Как чистить оперативную память в Centos 7?

Question

[Владимир Ревякин]

Подскажите пожалуйста, каким способом лучше очищать оперативную память, и как проверить какой процесс ее использует? В последнее время оперативная память постепенно уходит, не могу понять на что именно тратится такой большой объем оперативной памяти.

Comments

[Lynn «Кофеман»]

И при чём тут nginx?

Answer 1

[Владимир Ревякин]

kolu4iy: Ну у меня большая часть оперативной памяти в кеше, я так понимаю, мне ее не трогать ? А если она вся забьется?

Comments

[kolu4iy]

Вы заметили, что при этом использование swap=0? А за 35 дней, если бы память текла, система бы скорее всего уже тормозила и свопилась.
Я уже писал выше: если какому-то процессу свободной памяти будет недостаточно, система первым делом отдаст кусок кеша, а не своп.
Это нормально, ядро линкус давно так работает. Тем самым оно уменьшает обращения к дисковой подсистеме, не в ущерб работе остальных процессов.
Кстати, вы заметили, что у вас около 30 java-процессов, каждый из которых затребовал по 34 Гб виртуальной памяти? У вас её много, но при этом заметно меньше чем 30*34 Гб. При этом реально процессы эту память сейчас не используют, но такая конфигурация может потенциально привести к проблемам следующего рода: конкретно с jetbrains я не работал, но подобная ситуация у меня была при некорректной настройке mysql - он выделял очень большой буфер на одно соединение. В итоге, когда нагрузка на веб-сервер росла, количество соединений с mysql тоже росло. Виртуальной памяти было потреблено тоже больше, чем доступно (vmcommit > vmlimit, который равен физической памяти + своп в первом приближении). VMCommit у меня был порядка 40-42 Гб при лимите в 36 (32 + 4 своп). Оно светило красненьким, и я не обращал внимания. В какой-то момент мои коллеги внесли небольшие изменения в запросы, и они стали заполнять эти буфера больше чем процентов на 10, а в итоге реально потребляемая память в какой-то момент превысила vmlimit, после чего сервер встал.
Потому, на всякий случай, проверьте либо настройки java при её запуске, либо уменьшите количество процессов на всякий случай. Лёгкое изменение сценария использования вашего сервера потенциально может привести к крашу процессов jetBrains.BuildServer, как минимум.

[Владимир Ревякин]

kolu4iy: как в моем случае лучше поступить? Я новичок в этом деле, и чем проще тем лучше)

[kolu4iy]

Почитать документацию по билд серверу, поднастроить его. Остальное не трогать.

Answer 2

[Антон Нагаец]

Проверить кто ест память - htop (настроек больше чем в простом top)
убить процесс kill , ну или перезагрузить его.

Answer 3

[kolu4iy]

На кэш тратится. Не мешайте операционной системе работать - так положено. Не забудьте в sysctl.conf выставить vm.swappiness поменьше, например 10.
Посмотрите с помощью atop - если основной объем памяти (строка MEM) указан в третьей колонке (cache) - то это оно. Не трогайте.
Если какой-то конкретный процесс отожрал - то все предыдущие советы правильные.

Comments

[Владимир Ревякин]

Спасибо

[Владимир Ревякин]

Посмотрите с помощью atop - если основной объем памяти (строка MEM) указан в третьей колонке (cache) - то это оно.
Именно так как вы и написали, но в кеше уже большая часть оперативной памяти((((

[kolu4iy]

Так это же хорошо - память не простаивает. Отдаёт при нужде мгновенно, зато дисковый ввод-вывод, например, у вас хорошо закеширован. Система свопится? Что конкретно вас не устраивает? Какому-то процессу мало памяти?
То есть "нет свободной памяти" - это не проблема. На самом деле она есть и ОС отдаст её по первому же свистку. "Медленно работает" - уже проблема, но надо искать узкое место - не факт, что это память.

[Владимир Ревякин]

kolu4iy: быть может эта команда : echo 3 > /proc/sys/vm/drop_caches поможет?

[kolu4iy]

Вы так и не озвучили ответ на вопрос "зачем".