Всем добрый день,

Гуру подскажите по такой проблеме - имею 5 app, продуктив, в одном из которых (не ci) ОС пожрала практически всю память под кэш.
И отдавать особо не желает. По процессам никакого криминала не замечено. Перегружать app не хотелось бы.
ОС = Linux Suse, БД = Oracle

Если скажем "тёмной ночью", пока никого нет в системе я сделаю так



это криминал или нормально?

Спасибо.

В догонку - вообще команда не деструктивная, и может быть не делать sync, а drop_caches тогда сбросит только чистую память, а грязная как была так и останется занятой, пока сама не сбросится на диск.

Тёмной ночью, когда пользователи спят, лучше оставить в кроне(или через at) перезагрузку appl сервера:
stopsap r3;cleanipc <in> remove;startsap r3;
А вообще, ничего страшного, в том что аппл отъедает память своим кэшом нет.
У нас отдельные апплы сьедают 100% озу и работают нормально - до плановой перезагрузки..ш

Дампы посыпались от фоновых заданий - им памяти не хватало, "каких-то 7 килобайт".

2Egal: Кеш на уровне оси вычищается сам при необходимости получить память под активные процессы либо под другие активные данные. Сбрасывать его в ручную было бы не совсем красиво, но криминала нет. Если хотите заняться настройкой кеша вот полезная нота: 1557506 - Linux paging improvements

2bdmalex: Рестарт аппликух очень эффективно, но грубовато.

Оптимальным на мой взгляд, будет, настроить автоматический рестарт рабочих процессов, они тогда не будут выедать память почём зря.
Делается это через параметр аппликухи: rdisp/wp_auto_restart Воркпроцессы будут рестартовать спокойно, в разнобой и только в том случае если не выполняют никаких задач, удобно.

У меня пошел дождик из дампов, и перспективы особой не наблюдалось. Я подождал пока число пользователей и BTC станет минимальным и почистил кэш.


Спасибо, прочту обязательно.

Вот и я о том же подумал, чего его туда-сюда мотылять. Хотя все же на субботу запланировали рестарт.


Этот параметр уже есть = 1800. Есть ли смысл делать чаще?

Интересно стало, а о каких количествах пользователей идет речь ? То есть, при каких кол-вах меня тоже будут ожидать такие пляски ? У меня народу мало, дал им 80 Гб на всю CI систему и порядок. А для меня этот топик выглядит попыткой решить не верно сконфиругированные профильные параметры - зашедулированной перезагрузкой рабочих процессов, в прочем, прошу прощения, я видимо ничего не понимаю в колбасных обрезках и hi-load системах

а в чем тогда смысл кэша, если его регулярно сбрасывать рестартуя инстанцию?

Если есть memory leak, то это надо лечить: 1. заменой ядра оси и параметризацией 2. заменой ядра системы

остальное, на мой взгляд, должно быть реализовано штатными средствами - профильным параметром рестарта WP.

добавлю ноту, из тех, что под рукой:

1824819 - SAP HANA DB: Recommended OS settings for SLES 11 / SLES for SAP Applications 11 SP2

этот параметр, в случае проблем с памятью, я бы проверил обязательно:

По порядку:

1. У меня не Хана, просто Оракл - нота 1824819 - SAP HANA DB: Recommended OS settings for SLES 11 / SLES for SAP Applications 11 SP2 - наверное не для меня

2. Вопрос был именно такой "локальный", можно ли разово, "в порядке исключения, для царственных особ", из-за кучи дампов (которые возникли изза амнезии у app), "тёмной ночью" сбросить кэш. Понятно что ядро надо патчить, параметры оптимизировать и всё такое. Но это перспектива. Причем очень далёкая.
А у меня была вот такая мгновенная реальность. Я подождал минимальной нагрузки и сбросил кэш как написал выше. Т.к. потом выяснилось что в подобной ситуации давно-давно кто-то сбросил кэш и фоновые процессы разлетелись кто куда. Хотя подтверждения того что это было именно из-за сброса кэша я не имею.
По-этому хотел убедиться что это действительно non destructive command как пишут в мануале

3. Речь идет о большом числе пользователей, не одна сотня. И не три. Но собственно дело не в пользователях, а в памяти выделяемой для фоновых процессов.
Когда все реальные пользователи вышли из системы во free из кэша вернулось всего 3 Gb, и того стало около 6. После сброса кэша - свободной стало около 40 Gb.
В это время на остальных app было от 18 до 30Gb, при меньшем числе пользователей, но при примерно такой же нагрузке фоновыми процессами.

Как-то так

ок, вот Вам тоже самое, только вид с боку и без HANA
1310037 - SUSE LINUX Enterprise Server 11: Installation notes


не помогал?

Кеш сбросить можно, но проблему это не решит, он наполнится заново. И ничего плохого в этом нет, как только рабочему процессу потребуется под данные N количество памяти, ядро само освободит кусок кеша и отдаст его процессу. Грубо говоря, в linux свободная память = free + cache (но это грубо, есть нюансы).

Не совсем понятна суть проблемы которую пытаетесь решить сбросом кеша. Если это сферический free, то да, он вырастет.

Наверно стоит изучить динамику использования памяти на отрезке времени "спокойно-нагрузка-спокойно" через утилиту sar c ключом -r. Она покажет в динамике распределение памяти.

И да, стоит подробно изучить данные в st02, там же и использование буферов.

Это очевидно. Проблему нужно было решить "здесь и сейчас", и перегружать app в ближайшие 5 дней было нельзя.


Это все хорошо в теории. На практике ОС показывала болт wp и app выкидывал фоновый процесс в дамп из-за нехватки памяти.


Суть проблемы я же озвучил - можно ли таким образом поступить на продуктивной системе, в emergency-случае.

В ST02 "красный" был swap - по дискам система хорошо шуршала.
/$sync помогает +1Gb к free, что в общем то несерьёзно.

Egal
тогда в качестве summary: даже на продуктивной системе, в случае emergency-ситуации - все инструменты хороши. а потеря кэша (общесистемного!!!) приведет только к деградации производительности, без потерь данных.

Напишу на всякий случай, ибо выше упоминания не увидел:
Чтобы не дропать пользователей, перед рестартом апликухи (за несколько часов), ее стоит вывести из групп: SMLG, SP12, SM61. Тогда все произойдет быстро и безболезненно.

Ну или деактивировать в SM51