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

24

Запуск 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
linux memory memory-usage disk-cache trisweb
источник
3
У меня нет никакого объяснения для вашего кеша (хотя я подозреваю, что файлы mmap'd, вероятно, входят в него), но на благо человечества, возьмите лопату и немного негашеной извести и избавьтесь от «вам не нужен обмен если у вас много оперативной памяти! ракета - носитель. Они невосприимчивы к рациональному обсуждению и опасно ошибаются. Тот факт, что убийца ООМ преследует вас, является лишь одним из признаков этого.
womble
Мои мысли точно. Спасибо за совет. Знаете ли вы какие-либо другие хорошие статьи или аргументы о том, почему обмен необходим?
августа
6
Потому что, если у вас нет свопа, такие вещи случаются. Но не пытайтесь спорить со своим отрицателем свопа; либо вырваться из негашеной или сказать «если вы не хотите подкачки здесь, вы исправить этот беспорядок вы настояли на создании». Они либо сами в конце концов передумают, либо умрут, пытаясь. Проблема решена в любом случае.
Вомбл
Отлично, спасибо за советы. Кстати, вы были правы насчет файлов mmap - быстрый lsof показал, как файлы журналов занимают память. Удаление их решило проблему.
trisweb
Проблема заключается в том, что без перестановки избыточное завершение приводит к запуску OOM killer, а не чрезмерное завершение приводит к тому, что система не может запускать процессы. Вам нужно поменяться, чтобы эффективно использовать оперативную память.
Дэвид Шварц

Ответы:

8

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

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

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

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

trisweb
источник
2
Страницы mmap'd удаляются, поэтому кеш не должен быть закреплен. Вы используете ramfs?
Псуси
Привет, извините, что выкопал старую ветку, но сейчас я сталкиваюсь с той же проблемой и lsof -sне вижу необычного использования Тем не менее, я использую ramfs, как вы сказали [и ядро ​​2.6.10, у которого нет функции drop_caches]. Как вы думаете, это вероятный подозреваемый?
Рам
1
Спасибо за совет! Я добавляю lsof -s | sort -rnk 7 | lessв свой набор инструментов сейчас. Примечание для других читателей: это могут понравиться большие записи /proc/net/rpc/nfs4.nametoid/channel, но они не оказались виновником в моем случае.
Николай
убедитесь, что ваши большие файлы или программы не используют mlock. в /proc/meminfoвзгляде на "Неуязвимые" страницы.
Майкл Мартинес