具有 512 GB RAM 的 Red Hat 7.9 服务器。
我们经常收到有关交换空间已满的警报。99% 经常使用 Swap。我们的服务器管理员告诉我们，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
在网上我可以看到交换使用率高是不正常的。我还注意到，重新启动后，几天内交换量非常低。当一个进程消耗了所有 RAM（我们这边的错误）时，交换使用率会增加到 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 但我不知道如何解释它。“顶部”也一样。
例如，我将 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
我不知道要检查 top 或 free -h 的哪些值来了解 RAM 消耗使用的实际百分比。
非常感谢您的帮助
您的系统似乎没有任何与交换相关的问题。但是，正如您提到的高交换使用率和终止的进程，您可能偶尔会遇到内存不足的问题。
默认情况下，即使在具有大量可用内存的系统上，也会使用一些交换，因为内核会主动交换不活动的内存，以便为缓冲区/缓存提供更多空间。您有 500+ GB 的 RAM 和 16 GB 的交换分区，因此用不活动的数据填充它是正常的。
如果交换导致性能问题，您可以通过以下方式限制或禁用其使用：
sysctl vm.swappiness=0意味着系统不应该使用任何交换区，除非可用内存非常低。为了在重新启动后仍然存在，您需要将其写入vm.swappiness=0文件/etc/sysctl.conf；swapoff -a强制禁用任何交换。请注意，如果您确实需要一些交换（即：吸收内存消耗峰值），您的系统可能会通过 OOM-killer 杀死某些进程。要在重新启动后保持不变，您需要从/etc/fstab文件中删除交换条目；禁用磁盘交换并用于
zram创建压缩的 RAM 设备。zram可能非常有用，但除非确实需要并且适用于您的工作负载，否则我不会使用此解决方案。更多信息：
当交换进程存在时，应该释放交换空间。如果交换区不断被填满，则可能意味着另一个非交换进程被杀死，而不是被交换的进程。您可以使用它
dmesg来检查内核 OOM。这意味着内核正在尝试释放一些内存以防止 OOM（未成功）。
sar据我所知，不具备警报功能。您需要解析free输出和/或使用网络监控工具，如zabbix、netdata等。好吧，您确实应该阅读相关的手册页。简而言之，您可以检查报告的
used或列。availablefree我建议安装在顶部
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
这主要是评论。
呃，不。我希望这个故事在重述时失去了一些原来的意义。除了一些非常罕见的边缘情况外，在充当服务器的主机上主动使用交换是不好的。
同样非常奇特的是交换空间的大小约为 RAM 的 3%。我很难想象为什么这会有意义。
如果您不是系统管理员，我还想知道您在这个故事中的角色是什么。
在正确配置/管理的服务器主机上不应发生这种情况。
此外，您尝试用于此任务的工具对于诊断很有用，但对于监视却很差。有许多优秀的工具可供使用，其中许多是免费软件，用于监控；Zabbix、Nagios、Icinga、LibreNMS、Check_MK 等等。不要尝试编写自己的工具，除非您 1) 对系统管理有很好的了解 2) 有充分的理由不使用可用的工具。
Linux 内存利用率可能令人困惑，并且不同工具的输出难以解释。您可能需要先阅读https://www.linuxatemyram.com/之类的内容作为介绍性材料。
top和的输出free显示您的系统未充分利用 RAM - 正常运行 9 天后仅使用了 81GB，其他所有内容都是缓冲区和高速缓存，如果系统需要更多内存用于程序，则可以将其丢弃。但是，如果top和 是free在大型程序被 OOM 杀死并且内存被释放之后立即运行的，那么这些指标就无关紧要了。第一个
sar输出显示与第二个输出（分别为约 30% 和 260 GB）相比，更多的已提交内存 (~60%) 和更多的活动内存 (360GB)。这些值与内存耗尽和进程被杀死的情况相差甚远。第一个sar显示多天的测量结果，没有任何重大变化，因此不存在缓慢的内存泄漏。在您的情况下，交换使用量微不足道（512GB 中的 16 GB）并且影响不大。只要
available列输入top或free输出中有足够的内存，您的系统就可以在 100% 交换使用率下运行得很好。您可以增加交换大小以将其利用率保持在 100% 以下，从而通过释放实际 RAM 来提高系统性能。密切关注vmstat换入 (si) 和换出 (so) 指标 - 它们在大多数情况下应该接近于零。请记住，交换使用百分比是失控进程引起的内存消耗的二阶效应。考虑到所有可用的细节以及不存在缓慢的内存泄漏，我怀疑有时会出现一个失控的进程，它会快速消耗所有内存，迫使交换使用率达到 100%，然后该进程会被 OOM 杀死。您需要检查日志中是否有 OOM 消息，它们应该包含有关被终止进程及其内存消耗的信息。一旦识别出失控进程，您就可以在其 systemd 单元中设置其内存限制，以便在消耗所有系统资源之前将其杀死。
您还可以随时通过运行来检查各个进程的内存利用率，
top -o RES这将按进程的驻留内存消耗对进程进行排序。您可以安装诸如monit之类的简单工具来监视系统内存/交换消耗以及所选进程的每个进程的内存消耗。