如何监控 Red Hat 7.9 上的 RAM 消耗

如何监控 Red Hat 7.9 上的 RAM 消耗

配备 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或列。availablefree

答案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,其余都是缓冲区和缓存,如果系统需要更多内存来运行程序,则可以丢弃它们。但如果topfree是在大型程序因 OOM 终止并释放内存后立即运行的,那么这些指标就无关紧要了。

第一个sar输出显示已提交内存 (~60%) 和活动内存 (360GB) 比第二个输出 (分别约为 30% 和 260 GB) 更高。这些值与内存耗尽和进程被终止的情况相差甚远。第一个sar显示多天的测量结果没有任何显著变化,因此不存在缓慢的内存泄漏。

您的案例中的交换使用量微不足道(512GB 中只有 16 GB),影响不大。只要您在available列中topfree输出中有足够的内存,您的系统就可以在交换使用率为 100% 的情况下运行良好。您可以增加交换大小以使其利用率保持在 100% 以下,这样可以通过释放实际 RAM 来提高系统性能。密切关注vmstat交换入 (si) 和交换出 (so) 指标 - 它们在大多数情况下应该接近于零。请记住,交换使用率百分比是失控进程导致的内存消耗的二阶效应。

考虑到所有可用的细节和没有缓慢的内存泄漏,我怀疑你有时会有一个失控的进程,它会快速消耗所有内存,迫使交换使用率达到 100%,然后这个进程被 OOM 杀死。你需要检查日志中的 OOM 消息,它们应该包含有关被杀死的进程及其内存消耗的信息。一旦你确定了失控的进程,你就可以设置它的内存限制在其 systemd 单元中,因此它在消耗所有系统资源之前就被杀死。

您还可以通过运行随时检查各个进程的内存使用情况,top -o RES并根据进程的驻留内存消耗对其进行排序。

您可以安装一些简单的东西,例如监控监控选定进程的系统内存/交换消耗以及每个进程的内存消耗。

相关内容