Linux服务器只使用60％的内存，然后交换
我有一台运行我们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------ rb 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时间sorting的top的输出似乎支持swap这个理论，
- 如何增加交换大小？
- 在Linux中禁用交换的最佳方法
- 良好和免费的垃圾邮件filter
- 在一个小型组织的Windows 2012 R2域控制器上运行Exchange 2016有多糟？
- Outlook安全警报 – 安全证书上的名称无效或与网站的名称不匹配
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
这里按照虚拟内存的大小sorting：
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位问题的内存限制的问题。
Update2：正如我在原始问题中提到的，我已经尝试将swappiness调整为各种值，其中包括0.结果总是相同，大约有1.6 GB的内存未被使用。
Update3：向上述信息添加了顶级输出。
Bacula的性能是高度依赖于数据库的。 可能是postgresql会导致你的服务器死机。 高负载的平均水平和相当大的CPU等待时间等待状态清楚地表明它正在等待磁盘I / O …这就是PostgreSQL的做法。 对于备份集中的每个文件，至less要执行一条UPDATE语句。 不要担心交换。
调整PostgreSQL安装。 可能给个人数据库（甚至表）他们自己的磁盘/ RAID组来散布I / O。 你可以强制PostgreSQL使用asynchronous写入，如果它尚未…尽pipe这是交易数据库完整性的写性能。 提升PostgreSQL的共享内存。 这将减轻至less很多在数据库上的读取。 如果你从来没有这样做过，可以在Bacula数据库上运行VACCUM ANALYZE，并为查询优化器提供一些工作。
到目前为止，Bacula最薄弱的地方就是数据库的依赖性（以及其中一些的大脑死亡…）运行一个最近的大型备份的清除，并注意运行几十万个查询需要多长时间（经常）。巴库拉喜欢比较less的大文件，否则是狗。
你是I / O绑定的。 你的系统是一个小小的救生筏，在100英尺高的缓冲区/caching/虚拟机页面的大风浪中汹涌澎湃。
哇。 只是……哇。 你的I / O速度大约是100Mbyte / sec，I / O等待时间超过了50％的CPU时间，而你有4Gb的RAM。 这个服务器的虚拟机的背压必须是巨大的。 在“正常”的情况下，当系统开始缓冲/caching时，任何可用的RAM将在不到40秒内被活着吃掉 。
可以从/proc/sys/vm发布设置吗？ 这将提供一些洞察，你的内核认为是“正常的”。
那些postmaster进程也表明你在后台运行PostgreSQL。 这对你的设置是正常的吗？ PostgreSQL在默认configuration下使用的RAM很less，但一旦重新调整速度，它可以快速咀嚼25％-40％的可用内存。 所以，我只能猜测，鉴于输出中它们的数量，当您运行备份时，您正在运行某种生产数据库。 这不是一个好兆头。 你可以给一些更多的信息，为什么它正在运行？ 所有postmaster进程共享内存参数的大小是多less？ 是否可以closures服务，或临时重新configuration数据库以在备份运行时使用更less的连接/缓冲区？ 这将有助于消除已经紧张的I / O和可用RAM的一些压力。 请记住，每个postmaster进程消耗的RAM超出了数据库用于内部caching的范围。 所以，当你调整内存设置时， 要小心哪些是“共享”，哪些是“每进程” 。
如果您将PostgreSQL用作备份过程的一部分，请尝试将其重新调整为只接受最less数量的连接 ，并确保将每个进程的参数缩小到合理（每个只有几个兆）。 这样做的缺点是， 如果PostgreSQL不能像RAM那样使用RAM中的数据集，那么PostgreSQL会溢出到磁盘上，这样会增加磁盘I / O ，所以要仔细调整。
X11本身并不占用太多的内存，但是一个完整的桌面会话可以消耗几个megs。 注销您拥有的任何活动会话，并从控制台或通过SSH运行连接。
不过， 我不认为这完全是一个记忆问题。 如果你比50％的I / O长时间等待 （你发布的数字接近 70年代）， 那么最终的瓶颈将最终压垮其余的系统。 就像达斯·维达压扁脖子一样。
你configuration了多less个刷新线程 ？ 使用
cat /proc/sys/vm/nr_pdflush_threads
找出和
echo "vm.nr_pdflush_threads = 1" >> /etc/sysctl.conf
将其设置为单个线程。 请注意，最后一个命令会在重新启动后永久加载。 看到1或2在那里并不罕见。 如果你有几个内核或者大量的I / O的主轴/总线容量，你会想要稍微碰撞一下。 更多的刷新线程=更多的I / O活动，但也花费在I / O等待上更多的CPU时间。
它是默认值，还是你碰到它？ 如果你碰到了，你有没有考虑减less数量来减lessI / O操作的压力？ 或者是否有大量的主轴和通道可供使用，在这种情况下，是否考虑增加平头螺纹的数量？
PS你想设置swappiness到较低的值，而不是较高的值，以防止换出。 最高值= 100 =当感觉正确的时候，像疯了一样交换，最低值= 0 =尽量不要交换。
如果你看看在IO下每秒钟读取的数据块（bi），它将交换活动压缩多个数量级。 我不认为交换使用是什么导致你的磁盘颠簸，我认为你有东西运行在只是造成大量的磁盘活动（读取）的东西。
我会调查运行的应用程序，看看你是否能find罪魁祸首。
看看这个链接是否回答你的一些问题。 在60％的利用率之前，我经常看到Linux分页（不交换）内存。 这是其内存调优的一个预期部分：
http://www.sheepguardingllama.com/?p=2252
但是，你缺乏缓冲区/caching担心我。 这看起来很不寻常。 所以我在想更多的东西是不对的
你可以尝试完全禁用交换？
swapoff /dev/hdb2
或者至less这样做，至less会certificate它是交换这是你的问题，而不是别的。
默认情况下，swappiness被设置为60。
猫/ proc / sys / vm / swappiness 60
Swappiness是一个内核，用来调整内核对RAM的交换。 高swappiness意味着内核会换出很多，低swappiness意味着内核将尽量不使用swap空间。
我们可以在/etc/sysctl.conf中更改这个编辑vm.swappiness的值。
您可以手动设置内核的swappinness ，这可以在/proc/sys/vm/swappiness或者发出命令sysctl vm.swappiness 。 swappiness是决定使用多less交换的内核设置。
通过设置sudo sysctl vm.swappiness=0 ，可以有效地禁用交换分区。 要使此更改永久化，可以在/etc/sysctl.conf添加/修改vm.swappiness=0 。 你应该看看对你有什么好处。 我个人有它configuration为vm.swappiness=10 ，是60的默认值。
另一件你可能想要看的是你的内核运行队列和不可中断的进程（vmstat中的'r'和'b'列）是系统有时饱和的一个指标。 在旁注中，不要将饱和与利用相混淆…… 真正的问题可能是饱和内核的饥饿进程堆栈:-(
你也可以运行'pmap -x [PID]'来获取更多消耗进程的额外的内存细节。 祝你好运！
马特
也许你有短暂的过程，使用大量的内存，然后退出之前，你有机会注意到他们。
这与你所看到的一致。
你有调查问题与inodecaching？ 如果你遇到这样的事情， slabtop应该至less给你一个出发点。
当您的系统是64位时，系统可能无法实际处理所有可用内存。 这是一个芯片组限制。 例如，上一代Mac mini“支持”4GB内存，但实际上只有3.3GB是可寻址的。