Linux не освобождает большой кеш диска, когда увеличивается спрос на память

Запуск Ubuntu на ядре 2.6.31-302 x86-64. Общая проблема заключается в том, что у меня есть память в категории "кэшированная", которая продолжает увеличиваться и не будет освобождена или использована даже тогда, когда это требуется нашему приложению.

Так вот что я получаю из "свободной" команды. Ничто из этого не выглядит необычным на первый взгляд.

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

Первое, что кто-то скажет: "Не волнуйтесь, Linux управляет этой памятью автоматически". Да, я знаю, как должен работать диспетчер памяти; проблема в том, что это не правильно делает. "Кэшированные" 1,4 ГБ здесь зарезервированы и непригодны для использования.

Мое знание Linux говорит мне, что 3 ГБ "бесплатно"; но поведение системы говорит об обратном. Когда 1,6 ГБ реальной свободной памяти израсходовано во время пикового использования, как только требуется больше памяти (а "свободный" в первом столбце приближается к 0), вызывается убийца ООМ, процессы уничтожаются, и начинаются проблемы даже несмотря на то, что "free" в строке -/+ buffers/cache все еще имеет около 1,4 ГБ "free".

Я настроил значения oom_adj для ключевых процессов, чтобы они не поставили систему на колени, но даже тогда важные процессы будут убиты, и мы никогда не хотим достичь этой точки. Особенно, когда теоретически 1,4 ГБ по-прежнему "свободны", если бы они только вытеснили кеш диска.

Кто-нибудь знает, что здесь происходит? Интернет наводнен тупыми вопросами о команде Linux "free" и "почему у меня нет свободной памяти", и из-за этого я ничего не могу найти по этой проблеме.

Первое, что приходит мне в голову, это то, что своп отключен. У нас есть системный администратор, который непреклонен в этом; Я открыт для объяснений, если они поддерживаются. Может ли это вызвать проблемы?

Здесь бесплатно после запуска 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

Как видите, крошечный объем кеша фактически освобожден, но около 1,4 ГБ кажется "зависшим". Другая проблема состоит в том, что это значение, кажется, растет со временем. На другом сервере зависло 2,0 ГБ.

Я бы очень хотел вернуть это воспоминание... любая помощь была бы очень признательна.

Вот cat /proc/meminfo если это чего-то стоит

# 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 ответа

Решение

Я нашел ответ на свой вопрос - благодаря помощи Womble (отправьте ответ, если хотите).

lsof -s показывает используемые файловые дескрипторы и оказывается, что в кэш занято несколько гигабайт файлов журнала mmap.

Реализация logrotate должна полностью решить проблему и позволить мне использовать больше памяти.

Я также повторно включу своп, чтобы у нас не было проблем с OOM killer в будущем. Благодарю.

Видимо, postgres' shared_buffers может появиться в cachedв то время как на самом деле это не так просто сбросить... Посмотрите OOM, несмотря на доступную память

Я столкнулся с аналогичной проблемой, когда выбор файловой системы был неправильным. Переключение наxfsсистема от решила эту проблему. tmpfsсистема использовала всю оперативную память в качестве кэша страниц, что в конечном итоге привело к завершению моего процесса убийцей OOM.

Другие вопросы по тегам