Linux服务器仅使用60％的内存，然后交换

12

我有一台运行我们的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位问题引起的内存限制问题。

Update2：正如我在原始问题中提到的那样，我已经尝试将swappiness调整为各种值，包括0。结果始终是相同的，大约有1.6 GB的未使用内存。

Update3：在上面的信息中增加了顶部输出。

linux memory swap

— 卡米尔·基西尔（Kamil Kisiel）
source

2

看起来Linux并没有使用页面缓存，但是您仍然有大量的可用内存。显然有些不对劲。

— David Pashley 2009年

1

您可以发布一些其他Linux OS详细信息吗？供应商，发行版，内核版本等？我想建议几个工具，但是其中一些需要特定的内核版本或支持库版本。

— Christopher Cashell

6

Bacula的性能在很大程度上取决于数据库。可能是PostgreSQL杀死了您的服务器。平均负载很高，并且在等待状态下花费的CPU时间所占的百分比很大，这清楚地表明它正在等待磁盘I / O ...这就是PostgreSQL所做的。对于备份中的每个文件，请至少执行一条UPDATE语句。不用担心交换。

请调整PostgreSQL安装。可能给单个数据库（甚至表）自己的磁盘/突袭集，以分散I / O。您可以强制PostgreSQL使用异步写入（如果尚未进行的话）...尽管这是为了牺牲写入性能而进行的数据库完整性交换。充分利用PostgreSQL可用的共享内存。这将至少减轻数据库中的大量读取。如果您从未做过，那么也可以在Bacula数据库上运行VACCUM ANALYZE，以使查询优化器可以使用。

到目前为止，Bacula的最弱点是数据库依赖关系（以及其中某些人的脑力衰竭……）对最近的大型备份进行清除，并注意运行几千万个查询需要多长时间（通常数小时）。 .. Bacula不喜欢比较大的文件，否则它是只狗。

— 亚历山大·卡梅尔·维勒
source

谢谢。这确实看起来像是问题的症结所在。我们将研究纠正它的方法。

— 卡米尔·基西尔

19

您是I / O绑定的。 您的系统就像是一条救生筏，被汹涌的缓冲区/高速缓存/ VM分页激增浪潮所打击，该激增层高100英尺。

哇。只是...哇。您的I / O速度约为100Mbyte / sec，I / O等待中的CPU时间已远远超过50％，并且您具有4Gb的RAM。此服务器的VM上的背压一定很大。在“正常”情况下，随着系统开始缓冲/缓存，您拥有的所有可用RAM将在不到40秒的时间内被吞噬。

是否可以张贴设置的/proc/sys/vm？这将提供一些有关您的内核认为“正常”的见解。

这些postmaster过程还表明您在后台运行PostgreSQL。这对您的设置正常吗？默认配置中的PostgreSQL将使用很少的RAM，但是一旦对其速度进行了调整，它可以迅速消耗25％-40％的可用RAM。因此，我只能猜测，根据输出中的数量，您在运行备份时正在运行某种生产数据库。 这不是一个好兆头。 您能否提供更多有关其运行原因的信息？所有共享内存参数的大小是多少postmaster过程？在备份运行时，是否可以关闭服务或临时重新配置数据库以使用较少的连接/缓冲区？这将有助于减轻已经紧张的I / O和可用RAM的压力。请记住，每个 postmaster进程消耗的内存超出了数据库用于内部缓存的内存。因此，在调整内存设置时，请注意哪些是“共享的”，哪些是“每个进程的”。

如果您在备份过程中使用PostgreSQL，请尝试对其进行重新调整，使其仅接受最小数量的连接，并确保将每个进程的参数缩减至合理的水平（每个参数仅减少几兆）。不利的一面是，如果PostgreSQL无法像它想要的那样使用RAM中的数据集，它将泄漏到磁盘上，因此实际上会增加磁盘I / O，因此请仔细调整。

X11本身并不会占用太多内存，但是一个完整的桌面会话可能会消耗数兆。注销所有活动会话，然后从控制台或通过SSH运行连接。

不过，我不认为这完全是内存问题。 如果您的I / O优于50％，则需要等待更长的时间（并且发布的数字接近 70年代），由此产生的瓶颈最终将压垮系统的其余部分。就像达斯·维达（Darth Vader）压脖子一样。

达斯·维达（Darth Vader）死气沉沉的企业界有人

您配置了多少个刷新线程？采用

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 =尝试完全不进行交换。

— 艾利佩恩
source

我会看你的一些建议。不，我并不疯，并在备份系统上运行生产数据库。PostgreSQL是备份系统的一部分，因为Bacula使用PostgreSQL作为其信息存储来跟踪磁带上的内容，等等。我将研究调整您指定的一些参数。由于其他服务器将数据转储到该服务器的磁盘托盘中，因此该I / O吞吐量很高，因此该服务器随后提取该数据并将其写入LTO4磁带库。

— 卡米尔·基西尔

