配备 512 GB RAM 的 Red Hat 7.9 服务器。
我们经常收到有关交换空间已满的警报。交换空间经常被使用 99%。我们的服务器管理员告诉我们,Linux 交换空间被使用 100% 是正常的。没有办法检查实际的 RAM 消耗。
我们的服务器使用 SAR 后总能保持在 99% 左右:
Memory & Swap
=============
kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty
01/11/2024 9869583 517833049 98.13 977 285023790 319073740 58.60 340613912 162678784 614843
01/12/2024 4181004 523521628 99.21 1349 287757937 323767076 59.46 346046454 162168337 1115633
01/13/2024 2567787 525134845 99.51 844 285755715 327744180 60.19 352144911 157031086 654493
01/14/2024 2827695 524874937 99.46 844 285135562 328070493 60.25 352003644 156742082 742178
01/15/2024 3482087 524220545 99.34 1838 280133083 332837943 61.13 353676271 153986907 998373
01/16/2024 2152990 525549642 99.59 839 273578756 342252974 62.86 362157756 147013751 1136099
01/17/2024 4575639 523126993 99.13 2418 271393967 340334778 62.51 355987093 150884756 1033531
01/18/2024 2205445 525497187 99.58 2413 282078831 328216144 60.28 353148916 156770066 625021
01/19/2024 9451354 518251278 98.21 1542 293648210 305176716 56.05 352495156 150264497 680464
在网上我可以看到,高交换使用率是不正常的。我还注意到,重启后,几天内交换量都很低。当一个进程消耗了所有的内存(我们的错误)时,交换使用率就会增加到 100%,然后永远不会下降,即使相应的进程被杀死。这就是为什么运行了数周的服务器交换使用率达到 100% 的原因。
有人告诉我使用 sar (pswpin/s pswpout/s) 来监控交换使用情况。
当交换使用率为 100% 时,我不会遇到任何问题,但是当进程由于 RAM 问题而开始被终止时,我可以看到 pswpin/s pswpout/s(sar -W)的高值。
在一周内我可以监控此活动以检查是否存在 RAM 问题。
我的问题如下:如何防止 RAM 问题发生?我可以用什么来检查 RAM 的使用百分比(而在 SAR 中它始终是 99%...)?如何像在 Windows 操作系统中一样获取真实值?确保终止开始占用所有 RAM 的进程。
我想在 RAM 使用率达到 80% 时生成警告。
我知道可以使用 free -h,但我不知道如何解释它。“top”也是一样。
例如,我将 sar 输出与 free -h 和 top 输出进行比较,但没有看到匹配的值……:-(
[XXXXX@YYYYYY ~]$ sar -r
Linux 3.10.0-1062.4.1.el7.x86_64 (XXXXXX) 02/02/2024 _x86_64_ (64 CPU)
10:30:01 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty
11:55:01 AM 7916396 519786232 98.50 4688 436720908 164442944 30.20 256757744 249531760 1548
12:00:01 PM 1106680 526595948 99.79 4688 436883120 173459020 31.86 263356476 249699552 4184
12:05:01 PM 742056 526960572 99.86 4688 436447380 173668428 31.90 264216776 249402376 5380
12:10:01 PM 11076780 516625848 97.90 4688 434763392 162944064 29.93 255501116 247835888 3732
12:15:01 PM 7891084 519811544 98.50 4688 434921220 165981024 30.48 258656448 247885164 600
Average: 2201518 525501110 99.58 5447 448667788 154099963 28.30 257069976 255388912 3431
[XXXXX@YYYYYY ~]$ free -h
total used free shared buff/cache available
Mem: 503G 81G 4.3G 1.3G 417G 419G
Swap: 15G 11G 4.4G
[XXXXX@YYYYYY ~]$ top
top - 12:22:09 up 9 days, 18:55, 48 users, load average: 4.21, 4.69, 5.06
Tasks: 2645 total, 5 running, 2488 sleeping, 0 stopped, 152 zombie
%Cpu(s): 6.8 us, 3.4 sy, 0.0 ni, 89.8 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 52770262+total, 6888876 free, 83310656 used, 43750310+buff/cache
KiB Swap: 16777212 total, 4582892 free, 12194320 used. 44195168+avail Mem
我不知道要检查哪些值或 free -h 来了解 RAM 消耗使用情况的实际百分比。
非常感谢你的帮助
答案1
您的系统似乎没有任何与交换相关的问题。但是,正如您提到的高交换使用率和终止进程,您可能会偶尔遇到内存不足的问题。
默认情况下,即使在拥有大量可用内存的系统上,也预计会使用一些交换空间,因为内核会主动交换非活动内存,以便为缓冲区/缓存留出更多空间。您有 500+ GB 的 RAM 和 16 GB 的交换分区,因此用非活动数据填充它是正常的。
如果交换导致您的性能问题,您可以通过以下方式限制或禁用其使用:
sysctl vm.swappiness=0
意味着系统应该不是除非可用内存非常低,否则请使用任何交换。要使系统重启后仍保留,您需要将其放入文件vm.swappiness=0
中/etc/sysctl.conf
;swapoff -a
强制禁用任何交换。请注意,如果您确实需要一些交换(即:吸收内存消耗峰值),您的系统可以通过 OOM-killer 终止某些进程。要保留到重启后,您需要从/etc/fstab
文件中删除交换条目;禁用磁盘交换并使用
zram
创建压缩的 RAM 设备。zram
可能非常有用,但除非真正需要且适用于您的工作负载,否则我不会使用此解决方案。
更多信息:
当某个进程消耗了所有 RAM(这是我们的错误)时,交换使用率将增加到 100%,并且永远不会减少,即使相应的进程被终止
当存在交换进程时,应释放交换空间。如果交换空间不断被填满,则可能意味着另一个非交换进程被终止,而不是交换进程。您可以使用它dmesg
来检查内核 OOM。
当交换使用率为 100% 时,我不会遇到任何问题,但是当进程由于 RAM 问题而开始被终止时,我可以看到 pswpin/s pswpout/s(sar -W)的高值。
这意味着内核正在(未成功)尝试释放一些内存以防止 OOM。
我想在 RAM 使用率达到 80% 时生成警告。
sar
据我所知,没有警报功能。您需要解析free
输出和/或使用网络监视工具zabbix
,如netdata
、等。
我知道可以使用 free -h,但我不知道如何解释它。“top”也是一样。
嗯,你应该真的阅读相关手册页。简而言之,您可以检查报告的used
或列。available
free
答案2
我建议安装在顶部
https://www.redhat.com/sysadmin/analyzing-linux-server-performance-atop
这会在预定义的间隔内创建性能快照,以便您可以看到导致内存消耗的原因。
关于网络后续问题的编辑
Linux 内核不维护每个进程或每个线程发出的网络访问次数的计数器。因此,如果 atop 显示您的某个网络接口利用率很高,则无法分析哪个进程和/或线程导致的负载最大。可以加载可选内核模块 netatop 来收集有关每个进程和每个线程已发送/接收的 TCP 和 UDP 数据包的统计信息。一旦 atop 发现此模块处于活动状态,它就会在通用屏幕中显示 SNET 和 RNET 列,以显示每个进程发送和接收的数据包数量。按下“n”键时,它会显示有关通过 TCP 和 UDP 发送/接收的数据包数量、这些数据包的平均大小以及每个进程/线程输入和输出所消耗的总带宽的详细计数器。 https://www.atoptool.nl/netatop.php
答案3
这主要是评论。
我们的服务器管理员告诉我们,Linux 的交换使用率达到 100% 是正常的
呃,不。我希望这个故事在重述时会失去一些原有的意义。除了一些非常在极少数的边缘情况下,在充当服务器的主机上主动使用交换是不好的。
什么是还非常奇怪的是交换空间的大小约为 RAM 的 3%。我很难想象这有什么道理。
如果您不是系统管理员,我还想知道您在这个故事中扮演什么角色。
当进程因为 RAM 问题而被终止时
这不应该发生在正确配置/管理的服务器主机上。
此外,您尝试用于此任务的工具对于诊断很有用,但对于监控却很差。有很多优秀的工具可供使用,其中许多是免费软件,用于监控;Zabbix、Nagios、Icinga、LibreNMS、Check_MK 等等。除非您具备 1) 良好的系统管理知识 2) 一个非常不使用可用工具的充分理由。
答案4
Linux 内存利用率可能令人困惑,不同工具的输出也难以解释。你可能需要阅读类似https://www.linuxatemyram.com/首先作为介绍材料。
top
和的输出free
表明您的系统未充分利用 RAM - 正常运行 9 天后仅使用了 81GB,其余都是缓冲区和缓存,如果系统需要更多内存来运行程序,则可以丢弃它们。但如果top
和free
是在大型程序因 OOM 终止并释放内存后立即运行的,那么这些指标就无关紧要了。
第一个sar
输出显示已提交内存 (~60%) 和活动内存 (360GB) 比第二个输出 (分别约为 30% 和 260 GB) 更高。这些值与内存耗尽和进程被终止的情况相差甚远。第一个sar
显示多天的测量结果没有任何显著变化,因此不存在缓慢的内存泄漏。
您的案例中的交换使用量微不足道(512GB 中只有 16 GB),影响不大。只要您在available
列中top
或free
输出中有足够的内存,您的系统就可以在交换使用率为 100% 的情况下运行良好。您可以增加交换大小以使其利用率保持在 100% 以下,这样可以通过释放实际 RAM 来提高系统性能。密切关注vmstat
交换入 (si) 和交换出 (so) 指标 - 它们在大多数情况下应该接近于零。请记住,交换使用率百分比是失控进程导致的内存消耗的二阶效应。
考虑到所有可用的细节和没有缓慢的内存泄漏,我怀疑你有时会有一个失控的进程,它会快速消耗所有内存,迫使交换使用率达到 100%,然后这个进程被 OOM 杀死。你需要检查日志中的 OOM 消息,它们应该包含有关被杀死的进程及其内存消耗的信息。一旦你确定了失控的进程,你就可以设置它的内存限制在其 systemd 单元中,因此它在消耗所有系统资源之前就被杀死。
您还可以通过运行随时检查各个进程的内存使用情况,top -o RES
并根据进程的驻留内存消耗对其进行排序。
您可以安装一些简单的东西,例如监控监控选定进程的系统内存/交换消耗以及每个进程的内存消耗。