Ten pogląd może być bardzo mylący w wielu rzeczywistych przypadkach.
Jądro zapewnia teraz oszacowanie dostępnej pamięci w MemAvailable
terenie. Ta wartość znacznie różni się od MemFree + Cached
.
/ proc / meminfo: zapewnia szacunkową dostępną pamięć [opis zmiany jądra, 2014]
Wiele programów do równoważenia obciążenia i umieszczania obciążenia sprawdza / proc / meminfo, aby oszacować, ile wolnej pamięci jest dostępne. Na ogół robią to, dodając „darmowy” i „buforowany”, co było w porządku dziesięć lat temu, ale jest prawie pewne, że dzisiaj się myli.
Jest to błędne, ponieważ pamięć podręczna obejmuje pamięć, której nie można zwolnić jako pamięć podręczną strony, na przykład segmenty pamięci współużytkowanej, tmpfs i ramfs, i nie obejmuje pamięci płyty, którą można odzyskać, która może zajmować dużą część pamięci systemowej w większości bezczynnych systemów z dużo plików.
Obecnie ilość pamięci dostępnej dla nowego obciążenia, bez popychania systemu do zamiany, można oszacować na podstawie MemFree, Active (plik), Inactive (plik) i SReclaimable, a także „niskich” znaków wodnych z / proc / zoneinfo. Może się to jednak zmienić w przyszłości i naprawdę nie należy oczekiwać, że przestrzeń użytkownika zna wewnętrzne jądra w celu oszacowania ilości wolnej pamięci. Bardziej wygodne jest podanie takiego oszacowania w / proc / meminfo. Jeśli coś się zmieni w przyszłości, musimy to zmienić tylko w jednym miejscu.
...
Dokumentacja / systemy plików / proc.txt:
...
MemAvailable: Szacunkowa ilość pamięci dostępnej do uruchamiania nowych aplikacji, bez zamiany. Obliczony na podstawie MemFree, SReclaimable, rozmiar list LRU pliku i niskie znaki wodne w każdej strefie. Szacunek bierze pod uwagę, że system potrzebuje pewnej pamięci podręcznej stron, aby dobrze funkcjonować, i że nie wszystkie płyty, które można odzyskać, będą możliwe do odzyskania z powodu wykorzystywania elementów. Wpływ tych czynników będzie się różnił w zależności od systemu.
1. Szczegóły MemAvailable
Jak wspomniano powyżej, tmpfs i inna Shmem
pamięć nie mogą zostać zwolnione, a jedynie przeniesione do zamiany. Cached
w /proc/meminfo
może być bardzo mylące, w tym ze względu na to swap Shmem
pamięci. Jeśli masz zbyt wiele plików w tmpfs, może to zajmować dużo pamięci :-). Shmem
może również obejmować niektóre przydziały pamięci graficznej , które mogą być bardzo duże.
MemAvailable
celowo nie obejmuje pamięci wymiennej. Zbyt duża zamiana może powodować duże opóźnienia. Być może zdecydowałeś się uruchomić bez przestrzeni wymiany, lub zezwoliłeś tylko na względnie ograniczoną ilość.
Musiałem dokładnie sprawdzić, jak MemAvailable
działa. Na pierwszy rzut oka wydaje się, że kod nie wspomina o tym rozróżnieniu.
/*
* Not all the page cache can be freed, otherwise the system will
* start swapping. Assume at least half of the page cache, or the
* low watermark worth of cache, needs to stay.
*/
pagecache = pages[LRU_ACTIVE_FILE] + pages[LRU_INACTIVE_FILE];
pagecache -= min(pagecache / 2, wmark_low);
available += pagecache;
Stwierdziłem jednak, że poprawnie traktuje Shmem
jako pamięć „używaną”. Utworzyłem kilka plików 1GB w tmpfs. Każdy wzrost o 1 GB Shmem
zmniejsza się MemAvailable
o 1 GB. Zatem rozmiar „list LRU pliku” nie obejmuje pamięci współdzielonej ani żadnej innej pamięci wymiennej. (Zauważyłem, że te same liczby stron są również używane w kodzie obliczającym „brudny limit” ).
Ta MemAvailable
kalkulacja zakłada również, że chcesz zachować przynajmniej na tyle, aby dorównać pamięci podręcznej plików jądra „niski” znak wodny. Lub połowa bieżącej pamięci podręcznej - w zależności od tego, która wartość jest mniejsza. (To samo dotyczy również płyt podlegających zwrotowi). „Niski znak wodny” jądra można dostroić, ale zwykle jest to około 2% pamięci RAM systemu . Więc jeśli chcesz tylko z grubsza oszacować, możesz zignorować tę część :-).
Jeśli korzystasz firefox
z około 100 MB kodu programu zmapowanego w pamięci podręcznej strony, zazwyczaj chcesz zachować to 100 MB w pamięci RAM :-). W przeciwnym razie w najlepszym wypadku wystąpią opóźnienia, w najgorszym przypadku system będzie spędzał cały czas na rzucaniu się między różnymi aplikacjami. Pozwala więc na MemAvailable
to niewielki procent pamięci RAM. Może to nie wystarczać lub może być zbyt hojne. „Wpływ tych czynników będzie się różnił w zależności od systemu”.
W przypadku wielu obciążeń komputerów punkt „wiele plików” może nie być istotny. Mimo to mam obecnie 500 MB pamięci do odzyskania na płycie w moim laptopie (z 8 GB pamięci RAM). Wynika to z ext4_inode_cache
(ponad 300 000 obiektów). Stało się tak, ponieważ ostatnio musiałem przeskanować cały system plików, aby znaleźć, co wykorzystuje moje miejsce na dysku :-). Użyłem polecenia df -x / | sort -n
, ale np. Gnome Disk Usage Analyzer zrobiłby to samo.
2. [edycja] Pamięć w grupach kontrolnych
Tak zwane „Linux” pojemniki są zbudowane z namespaces
, cgroups
i różne inne funkcje, w zależności od gustu :-). Mogą zapewnić wystarczająco przekonujące środowisko, aby uruchomić coś prawie jak pełny system Linux. Usługi hostingowe mogą budować takie kontenery i sprzedawać je jako „serwery wirtualne” :-).
Serwery hostingowe mogą również budować „serwery wirtualne” przy użyciu funkcji, których nie ma w głównym Linuksie. Kontenery OpenVZ wcześniej datują grupy główne o dwa lata i mogą używać „beancounters” w celu ograniczenia pamięci. Nie możesz więc dokładnie zrozumieć, jak działają te limity pamięci, jeśli czytasz tylko dokumenty lub zadajesz pytania dotyczące głównego jądra Linuksa. cat /proc/user_beancounters
pokazuje aktualne użycie i ograniczenia. vzubc
prezentuje go w nieco bardziej przyjaznym formacie. Strona główna beancounters dokumentuje nazwy wierszy.
Grupy kontrolne obejmują możliwość ustawiania limitów pamięci dla procesów w nich zawartych. Jeśli uruchomisz aplikację w takiej grupie, nie cała pamięć systemowa będzie dostępna dla aplikacji :-). Jak więc widzimy dostępną pamięć w tym przypadku?
Interfejs do tego różni się na wiele sposobów, w zależności od tego, czy używasz cgroup-v1 czy cgroup-v2 .
Instalacja mojego laptopa używa cgroup-v1. Mogę uruchomić cat /sys/fs/cgroup/memory/memory.stat
. Z akt sprawy wynika wielu dziedzinach, takich total_rss
, total_cache
, total_shmem
. shmem, w tym tmpfs, wlicza się do limitów pamięci. Myślę, że można spojrzeć na total_rss
odwrotny odpowiednik MemFree
. Jest też plik memory.kmem.usage_in_bytes
reprezentujący pamięć jądra, w tym płyty. (Zakładam, że memory.kmem.
zawiera także memory.kmem.tcp.
wszelkie przyszłe rozszerzenia, chociaż nie jest to wyraźnie udokumentowane). Nie ma osobnych liczników, aby wyświetlić pamięć płyty, którą można odzyskać. Dokument dla cgroup-v1 mówi, że przekroczenie limitów pamięci nie powoduje odzyskania żadnej pamięci płyty. (Dokument zawiera również oświadczenie, że jest „beznadziejnie nieaktualny” i że powinieneś sprawdzić aktualny kod źródłowy).
cgroup-v2 jest inny. Myślę, że grupa główna (najwyższego poziomu) nie obsługuje rozliczania pamięci. cgroup-v2 nadal ma memory.stat
plik. Wszystkie pola sumują się nad grupami podrzędnymi, więc nie trzeba szukać total_...
pól. Istnieje file
pole, co oznacza, że to samo cache
zrobiło. Irytujące nie widzę takiego pola jak w rss
środku memory.stat
; Myślę, że musiałbyś zsumować poszczególne pola. Istnieją osobne statystyki dla pamięci płyty, którą można odzyskać i której nie można odzyskać; Myślę, że grupa cg2 v2 została zaprojektowana do odzyskiwania płyt, gdy zaczyna brakować pamięci.
Grupy linuksowe nie wirtualizują się automatycznie /proc/meminfo
(ani żadnego innego pliku /proc
), więc pokazywałyby wartości dla całego komputera. Myliłoby to klientów VPS. Można jednak użyć przestrzeni nazw, aby zastąpić /proc/meminfo
plikiem sfałszowanym przez określone oprogramowanie kontenera . Jak przydatne są fałszywe wartości, zależy od tego, co robi to konkretne oprogramowanie.
systemd
uważa, że cgroup-v1 nie może być bezpiecznie delegowany np. do kontenerów. systemd-nspawn
Zajrzałem do pojemnika w moim systemie cgroup-v1. Widzę grupę, w której został umieszczony, i pamięć na tym. Z drugiej strony zawarte systemd
nie tworzy zwykłych grup usług dla rozliczania zasobów. Jeśli rozliczanie pamięci nie zostało włączone w tej grupie, zakładam, że kontener nie będzie mógł go włączyć.
Zakładam, że jeśli jesteś w kontenerze cgroup-v2, będzie on wyglądał inaczej niż katalog główny prawdziwego systemu cgroup-v2 i będziesz w stanie zobaczyć pamięć odpowiadającą za grupę cgroup najwyższego poziomu. Lub jeśli cgroup, którą widzisz, nie ma włączonego rozliczania pamięci, mam nadzieję, że będziesz miał uprawnienia delegowane, aby móc włączyć rozliczanie pamięci wsystemd
(lub równoważnym).
MemAvailable
, został dodany w wersji 3.14.