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.