LINUX.ORG.RU

Переполнение кэша оперативной памяти

 , , , ,


0

1

Есть кластер с RHEL 6.

  • ФС – gpfs;
  • Процессор – 24хядерные Intel Xeon;
  • Оперативка – 128 Гб;
  • Диски HDD серверные.

Запускается задача явной динамики с массивной записью данных каждого шага на диск. Через какое-то время переполняется кэш оперативной памяти и задача падает с ООМ.

Если запускать на нескольких узлах, то задача падает быстрее. Если запускать на одном узле – падает гораздо позже. На стационарном компьютере (Windows 7, i7-7700k, 64 Гб оперативы, HDD) задача не падает, но считается, очевидно, медленно.

На мой дилетантский взгляд бутылочное горло – дисковая подсистема: производительность нескольких узлов гораздо выше пропускной способности дисков и поэтому «сгенерированные» расчётные данные не успевают записываться на диск; снижаем вычислительную мощность и проблема пропадает.

Вопросы:

  • Верно ли моё предположение?
  • Какой самый дешёвый (желательно без покупки нового железа, т.е. программный) и простой (у нас тут все по части Linux дилетанты) способ решить проблему?

P.S. Кроме как уменьшать периодичность записи данных в голову ничего не идёт, но это не очень желательно.

Ответ на: комментарий от anonymous

Не совсем понимаю, как это должно повлиять на работу. По моим прикидкам выходит, что как увеличение, так и уменьшение значения не приведёт к улучшению работы программы:

  • Уменьшение значения dirty_ratio приведёт к тому, что при заполнении меньшего (чем ранее) объёма памяти начнётся запись на диск, что приведёт к тому, что операции I/O заблокируются раньше и память закончится быстрее.

  • Увеличение dirty_ratio позволит загрузить в кэш больше данных, но т.к. скорость записи на диск не увеличивается кэш просто займёт больше памяти, чем ранее и в итоге задача завершится либо так же, как и с исходным значением dirty_ratio, либо раньше, потому что больше памяти занято кэшем.

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

Если моя догадка про бутылочное горлышко неверна, то как поведёт себя программа при увеличении / уменьшении параметра dirty_ratio?

the_real_kinik ()
Ответ на: комментарий от AnDoR

Рекомендую перенести в Jobs.

Ожидал этого комментария, но нанять стороннего специалиста для решения проблемы будет проблематично.

Предприятие режимное, отсюда и ограничения:

  • будет предшествовать куча бюрократической волокиты;
  • сеть наружу никто не откроет, админу придётся ехать на место;
  • вряд ли руководство предложит оплату, достаточную для того, чтобы мотивировать хорошего специалиста забить на предыдущие два пункта.

Поэтому будем разбираться сами, благо сроки не поджимают.

the_real_kinik ()

Какой самый дешёвый (желательно без покупки нового железа, т.е. программный) и простой (у нас тут все по части Linux дилетанты) способ решить проблему?

Своп на ссд.

Deleted ()
Ответ на: комментарий от Deleted

Если бы существовал кэш, от которого можно избавиться, не приходил бы oom, верно ?

Да, поэтому дело в чем-то другом. Может банально самой программе памяти не хватает, а ОП думает, что как-то по другому. Может этот кеш записи, не файловый кеш ОС, а кеш внутри самой программы.

goingUp ★★★★★ ()
Последнее исправление: goingUp (всего исправлений: 1)
Ответ на: комментарий от goingUp

По хорошему нужно научить прогу притормаживать, когда к-во свободной памяти стремится к 0. Но мне кажется, что самым дешевым вариантом будет своп. Для начала можно попробовать свопить на hdd, если не хватит - свопить на ssd. Так же очень рекомендуется ко включенному свопу включить zswap. Хотя если данные хорошо сжимаются, то можно попробовать zram, отдав ему 20-40% памяти.

Deleted ()

дык сбрасывай кеш через echo 3 >/proc/sys/vm/drop_caches

Но oom все равно придет. Память может течь не только в программе, но и в ядре. Да и еще RHEL 6 со своими мутантами ядер 2.6

Гугл про «gpfs oom» выдает много интересного.

Убери gpfs для эксперимента.

vel ★★★★★ ()