Linux 服务器只使用 60% 的内存，然后交换
Kam*_*iel 12 linux memory swap
我有一台运行我们的 bacula 备份系统的 Linux 服务器。机器像疯了一样磨，因为它很重来交换。问题是，它只使用了 60% 的物理内存！
这是来自的输出free -m：
free -m
total used free shared buffers cached
Mem: 3949 2356 1593 0 0 1
-/+ buffers/cache: 2354 1595
Swap: 7629 1804 5824
和一些示例输出vmstat 1：
procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 2 1843536 1634512 0 4188 54 13 2524 666 2 1 1 1 89 9 0
1 11 1845916 1640724 0 388 2700 4816 221880 4879 14409 170721 4 3 63 30 0
0 9 1846096 1643952 0 0 4956 756 174832 804 12357 159306 3 4 63 30 0
0 11 1846104 1643532 0 0 4916 540 174320 580 10609 139960 3 4 64 29 0
0 4 1846084 1640272 0 2336 4080 524 140408 548 9331 118287 3 4 63 30 0
0 8 1846104 1642096 0 1488 2940 432 102516 457 7023 82230 2 4 65 29 0
0 5 1846104 1642268 0 1276 3704 452 126520 452 9494 119612 3 5 65 27 0
3 12 1846104 1641528 0 328 6092 608 187776 636 8269 113059 4 3 64 29 0
2 2 1846084 1640960 0 724 5948 0 111480 0 7751 116370 4 4 63 29 0
0 4 1846100 1641484 0 404 4144 1476 125760 1500 10668 105358 2 3 71 25 0
0 13 1846104 1641932 0 0 5872 828 153808 840 10518 128447 3 4 70 22 0
0 8 1846096 1639172 0 3164 3556 556 74884 580 5082 65362 2 2 73 23 0
1 4 1846080 1638676 0 396 4512 28 50928 44 2672 38277 2 2 80 16 0
0 3 1846080 1628808 0 7132 2636 0 28004 8 1358 14090 0 1 78 20 0
0 2 1844728 1618552 0 11140 7680 0 12740 8 763 2245 0 0 82 18 0
0 2 1837764 1532056 0 101504 2952 0 95644 24 802 3817 0 1 87 12 0
0 11 1842092 1633324 0 4416 1748 10900 143144 11024 6279 134442 3 3 70 24 0
2 6 1846104 1642756 0 0 4768 468 78752 468 4672 60141 2 2 76 20 0
1 12 1846104 1640792 0 236 4752 440 140712 464 7614 99593 3 5 58 34 0
0 3 1846084 1630368 0 6316 5104 0 20336 0 1703 22424 1 1 72 26 0
2 17 1846104 1638332 0 3168 4080 1720 211960 1744 11977 155886 3 4 65 28 0
1 10 1846104 1640800 0 132 4488 556 126016 584 8016 106368 3 4 63 29 0
0 14 1846104 1639740 0 2248 3436 428 114188 452 7030 92418 3 3 59 35 0
1 6 1846096 1639504 0 1932 5500 436 141412 460 8261 112210 4 4 63 29 0
0 10 1846104 1640164 0 3052 4028 448 147684 472 7366 109554 4 4 61 30 0
0 10 1846100 1641040 0 2332 4952 632 147452 664 8767 118384 3 4 63 30 0
4 8 1846084 1641092 0 664 4948 276 152264 292 6448 98813 5 5 62 28 0
此外，按 CPU 时间排序的 top 输出似乎支持交换导致系统陷入困境的理论：
top - 09:05:32 up 37 days, 23:24, 1 user, load average: 9.75, 8.24, 7.12
Tasks: 173 total, 1 running, 172 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.6%us, 1.4%sy, 0.0%ni, 76.1%id, 20.6%wa, 0.1%hi, 0.2%si, 0.0%st
Mem: 4044632k total, 2405628k used, 1639004k free, 0k buffers
Swap: 7812492k total, 1851852k used, 5960640k free, 436k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ TIME COMMAND
4174 root 17 0 63156 176 56 S 8 0.0 2138:52 35,38 bacula-fd
4185 root 17 0 63352 284 104 S 6 0.0 1709:25 28,29 bacula-sd
240 root 15 0 0 0 0 D 3 0.0 831:55.19 831:55 kswapd0
2852 root 10 -5 0 0 0 S 1 0.0 126:35.59 126:35 xfsbufd
2849 root 10 -5 0 0 0 S 0 0.0 119:50.94 119:50 xfsbufd
1364 root 10 -5 0 0 0 S 0 0.0 117:05.39 117:05 xfsbufd
21 root 10 -5 0 0 0 S 1 0.0 48:03.44 48:03 events/3
6940 postgres 16 0 43596 8 8 S 0 0.0 46:50.35 46:50 postmaster
1342 root 10 -5 0 0 0 S 0 0.0 23:14.34 23:14 xfsdatad/4
5415 root 17 0 1770m 108 48 S 0 0.0 15:03.74 15:03 bacula-dir
23 root 10 -5 0 0 0 S 0 0.0 13:09.71 13:09 events/5
5604 root 17 0 1216m 500 200 S 0 0.0 12:38.20 12:38 java
5552 root 16 0 1194m 580 248 S 0 0.0 11:58.00 11:58 java
以下是按虚拟内存映像大小排序的相同内容：
top - 09:08:32 up 37 days, 23:27, 1 user, load average: 8.43, 8.26, 7.32
Tasks: 173 total, 1 running, 172 sleeping, 0 stopped, 0 zombie
Cpu(s): 3.6%us, 3.4%sy, 0.0%ni, 62.2%id, 30.2%wa, 0.2%hi, 0.3%si, 0.0%st
Mem: 4044632k total, 2404212k used, 1640420k free, 0k buffers
Swap: 7812492k total, 1852548k used, 5959944k free, 100k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ TIME COMMAND
5415 root 17 0 1770m 56 44 S 0 0.0 15:03.78 15:03 bacula-dir
5604 root 17 0 1216m 492 200 S 0 0.0 12:38.30 12:38 java
5552 root 16 0 1194m 476 200 S 0 0.0 11:58.20 11:58 java
4598 root 16 0 117m 44 44 S 0 0.0 0:13.37 0:13 eventmond
9614 gdm 16 0 93188 0 0 S 0 0.0 0:00.30 0:00 gdmgreeter
5527 root 17 0 78716 0 0 S 0 0.0 0:00.30 0:00 gdm
4185 root 17 0 63352 284 104 S 20 0.0 1709:52 28,29 bacula-sd
4174 root 17 0 63156 208 88 S 24 0.0 2139:25 35,39 bacula-fd
10849 postgres 18 0 54740 216 108 D 0 0.0 0:31.40 0:31 postmaster
6661 postgres 17 0 49432 0 0 S 0 0.0 0:03.50 0:03 postmaster
5507 root 15 0 47980 0 0 S 0 0.0 0:00.00 0:00 gdm
6940 postgres 16 0 43596 16 16 S 0 0.0 46:51.39 46:51 postmaster
5304 postgres 16 0 40580 132 88 S 0 0.0 6:21.79 6:21 postmaster
5301 postgres 17 0 40448 24 24 S 0 0.0 0:32.17 0:32 postmaster
11280 root 16 0 40288 28 28 S 0 0.0 0:00.11 0:00 sshd
5534 root 17 0 37580 0 0 S 0 0.0 0:56.18 0:56 X
30870 root 30 15 31668 28 28 S 0 0.0 1:13.38 1:13 snmpd
5305 postgres 17 0 30628 16 16 S 0 0.0 0:11.60 0:11 postmaster
27403 postfix 17 0 30248 0 0 S 0 0.0 0:02.76 0:02 qmgr
10815 postfix 15 0 30208 16 16 S 0 0.0 0:00.02 0:00 pickup
5306 postgres 16 0 29760 20 20 S 0 0.0 0:52.89 0:52 postmaster
5302 postgres 17 0 29628 64 32 S 0 0.0 1:00.64 1:00 postmaster
我已经尝试将swappiness内核参数调整为高值和低值，但似乎没有改变这里的行为。我不知道发生了什么。我怎样才能找出导致这种情况的原因？
更新：该系统是一个完全 64 位的系统，因此应该不存在由于 32 位问题导致的内存限制问题。
更新 2：正如我在原始问题中提到的，我已经尝试将 swappiness 调整为各种值，包括 0。结果始终相同，大约有 1.6 GB 的内存未使用。
更新 3：将顶部输出添加到上述信息。
Ave*_*yne 19
您受 I/O 限制。 您的系统是一个小小的救生筏，在 100 英尺高的缓冲区/缓存/VM 分页膨胀的风暴海洋中遭受重创。
哇。只是……哇。您的 I/O 速度大约为 100Mbyte/sec，您在 I/O 等待中的 CPU 时间已经超过 50%，并且您拥有 4Gb 的 RAM。这台服务器的虚拟机上的背压一定是巨大的。在“正常”情况下，当系统开始缓冲/缓存时，您拥有的任何可用 RAM 都将在 40 秒内被活活吃掉。
是否可以从发布设置/proc/sys/vm？这将提供一些关于您的内核认为什么是“正常”的见解。
这些postmaster进程还表明您正在后台运行 PostgreSQL。这对于您的设置是否正常？默认配置中的 PostgreSQL 将使用很少的 RAM，但是一旦重新调整速度，它可以快速消耗 25%-40% 的可用 RAM。所以我只能猜测，鉴于输出中的数量，您在运行备份时正在运行某种生产数据库。 这不是好兆头。 你能提供更多关于它为什么运行的信息吗？所有共享内存参数的大小是多少postmaster流程？是否可以关闭服务，或临时重新配置数据库以在备份运行时使用更少的连接/缓冲区？这将有助于减轻已经紧张的 I/O 和可用 RAM 的一些压力。请记住，每个 postmaster进程消耗的 RAM 都超过了数据库用于内部缓存的 RAM。因此，当您调整内存设置时，请注意哪些是“共享的”，哪些是“每个进程的”。
如果您使用 PostgreSQL 作为备份过程的一部分，请尝试重新调整它以仅接受最少的连接数，并确保将每个进程的参数缩小到合理的范围（每个只有几兆）。这样做的缺点是，如果 PostgreSQL 不能像它想要的那样处理 RAM 中的数据集，它会溢出到磁盘，因此这实际上会增加您的磁盘 I/O，因此请仔细调整。
X11 本身并不会占用太多内存，但一个完整的桌面会话可能会消耗几兆内存。注销您拥有的所有活动会话并从控制台或通过 SSH 运行您的连接。
不过，我不认为这完全是内存问题。 如果您的 I/O 等待时间超过 50%（并且您发布的数据接近70 年代），那么由此产生的瓶颈最终将摧毁系统的其余部分。就像达斯·维达压伤脖子一样。
您配置了多少个冲洗线程？用
cat /proc/sys/vm/nr_pdflush_threads
找出并
echo "vm.nr_pdflush_threads = 1" >> /etc/sysctl.conf
将其设置为单线程。请注意，最后一个命令使其在重新启动时永久加载。在那里看到 1 或 2 并不罕见。如果您有多个内核或大量用于 I/O 的主轴/总线容量，您会想要（稍微）增加它们。更多的刷新线程 = 更多的 I/O 活动，但也有更多的 CPU 时间花在 I/O 等待上。
它是默认值，还是你碰过它？如果您遇到了它，您是否考虑过减少数量以减少对 I/O 操作的压力？或者您是否有大量的主轴和通道可以使用，在这种情况下，您是否考虑过增加冲洗线程的数量？
PS 您想将swappiness 设置为较低的值，而不是较高的值，以防止换出。最高值 = 100 = 在感觉合适时疯狂交换，最低值 = 0 = 尽量不要交换。
如果您查看 IO 下每秒 (bi) 读取的块，它会使交换活动相形见绌多个数量级。我不认为交换使用是导致您的磁盘抖动的原因，我认为您在盒子上运行了一些只是导致大量磁盘活动（读取）的东西。
我会调查正在运行的应用程序，看看你是否能找到罪魁祸首。
看看这个链接是否回答了你的一些问题。我经常看到 Linux 分页（而不是交换）内存在 60% 利用率之前很久。这是其内存调整的预期部分：
http://www.sheepguardingllama.com/?p=2252
但是你缺少缓冲区/缓存让我很担心。这看起来很不寻常。所以我在想还有什么不对的。
您可以尝试完全禁用交换吗？
swapoff /dev/hdb2
或一些这样的 - 至少这将验证它正在交换这是您的问题，而不是其他问题。
Bacula 性能高度依赖于数据库。很可能是 postgresql 杀死了您的服务器。高平均负载和相当大的 CPU 时间百分比花在等待状态清楚地表明它正在等待磁盘 I/O……这就是 PostgreSQL 所做的。对于备份集中的每个文件，它至少执行一个 UPDATE 语句。不用担心交换。
调整 PostgreSQL 安装。可能为单个数据库（甚至表）提供自己的磁盘/raid 集以分散 I/O。如果还没有，您可以强制 PostgreSQL 使用异步写入......尽管这是为了写入性能而交易数据库完整性。充分利用 PostgreSQL 可用的共享内存。这将至少减轻对数据库的大量读取。如果您从未这样做过，也可以在 Bacula 数据库上运行 VACCUM ANALYZE，以便为查询优化器提供一些工作。
到目前为止，Bacula 的最弱点是数据库依赖项（以及其中一些的脑死亡......）运行最近的大型备份的清除并注意运行几千万次查询需要多长时间（通常是几个小时）。 .. Bacula 喜欢的大文件比较少，否则就是一条狗。