Я собираю данные для мониторинга серверов HPC и обсуждаю политику распределения памяти (избыточная или нет). Я хотел показать пользователям количество виртуальной памяти, запрошенной их процессами (всей машиной), и сколько фактически было использовано.
Я думал, что получу интересные значения из / proc / meminfo, используя поля MemTotal, MemAvailable и Committed_AS. Последнее должно показывать, сколько памяти было выделено ядром, наихудшее число того, сколько памяти действительно потребуется для выполнения текущих задач.
Но Committed_AS явно слишком мал. Он меньше используемой в настоящее время памяти! Обратите внимание на два примера систем. Один административный сервер:
# cat /proc/meminfo
MemTotal: 16322624 kB
MemFree: 536520 kB
MemAvailable: 13853216 kB
Buffers: 156 kB
Cached: 9824132 kB
SwapCached: 0 kB
Active: 4854772 kB
Inactive: 5386896 kB
Active(anon): 33468 kB
Inactive(anon): 412616 kB
Active(file): 4821304 kB
Inactive(file): 4974280 kB
Unevictable: 10948 kB
Mlocked: 10948 kB
SwapTotal: 16777212 kB
SwapFree: 16777212 kB
Dirty: 884 kB
Writeback: 0 kB
AnonPages: 428460 kB
Mapped: 53236 kB
Shmem: 26336 kB
Slab: 4144888 kB
SReclaimable: 3863416 kB
SUnreclaim: 281472 kB
KernelStack: 12208 kB
PageTables: 38068 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 24938524 kB
Committed_AS: 1488188 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 317176 kB
VmallocChunk: 34358947836 kB
HardwareCorrupted: 0 kB
AnonHugePages: 90112 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 144924 kB
DirectMap2M: 4988928 kB
DirectMap1G: 13631488 kB
Это примерно 1,5 ГБ по сравнению с 2,5 ГБ при использовании без кешей. Вычислительный узел:
ssh node390 cat /proc/meminfo
MemTotal: 264044768 kB
MemFree: 208603740 kB
MemAvailable: 215043512 kB
Buffers: 15500 kB
Cached: 756664 kB
SwapCached: 0 kB
Active: 44890644 kB
Inactive: 734820 kB
Active(anon): 44853608 kB
Inactive(anon): 645100 kB
Active(file): 37036 kB
Inactive(file): 89720 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 134216700 kB
SwapFree: 134216700 kB
Dirty: 0 kB
Writeback: 140 kB
AnonPages: 44918876 kB
Mapped: 52664 kB
Shmem: 645408 kB
Slab: 7837028 kB
SReclaimable: 7147872 kB
SUnreclaim: 689156 kB
KernelStack: 8192 kB
PageTables: 91528 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 345452512 kB
Committed_AS: 46393904 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 797140 kB
VmallocChunk: 34224733184 kB
HardwareCorrupted: 0 kB
AnonHugePages: 41498624 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 312640 kB
DirectMap2M: 7966720 kB
DirectMap1G: 262144000 kB
Это примерно 47G используется против 44G. Речь идет о кластере CentOS 7:
uname-a
Linux adm1 3.10.0-862.14.4.el7.x86_64 #1 SMP Wed Sep 26 15:12:11 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
На моем рабочем столе Linux, использующем ванильное ядро, я вижу более «разумные» цифры с выделенными 32 Гбайт по сравнению с используемыми 15.5 Гбайт. На сервере Debian я вижу, что используется 0,4 ГБ, а на сервере - 1,5 ГБ.
Может кто-то объяснить это мне? Как мне получить правильный номер выделенной памяти? Это ошибка ядра CentOS / RHEL, о которой следует сообщить?
Список использованной / выделенной памяти для различных систем, к которым я мог получить доступ, с примечанием о типе нагрузки:
SUnreclaim для SLES и CentOS довольно большой… 0,5–1 Гбайт не редкость, даже если не промывать кеши время от времени. Но этого недостаточно, чтобы объяснить отсутствие памяти в Committed_AS. Машины с Ubuntu обычно имеют менее 100 млн SUnreclaim. Кроме 14.04, у этого есть небольшой Committed_AS и 0.4G SUnreclaim. Привести ядра в порядок непросто, так как ядро 3.10 от CentOS имеет многие функции ядра 4.x, перенесенные обратно. Но, похоже, есть грань между 4.4 и 4.9, которая повлияла на странно низкие значения Committed_AS. Серверы, добавленные некоторыми из моих коллег, предполагают, что Committed_AS также предоставляет странные числа для старых ядер. Было ли это сломано и исправлено несколько раз?
Люди могут это подтвердить? Это просто глючит /очень неточное поведение ядра при определении значений в / proc / meminfo, или есть история ошибок (исправлений)?
Некоторые записи в списке действительно странный. Неправильно иметь один процесс slurmdbd с четырехкратным RSS-потоком Committed_AS. У меня возникает соблазн протестировать ванильное ядро на этих системах с той же рабочей нагрузкой, но я не могу снимать с производства самые интересные машины для таких игр.
Думаю, ответ на мой вопрос - указатель на исправление в истории коммитов ядра, которое снова позволило получить хорошие оценки в Committed_AS. В противном случае просветите меня, пожалуйста ;-)
Эти коробки не испытывают значительной нагрузки на память. Также нет пейджинга (SwapFree). Второй ящик составляет ~ 47 ГБ из 250 ГБ. 200 ГБ - это много для игры.
На практике продолжайте увеличивать размер рабочей нагрузки, пока не произойдет одно из следующих событий:
Отношения между счетчиками памяти не интуитивно понятны, сильно различаются между рабочими нагрузками и, вероятно, действительно понятны только разработчикам ядра. Не беспокойтесь об этом слишком сильно, сосредоточьтесь на измерении очевидной нагрузки на память.
В других описаниях Comisted_AS, недавно включенных в список linux-mm, подчеркивается, что это оценка:
Committed_AS: An estimate of how much RAM you would need to make a 99.99% guarantee that there never is OOM (out of memory) for this workload. Normally the kernel will overcommit memory. That means, say you do a 1GB malloc, nothing happens, really. Only when you start USING that malloc memory you will get real memory on demand, and just as much as you use. So you sort of take a mortgage and hope the bank doesn't go bust. Other cases might include when you mmap a file that's shared only when you write to it and you get a private copy of that data. While it normally is shared between processes. The Committed_AS is a guesstimate of how much RAM/swap you would need worst-case.