Запуск 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), вызывается убийца OOM, процессы прекращаются, и начинают возникать проблемы. даже если «свободный» в строке - / + buffers / cache по-прежнему имеет около 1,4 ГБ «свободного».
Я настроил значения oom_adj для ключевых процессов, чтобы он не ставил систему на колени, но даже в этом случае важные процессы будут убиты, и мы никогда не хотим достичь этой точки. Особенно, когда теоретически 1,4 ГБ все еще «бесплатно», если это приведет только к вытеснению дискового кеша.
Кто-нибудь знает, что здесь происходит? Интернет наводнен глупыми вопросами о «бесплатной» команде Linux и «почему у меня нет свободной памяти», и из-за этого я ничего не могу найти по этой проблеме.
Первое, что приходит мне в голову, что своп отключен. У нас есть системный администратор, который непреклонен в этом; Я открыт для объяснений, если они поддерживаются. Могло ли это вызвать проблемы?
Вот бесплатно после запуска 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
Я нашел ответ на свой вопрос - благодаря помощи womble (отправьте ответ, если хотите).
lsof -s показывает используемые дескрипторы файлов, и оказывается, что несколько гигабайт файлов журнала mmap занимали кеш.
Реализация logrotate должна полностью решить проблему и позволить мне использовать больше памяти.
Я также повторно включу своп, чтобы у нас не было проблем с убийцей OOM в будущем. Спасибо.
По-видимому, postgres'ом shared_buffers может появиться в cached, хотя его нелегко выбросить ... См. OOM, несмотря на доступную память (кеш)