Большая часть памяти занята кешами, работает oom_killer, drop_caches не дает эффекта

что делать?

Я думаю, что проще всего будет добавить свопа.

При 16 ГБ свободной памяти? Сомнительно.

При 16 ГБ свободной памяти?

При невозможности выделить 8К.

+1

Тебе не кажется, что если кто-то внезапно отожрал 16 ГБ рамы, то стоит разобраться, кто это был и почему он себя так повел? А добавление свопа - это симптоматическое лечение, которое, скорее всего, не будет работать.

Своп был. Тогда вместо тормозов от нехватки памяти были тормоза из-за активного перемещения кеша в своп и обратно

на фоне общей нехватки памяти. Картина примерно следующая:

Не вижу нехватки памяти.

free -m
             total       used       free     shared    buffers     cached
Mem:          3892       3775        117          2        601       2621
-/+ buffers/cache:        552       3339
Swap:         5844          0       5844

как и в этом случае

Тебе не кажется, что если кто-то внезапно отожрал 16 ГБ рамы, то стоит разобраться, кто это был и почему он себя так повел?

Мне кажется, что в логах есть вот это:

[1797823.696096] Node 0 Normal free:52584kB

И если в таких условиях при fork невозможно выделить 8КБайт, дело, скорее всего, в фрагментации. Использование свопа - способ ее обойти.

А разобраться, конечно, стоит. Только вряд ли мы сумеем это сделать.

перемещения кеша в своп и обратно

Эм. Зачем дублировать данные из кеша на диск?

Своп был. Тогда вместо тормозов от нехватки памяти были тормоза из-за активного перемещения кеша в своп и обратно

(пожимая плечами) Выбирай, что для тебя лучше: OOM или свопинг.

большая часть памяти занята кешами
перемещения кеша в своп и обратно

Про то, что такое кеши, читаем здесь: http://www.linuxatemyram.com/ (кратко: Линукс хранит кеши ФС в свободной памяти, при необходимости выделить память, кеши выбрасываются; в своп кеши не пишутся; у тебя доступно для программ еще 13 ГБ из 16).

Причин для запуска oom_killer я не вижу, рамы у тебя очень много. Возможно, имел место принудительный запуск (что маловероятно, но все же). Проверь, что это за скрипт covertart.sh, во время работы которого произошел oom_killer.

Посмотри, кто у тебя активнее всех потребляет CPU (top) и диск (iotop).

невозможно выделить 8КБайт

Откуда ты знаешь, что был запрос на выделение 8КБ? Подскажи, где это написано.

дело, скорее всего, в фрагментации.

Фрагментации чего?

Я не знаю, зачем ядро это делает. Возможно, оно вместо того, чтобы вытеснить кеши из памяти и занять ее чем-нибудь полезным, вытесняло полезные данные на диск, а кеши не трогало. Но тормоза были, своп активно использовался до момента заполнения, а потом включался тот же oom_killer. Никакое приложение в момент его работы не ело память, более 10ГБ было всегда занято кешами.

Про то, что такое кеши, читаем здесь: http://www.linuxatemyram.com/ (кратко: Линукс хранит кеши ФС в свободной памяти, при необходимости выделить память, кеши выбрасываются; в своп кеши не пишутся; у тебя доступно для программ еще 13 ГБ из 16).

Гладко было на бумаге... Недоступны для программ эти 13ГБ и даже через drop_caches не освобождаются, в этом вся суть треда

А скрипт coverart.sh безобидный, там нечему память есть - ему просто не повезло :)

(пожимая плечами) Выбирай, что для тебя лучше: OOM или свопинг.

Мне не нужен ни oom, ни своппинг - у меня 13ГБ свободной памяти - я хочу, чтобы она была доступна приложениям, а не лежала мертвым грузкешем

А проверь, на всякий случай, нет ли у тебя какого-нибудь ramfs, забитого под завязку. Вроде /tmp и тому подобных. Что говорят cat /proc/mounts и df -h?

Несколько примонтированных tmpfs есть, но там было суммарно мегабайт 50 - я сразу проверил :)

Как трактовать строку «Shmem: 13075100 kB» в /proc/meminfo?

Откуда ты знаешь, что был запрос на выделение 8КБ?

[1797823.695987] coverart.sh invoked oom-killer: gfp_mask=0x3000d0, order=1, oom_score_adj=0

оrder=1 - это 2 страницы, 8К.

я хочу, чтобы она была доступна приложениям, а не лежала мертвым грузкешем

Покрути swappiness. Но своп тебе всё равно нужен, чтобы обойти фрагментацию.

Крутил swappiness, она дает только отсрочку oom_killer-a. При активном случайном чтении 2ТБ данных дисковые кеши неуклонно растут - надо их как-то перевоспитать, чтобы они своевременно освобождали оперативку, когда та нужна приложениям, иначе никакого свопа не напасешься.

Крутил swappiness, она дает только отсрочку oom_killer-a

Ты крутил swappiness без свопа, или у тебя даже со свопом срабатывает OOM killer?

Как я понимаю, кто-то выжирает shared memory (в выводе free это же значение показывается в колонке «shared», но в том, что ты постил выше, там был 0). Перепроверь показания free и посмотри, какой процесс у тебя использует так много shared memory.

Даже со свопом. Только ждать приходится дольше и мучительнее - пока своп заполнится под завязку, все дико тормозит, но если набраться терпения, можно дождаться oom_killer

Цитата из man free: «The shared memory column should be ignored; it is obsolete.» Так что надо смотреть только на meminfo:

[sio@hugetower] /home/sio/
# grep Shmem /proc/meminfo
Shmem:          13080504 kB