服务器的磁盘如何排列？您是否在使用镜像驱动器设置？

— 艾利·佩恩

1

紫色散文+1 ：）

— pjc50

是的，那天我有点创意。对不起这部戏。:)

— 艾利·佩恩

7

如果查看IO下每秒读入的数据块（bi），则会使交换活动相差多个数量级。我不认为交换使用是导致磁盘抖动的原因，我认为您正在盒子上运行的东西只是在引起大量磁盘活动（读取）。

我将调查正在运行的应用程序，看看是否可以找到罪魁祸首。

— 克里斯托弗·卡贝
source

好吧，正如我所说，它正在运行bacula备份系统。服务器中的数据块可能是服务器将数据转储到其外部连接的SAS磁盘阵列的结果。

— 卡米尔·基西尔

1

您确定磁盘正在从交换中删除，而不是备份中？包装盒上正在运行其他哪些进程？如果内核足够新，那么可以使用一些非常有用的工具（iotop），深入了解io的使用情况，如果使用CFQ IO调度程序，甚至可以设置IO优先级（高级）。

— Christopher Cashell

6

查看此链接是否回答您的某些问题。我经常看到Linux分页（不交换）内存使用率早于60％。这是预期的内存调整部分：

http://www.sheepguardingllama.com/?p=2252

但是您缺少缓冲区/缓存使我感到担忧。看起来很不寻常。所以我认为还有更多不对劲。

— 斯科特·艾伦·米勒
source

嘿-通话很好-缓冲区/缓存在哪里？他们关闭了吗？是某种使他们不断失效的东西吗？

— MikeyB 2009年

6

您可以尝试完全禁用交换吗？

swapoff /dev/hdb2

或某些类似的东西-至少可以验证它是您的问题，而不是其他问题。

— 蒂姆·霍兰德
source

+1以确认假定的诊断实际上是问题的原因。

— 韦恩

明天我会在工作中尝试一下。另外，我的Spaw不在/ dev / hdb2上；）

— Kamil Kisiel 2009年

应当指出的是，尽管这是一个很好的诊断帮助，但在生产系统上却非常危险。如果您确实需要交换，则会很快用完RAM。然后，OOM杀手将来杀掉一个随机过程，该过程可能只是您的生产数据库……

— sleske

同意-您不应该在生产附近的任何地方这样做。

— 蒂姆·霍兰德

3

默认情况下，swappiness设置为60。

猫/ proc / sys / vm / swappiness 60

Swappiness是一个内核，用于调整内核支持通过RAM进行交换的程度；高交换意味着内核将大量交换，而低交换意味着内核将不使用交换空间。

我们可以在/etc/sysctl.conf中更改此编辑的vm.swappiness值。

— 镍素
source

或者，您可以直接在中写入百分比/proc/sys/vm/swappiness。

— user2284570 2014年

2

您可以手动设置内核的可交换性，直到可以看到/proc/sys/vm/swappiness或发出命令sysctl vm.swappiness。swappiness是一个内核设置，它确定使用多少交换空间。

通过设置，sudo sysctl vm.swappiness=0您可以有效地停用交换分区。为了使这种更改永久您可以添加/修改vm.swappiness=0在/etc/sysctl.conf。您应该看到什么对您有好处。我个人将其配置为vm.swappiness=10，默认值为60。

— 航海家
source

不完全是，对于swappiness = 0，您是说如果有办法避免，则从不交换，但是如果唯一的选择是使分配失败或OOM 终止，则仍然要交换。我发现30的可交换性在笔记本电脑上是一个不错的改进，但不必在其他系统上搞乱它。

— LapTop006

1

您可能要看的另一件事是内核运行队列和不可互斥的进程（vmstat中的“ r”和“ b”列）指示系统有时已饱和。附带说明一下，不要将饱和与利用率混淆... 真正的问题可能是针对饱和内核的饥饿的进程堆栈:-(

您还可以运行'pmap -x [PID]'，以从一些更耗时的进程中获取更多内存详细信息。祝你好运！

马特

— 马特·卡明斯
source

1

也许您的生命周期短暂，会占用大量内存，然后在有机会注意到它们之前退出。

无论如何，这将与您所看到的一致。

— 标记
source

1

您是否调查过inode缓存问题？slabtop如果您遇到类似问题，至少应该为您提供一个起点。

— 马丁·M
source

0

当您的系统是64位时，系统可能无法实际寻址所有可用内存。这是芯片组的限制。例如，上一代Mac mini“支持” 4GB的ram，但实际上只有3.3GB是可寻址的。

— 达斯汀
source

它是SGI Altix XE240，我相当确定它可以支持超过4 GB的RAM，因为我已经使用了32 GB的演示单元。

— 卡米尔·基西尔

“这不是旧版mini中的芯片组限制，该芯片组可以达到8GB，但是Apple并未添加地址线来正确处理它（IIRC，但多家制造商之间存在普遍情况）

— LapTop006