Linux nie zwalnia dużej pamięci podręcznej dysku, gdy rośnie zapotrzebowanie na pamięć


24

Uruchamianie Ubuntu na jądrze 2.6.31-302 x86-64. Ogólny problem polega na tym, że mam pamięć w kategorii „buforowanej”, która ciągle rośnie i nie zostanie zwolniona ani wykorzystana, nawet jeśli nasza aplikacja jej potrzebuje.

Oto, co wyciągam z polecenia „darmowego”. Na pierwszy rzut oka nic z tego nie wygląda nietypowo.

# free
             total       used       free     shared    buffers     cached
Mem:       7358492    5750320    1608172          0       7848    1443820
-/+ buffers/cache:    4298652    3059840
Swap:            0          0          0

Pierwszą rzeczą, którą ktoś powie, jest: „Nie martw się, Linux automatycznie zarządza pamięcią”. Tak, wiem, jak powinien działać menedżer pamięci; problem polega na tym, że nie robi to dobrze. „Buforowana” 1,4 GB tutaj wydaje się być zarezerwowana i nie nadaje się do użytku.

Znajomość Linuksa mówi mi, że 3 GB jest „darmowe”; ale zachowanie systemu mówi inaczej. Gdy 1,6 GB rzeczywistej wolnej pamięci zostanie zużyte podczas szczytowego użycia, gdy tylko zajdzie potrzeba zwiększenia ilości pamięci (a „wolna” w pierwszej kolumnie zbliża się do 0), wywoływany jest zabójca OOM, procesy są zabijane i pojawiają się problemy nawet jeśli „wolny” w rzędzie buforów - / + / cache wciąż ma około 1,4 GB „wolnego”.

Dostosowałem wartości oom_adj do kluczowych procesów, aby nie rzucało systemu na kolana, ale nawet wtedy ważne procesy zostaną zabite i nigdy nie chcemy osiągnąć tego punktu. Zwłaszcza, gdy teoretycznie 1,4 GB jest nadal „darmowe”, jeśli tylko eksmituje pamięć podręczną dysku.

Czy ktoś ma pojęcie, co się tutaj dzieje? Internet jest zalany głupimi pytaniami o komendę Linuksa „wolną” i „dlaczego nie mam wolnej pamięci” i dlatego nie mogę znaleźć nic na ten temat.

Pierwszą rzeczą, która pojawia się w mojej głowie, jest to, że swap jest wyłączony. Mamy sysadmina, który jest nieugięty; Jestem otwarty na wyjaśnienia, jeśli mają kopie zapasowe. Czy to może powodować problemy?

Oto bezpłatne po uruchomieniu echo 3 > /proc/sys/vm/drop_caches:

# free
             total       used       free     shared    buffers     cached
Mem:       7358492    5731688    1626804          0        524    1406000
-/+ buffers/cache:    4325164    3033328
Swap:            0          0          0

Jak widać, niewielka ilość pamięci podręcznej jest faktycznie zwolniona, ale wydaje się, że około 1,4 GB „utknęło”. Innym problemem jest to, że wartość ta wydaje się z czasem rosnąć. Na innym serwerze 2,0 GB utknęło.

Naprawdę chciałbym odzyskać to wspomnienie ... każda pomoc byłaby najbardziej doceniana.

Oto, cat /proc/meminfoczy coś jest warte:

# cat /proc/meminfo 
MemTotal:        7358492 kB
MemFree:         1472180 kB
Buffers:            5328 kB
Cached:          1435456 kB
SwapCached:            0 kB
Active:          5524644 kB
Inactive:          41380 kB
Active(anon):    5492108 kB
Inactive(anon):        0 kB
Active(file):      32536 kB
Inactive(file):    41380 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:               320 kB
Writeback:             0 kB
AnonPages:       4125252 kB
Mapped:            42536 kB
Slab:              29432 kB
SReclaimable:      13872 kB
SUnreclaim:        15560 kB
PageTables:            0 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     3679244 kB
Committed_AS:    7223012 kB
VmallocTotal:   34359738367 kB
VmallocUsed:        7696 kB
VmallocChunk:   34359729675 kB
DirectMap4k:     7340032 kB
DirectMap2M:           0 kB

3
Nie mam żadnego wyjaśnienia dla twojej pamięci podręcznej (chociaż podejrzewam, że prawdopodobnie trafiają do niej pliki mmap), ale dla dobra ludzkości weź łopatę i trochę wapna i pozbądź się „nie potrzebujesz wymiany jeśli masz dużo pamięci RAM! ” Wzmacniacz. Są odporni na racjonalną dyskusję i niebezpiecznie się mylą. Fakt, że prześladuje cię zabójca OOM, jest tylko jednym z objawów tego.
womble

Dokładnie moje myśli. Dzięki za radę. Czy znasz inne dobre artykuły lub argumenty, dlaczego zamiana jest konieczna?
trisweb,

6
Ponieważ jeśli nie masz zamiany, takie rzeczy się zdarzają. Ale nie zawracaj sobie głowy próbowaniem sprzeczania się ze swoim zaprzeczaczem wymiany; albo wyłamać palonego lub powiedzieć „jeśli nie chcesz na zamianę tu Państwo rozwiązać ten bałagan pan nalegał na stworzenie”. Albo w końcu sami zmienią zdanie, albo umrą próbując. Problem rozwiązany w obu kierunkach.
womble

Doskonale, dziękuję za wskazówki. Nawiasem mówiąc, miałeś rację co do plików mmap - szybki lsof pokazał mnóstwo plików dziennika zajmujących pamięć. Usunięcie ich rozwiązało problem.
trisweb

Problem polega na tym, że bez zamiany nadmierne zaangażowanie powoduje, że zabójca OOM działa, a nie nadmierne zobowiązanie powoduje, że system nie może uruchomić procesów. Potrzebujesz efektywnej wymiany pamięci RAM.
David Schwartz

Odpowiedzi:


8

Znalazłem odpowiedź na moje własne pytanie - dzięki pomocy womble (prześlij odpowiedź, jeśli chcesz).

lsof -s pokazuje używane uchwyty plików i okazuje się, że pamięć podręczna zajmowała kilka gigabajtów plików dziennika mmap'd.

Wdrożenie logrotate powinno całkowicie rozwiązać problem i pozwolić mi skorzystać z większej ilości pamięci.

Ponownie włączę zamianę, abyśmy nie mieli problemów z zabójcą OOM w przyszłości. Dzięki.


2
strony mmap'd są usuwalne, więc nie powinny powodować przypięcia pamięci podręcznej. Czy używasz ramfs?
psusi

Cześć, przepraszam, że wykopałem stary wątek, ale mam obecnie ten sam problem i lsof -snie pokazuję żadnego niezwykłego użycia. Jednak używam ramfs, jak powiedziałeś [i jądra 2.6.10, które nie ma funkcji drop_caches]. Jak myślisz, co jest podejrzanym?
Ram

1
Dzięki za wskazówkę! Teraz dodaję lsof -s | sort -rnk 7 | lessdo mojego zestawu narzędzi. Uwaga dla innych czytelników: mogą to być duże wpisy /proc/net/rpc/nfs4.nametoid/channel, ale nie okazały się winowajcą w moim przypadku.
Nickolay

upewnij się, że twoje duże pliki lub programy nie używają mlock. w /proc/meminfospojrzeniu na „Unevictable” stron.
Michael Martinez,

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.