[sio@hugetower] /home/sio/
# ipcs -m      

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x00000000 1474560    sio        600        393216     2          dest         
0x00000000 3244033    sio        600        393216     2          dest         
0x00000000 3276802    sio        600        393216     2          dest         
0x00000000 3309571    sio        600        393216     2          dest         
0x00000000 3342340    sio        600        393216     2          dest         
0x00000000 3375109    sio        600        393216     2          dest         
0x00000000 915341318  sio        600        393216     2          dest  

tmpfs, повторюсь, есть, но пустые

Если своп за некоторое время заполняется, вывод очевиден - что-то течет.

Спасибо, кэп! А если 16 гиг рамы за некоторое время заполняются, то вывод не очевиден?

А если 16 гиг рамы за некоторое время заполняются, то вывод не очевиден?

Нет. И посмотри уже на dmesg - там доходчиво.

посмотри уже на dmesg - там доходчиво.

посмотрел очень внимательно, увидел вот это: «shmem:3291517» (==13 ГБ). О том же рассказывает /proc/meminfo.

А теперь скажи мне, убогому, где искать эти 13 ГБ, и при помощи какой магии включение свопа решит проблему, а не просто оттянет ее до тех пор, пока своп не забьется?

Еще одна сумасшедшая идея: прогони sudo lsof на tmpfs. Твои симптомы воспроизводятся с удаленными, но все еще открытыми, файлами. Может какой процесс чего открыл, удалил, да забыл закрыть?

Прогнал, среди открытых только существующие файлы.

посмотрел очень внимательно, увидел вот это: «shmem:3291517» (==13 ГБ)

Про shmem уже сказали выше.

А теперь скажи мне, убогому, где искать эти 13 ГБ

Окей, но это последний раз. Вот искомые 13ГБ.:

[1797823.696127] 3291810 total pagecache pages

и при помощи какой магии включение свопа решит проблему

Если проблема связана с фрагментацией, то свопинг может ее уменьшить.

tpmfs ограничь метров на 200
видимо бага ядра
потыкай другую версию ядра

Ок, кеш большой из-за активного чтения с диска. Почему он своевременно не освобождается, когда память нужна приложениям?

tmpfs не заполнена. Проблема наблюдается на всех ядрах, прошедших бэкпорты дебиана за последние полгода

Вот искомые 13ГБ
невозможность выделить 8К
проблема связана с фрагментацией

1) Фрагментация чего? Дай ссылку, где про это почитать.
2) Есть какие-то веские основания полагать, что проблема именно в этом? Занято всего порядка 20% памяти. Это должна быть какая-то очень адовая фрагменатция, чтобы в остальных 80% не нашелся цельный блок из двух страниц.

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

То, что он «своевременно не освобождается», ты заключил из OOM?

Да. Какие еще я мог сделать выводы?

а ты попробуй
занеси в fstab size=200m и reboot

Какие еще я мог сделать выводы?

Фрагментация, как я; ошибка ядра или заполнение tmpfs, как ubuntuawp.

+1 Проблема в больших файлах в tmpfs.

Я переписывал 1Гб файл с флэшки в tmpfs, кэш возрос, а в tmpfs показывало что, файл занимает несколько Мб. Я сначала думал, что файл не прочитался, но когда записал на жесткий диск, размер оказался нормальным.

Shmem как раз говорит об этом.

Параметры tmpfs крутить тут.

/etc/default/tmpfs

Фрагментация, как я

О какой такой фрагментации ты все время говоришь? Дай уже наконец ссылку, где можно об этом почитать. И какие у тебя есть основания предполагать фрагментацию при 80% свободной памяти?

заполнение tmpfs

Проверили же уже, ничего не нашли.

ошибка ядра

ТС пробовал разные версии ядра. Если ошибка давняя и легко воспроизводится, то почему ее еще не починили? А если ошибка проявляется только в определенных условиях, хочется понять, в каких именно.

Мне все еще на дает покоя идея про tmpfs. Попробуй их отмонтировать по одной (в single user mode, если потребуется). Может внезапно обнаружится, что одна из них все-таки держала всю память? А если нет, то по крайней мере, можно будет окончательно снять подозрения с tmpfs/ramfs и начать копать в другом направлении.

заполнение tmpfs

Проверили же уже, ничего не нашли.

Пусть скажет как проверял.

Свои tmpfs (за исключением стандартных от дистрибутива) я так и проверял.

Сегодня утром почти случайно удалось освободить эти 13ГБ shmem без перезагрузки: когда, убив по одному все сколько-нибудь активные приложения (после каждого делая sync и drop_caches), я сдался и собрался было перезагрузиться, я вышел из иксов и наудачу сделал те же sync + drop_caches. Счетчик shmem обнулился.

Последним шагом были остановлены X, fluxbox, conky (3 инстанции), xxkb, urxvtd, xscreensaver и два маленьких самописных скрипта. Сейчас иксы запущены снова, буду ждать накопления мусора в shmem и убивать этих по одному. Наибольшие подозрения у меня вызывает xscreensaver (он 18 часов в сутки крутит слайдшоу из фотографий), следующий на очереди urxvtd.

Как только узнаю что-то новое - отпишусь здесь.

И никто не вспомнил про zram...

urxvtd

кстати сколько он провисел запущенным? у меня под генту оно потихонечку текло..

а проблемма воспроизводится на раз-два или нужны специфические условия?

Проблема воспроизводится при обычном использовании, но медленно - через две недели обычно на глаз ничего еще не заметно - а там, глядишь, и новое ядро выпускают :)

Urxvtd был запущен те же 20 дней, что и компьютер.

У меня тоже на дебиане оно течет, при любой попытке обращения к миллионам мелких файлов в ext4. Пытался бороться, потом забил.

У меня тоже на дебиане оно течет, при любой попытке обращения к миллионам мелких файлов в ext4

Еще один специалист по системному программированию...