Zbieram liczby do monitorowania serwerów HPC i debatuję nad zasadami wydawania pamięci (nadmiernie lub nie). Chciałem pokazać użytkownikom liczbę o ile pamięci wirtualnej zażądali ich procesy (cała maszyna) w porównaniu do tego, ile faktycznie zostało wykorzystane.
Myślałem, że uzyskam interesujące wartości z / proc / meminfo przy użyciu pól MemTotal, MemAvailable i Committed_AS. Ten ostatni ma pokazać, ile pamięci zostało zajęte przez jądro, a najgorszy przypadek, ile pamięci naprawdę byłoby potrzebne do wykonania uruchomionych zadań.
Ale Committed_AS jest oczywiście za mały. Jest mniejszy niż obecnie używana pamięć! Obserwuj dwa przykładowe systemy. Jeden serwer administracyjny:
# 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
Jest to w przybliżeniu 1,5 G popełnione, a 2,5 G jest używane bez pamięci podręcznej. Węzeł obliczeniowy:
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
Jest to około 47G użytych vs. 44G zaangażowanych. Omawiany system to klaster 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
Na moim pulpicie Linuksa za pomocą jądra wanilii widzę więcej „rozsądnych” liczb przy zatwierdzonym 32G w porównaniu z 15,5G. Na serwerze Debian widzę 0,4G w użyciu vs. 1,5G zatwierdzone.
Czy ktoś może mi to wyjaśnić? Jak uzyskać prawidłowy numer dla zatwierdzonej pamięci? Czy to błąd w jądrze CentOS / RHEL, który należy zgłosić?
Zaktualizuj, dodając więcej danych i porównanie systemów
Lista pamięci używanej / zatwierdzonej dla różnych systemów, do których mogłem uzyskać dostęp, z notatką o rodzaju obciążenia:
- SLES 11.4 (jądro 3.0.101-108.71-domyślne)
- 17.6G / 17,4G , interaktywny HPC dla wielu użytkowników (np. MATLAB, GIS)
- CentOS 7.4 / 7.5 (jądro 3.10.0-862.11.6.el7 lub 3.10.0-862.14.4.el7)
- 1.7G / 1.3G , serwer administracyjny, klaster mgmt, DHCP, TFTP, rsyslog,…
- 8.6G / 1.7G , system wsadowy SLURM, 7.2G RSS dla samego slurmdbd
- 5.1G / 0.6G , serwer NFS (400 klientów)
- 26,8G / 32,6G, 16-rdzeniowy węzeł HPC załadowany 328 (trzeba porozmawiać z użytkownikiem) procesami GNU R
- 6,5G / 8,1G, 16-rdzeniowy węzeł HPC z 16 procesami MPI
- Ubuntu 16.04 (jądro 4.15.0-33-generic)
- 1.3G / 2.2G, 6-rdzeniowy węzeł HPC, 6-wątkowa aplikacja naukowa (1.1G RSS)
- 19,9G / 20,3G, 6-rdzeniowy węzeł HPC, 6-wątkowa aplikacja naukowa (19G RSS)
- 1.0G / 4.4G, 6-rdzeniowy węzeł logowania z serwerem metadanych / mgmt BeeGFS
- Ubuntu 14.04 (jądro 3.13.0-161-ogólne)
- 0,7G / 0,3G , maszyna wirtualna serwera HTTP
- Kompilacja niestandardowa (jądro wanilii 4.4.163)
- 0,7G / 0,04G , głównie bezczynny serwer Subversion
- Kompilacja niestandardowa (jądro wanilii 4.14.30)
- 14,2G / 31,4G, długo działający pulpit
- Alpine (jądro 4.4.68-0-grsec)
- 36,8M / 16,4M , niektóre serwery (sieciowe)
- Ubuntu 12.04 (jądro 3.2.0-89-generic)
- 1.0G / 7.1G, jakiś serwer
- Ubuntu 16.04 (jądro 4.4.0-112-ogólne)
- 0,9G / 1,9G, jakiś serwer
- Debian 4.0 (jądro 2.6.18-6-686, 32-bitowy x86, oczywiście)
- 1.0G / 0.8G , jakiś niezawodny serwer
- Debian 9.5 (jądro 4.9.0-6)
- 0.4G / 1.5G, różne usługi sieciowe, oczywiście lekkie obciążenie
- Debian 9.6 (jądro 4.9.0-8-amd64)
- 10,9G / 17,7G, komputer stacjonarny
- Ubuntu 13.10 (jądro 3.11.0-26-generic)
- 3.2G / 5.4G, stary pulpit
- Ubuntu 18.04 (jądro 4.15.0-38-generic)
- 6,4 G / 18,3 G, komputer stacjonarny
NIEZastosowanie dla SLES i CentOS raczej duże… 0,5G do 1G nie jest rzadkie, więcej, jeśli nie opróżnianie pamięci podręcznych od czasu do czasu. Ale nie wystarczy, aby wyjaśnić brakującą pamięć w Committed_AS. Maszyny Ubuntu zazwyczaj mają mniej niż 100 mln SUnreclaim. Z wyjątkiem wersji 14.04, ta ma małe Committed_AS i 0,4G SUnreclaim. Uporządkowanie jądra jest trudne, ponieważ jądro 3.10 z CentOS ma wiele funkcji jądra 4.x przeniesionego z powrotem. Ale wydaje się, że istnieje linia między 4,4 a 4,9, która wpłynęła na dziwnie niskie wartości Committed_AS. Dodane serwery od niektórych moich rówieśników sugerują, że Committed_AS dostarcza również dziwne liczby dla starszych jąder. Czy zostało to zepsute i naprawione wiele razy?
Czy ludzie mogą to potwierdzić? Czy jest to po prostu błędne / bardzo niedokładne zachowanie jądra przy określaniu wartości w / proc / meminfo, czy też istnieje historia błędów (poprawek)?
Niektóre wpisy na liście są naprawdę dziwne. Posiadanie jednego procesu slurmdbd z czterokrotnym kanałem RSS Committed_AS nie może być poprawne. Kusi mnie, aby przetestować jądro wanilii na tych systemach z takim samym obciążeniem, ale nie mogę wycofać z produkcji najbardziej interesujących maszyn dla takich gier.
Wydaje mi się, że odpowiedź na moje pytanie jest wskaźnikiem poprawki w historii zatwierdzeń jądra, która ponownie umożliwiła dobre oszacowania w Committed_AS. W przeciwnym razie proszę, oświeć mnie ;-)