Падает mariadb

Конфиги? Это ж не маша падает, а память кончается. Может ее кто-то еще жрёт.

Да, неверно написал. У меня конечно бредовое впечатление что не хватает физической памяти на хосте.

конфиг

Памяти 1.5 Gb, без maria-db занято до 200 Mb, кроме апача, нджинкса и эксима больше ничего нет. При запущенной Маше, занято не более 400-500.

Обычно при oom в dmesg падает куча инфы. В том числе кто сколько жрал. Неужели ничего нет?

Есть в страницах.

Вот кусок дмесга, если не сложно, то прошу глянуть http://pastebin.com/bbfvy7yP.

Apache жрет память.

ну кто же делает машины без свопа то ?

есть возможность сделать небольшой своп например на 500Мб? Сделай, возможно OOM просто не успевает разобраться. Обычно он ещё выбирает, кого кильнуть. Возможно проблема не в СУБД.

Жрут они вместе, то есть sql ведь потребляет в зависимоти от запросов сервера.

Смысл? Как я уже говорил с такой конфигурацией несколько серверов и oom-killer ниразу не мочил ни чего при гораздо более высоких нагрузках.

Та могу конечно, но я бы хотел понять как может при таких мизерных нагрузках не хватать памяти.

своп добавит устойчивости. Загрузка памяти не будет тебя ждать, она НИКОГО не ждёт. Это как кувалдой по голове. OOM Killer просто грохнет что попалось (что-нить просто большое). Если сделать своп, то OOM анализирует, и начисляет каждому процессу скор. У кого скор больше, тот и виноват в утечке.

при таких мизерных

откуда инфа? Ты каждую микросекунду замерял?

оттуда что у меня несколько серверов и я знаю где какая нагрузка.

тогда думай самостоятельно, и не задавай глупых вопросов.

Вообще то если бы ты сумел прочитать первый пост то не давал бы глупых советов.

Раньше была такая фича у линуха что без свопа он мог килять процессы даже если памяти достаточно. Если сильно покопаться то можно даже найти этому объяснение. Говорят что это давно пофиксили, но я всегда делаю своп на 100 метров от греха подальше.

Судя по тому что ядро киляет сразу несколько процессов проблема, подозреваю, в апаче. Поставь в нём MaxRequestPerChild 100.

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

Кстати, подобные случаи у нас вызывались обычно задачами в кроне которые посылали тяжёлые запросы на апач и базу, либо во время бэкапов.

PS Один из костыльных вариантов это тупо раз в пять секунд дампить список процессов вместе с timestamp и руками смотреть. Есть всякие atop/sar/etc которые умеют записывать показания, но я не умею ими пользоваться.

PPS отговорки «на других тачках всё работает» не канает.

ну может советы у меня(и не только у меня) и глупые, но мне помогло: в такой ситуации, после создания свопа, падать перестало. Но стало тормозить из-за нехватки памяти.

Я удивлён что ядро не написало кто сколько занимает места в памяти.

а что тут удивительного? Для составления этого списка тоже нужна память, которой НЕТ в момент нехватки памяти. Рекурсия. Виртуальная память построена аппаратно, потому её опустошение возникает ВНЕЗАПНО.

Можно зарезервировать десяток кб. Собстно, для работы omm killer-а тоже нужна память, и у него она есть.

Собстно, для работы omm killer-а тоже нужна память, и у него она есть.

есть, но недостаточно. На самом деле, алгоритм на сегодня очень сложный и запутанный. И «десятка К» ну никак для этого не хватит. На сегодня OOM это такой «libastral», который пытается _прогнозировать_ момент, в который произойдёт СТРАШНОЕ. И получается у него очень неплохо, лично я даже специально не смог сделать приложение, которое течёт, но при этом так, что OOM не может его распознать и прибить.

Фатальный недостаток виртуальной памяти в том, что ситуация сбоя возникает не в том приложении, которое является причиной проблемы. Потому в момент сбоя в общем-то делать уже нечего, а можно лишь валить то приложение, которому не повезло. Посему OOM собирает сложную статистику для того, чтобы завалить приложение ДО сбоя. Размер этой статистики непредсказуем, и потому её нельзя держать в памяти ядра.

И «десятка К» ну никак для этого не хватит

Обойти дерево процессов и вывести кто сколько сожрал? Да легко, имхо.

пытается _прогнозировать_ момент, в который произойдёт СТРАШНОЕ

Посему OOM собирает сложную статистику для того, чтобы завалить приложение ДО сбоя.

Ты уверен? Что-то мне подсказывает что всё гораздо проще. Видел трейсы перед OOM? Так вот, он вызывается из одного места. Вот выдержка из сырцов:

This gets called from __alloc_pages() in mm/page_alloc.c when we really run out of memory.

Посему OOM собирает сложную статистику

До твоего поста я был уверен что oom killer это что-то жутко сложное (хотя, нафига тут особая сложность?). Оказалось нет: ./mm/oom_kill.c весьма короткий. Кстати, есть dump_tasks который может выводить статистику. Активируется через sysctl vm.oom_dump_tasks=1 :)

До твоего поста я был уверен что oom killer это что-то жутко сложное (хотя, нафига тут особая сложность?). Оказалось нет: ./mm/oom_kill.c весьма короткий.

ну я же выше говорил, если случилось СТРАШНОЕ, то уже поздно что-то делать. Упомянутая мною статистика собирается ДО краха, а не во время. В момент краха OOM просто тупо смотрит, у кого больше(или меньше, не помню) скора. И того прибивает. Я лет пять назад занимался этим вопросом, и было всё именно так. Сейчас наверное только сложнее стало, ведь libastral.so так никто и не придумал. И вот раньше эта статистика лежала в юзерспейсе.

Кстати, есть dump_tasks который может выводить статистику. Активируется через sysctl vm.oom_dump_tasks=1 :)

Я с Патрегом в курсе:

$ cat /proc/sys/vm/oom_dump_tasks 
1

Упомянутая мною статистика собирается ДО краха

Там используются три базовых счётчика. Вот как вычисляется скор:

  /*
   * The baseline for the badness score is the proportion of RAM that each
   * task's rss, pagetable and swap space use.
   */

  points = get_mm_rss(p->mm) + p->mm->nr_ptes +
     get_mm_counter(p->mm, MM_SWAPENTS);

хм... Ну может и так, ковырять мне лениво сейчас...

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

В общем врубил на нем мониторинг, ситуация такая: la и память. То есть внезапно утром практически с нулевой нагрузки начинается такая фигня, приходит oom-killer и понеслась. И как видно памяти минимум остается еще 876 Mb. То есть нехватки памяти нет. На нем вращается несчастные 2 бд, и пару сайтиков. Врубить MaxRequestPerChild не могу, так как юзается mpm-itk.

Как дальше жить?

1) В какое время делаются бэкапы?

2) Стоит ли nginx перед апачём?

3) Что там по логам доступа к апачу? Не приходит ли какой-нить поисковик?

4) MaxClients стоит?

1) в 01:00

2) да, соответственно кип алив в апаче вырублен

3) ничего сверх нормы, боты приходят и уходят как обычно

4) нет, для этого нужно ставить mpm-prefork, если я поставлю apache2-mpm-prefork, он вынесет apache2-mpm-itk - без которого нельзя.

кип алив в апаче вырублен

Можешь врубить, он тут не помешает.

для этого нужно ставить mpm-prefork

Точно? Я перед тем как это писать порылся в сырцах itk, там всё на месте. Собстно, itk это патч для prefork.

Вообще, ты так и не собрал статистику того что творится внутри VM. cat /proc/sys/vm/oom_dump_tasks что говорит?

У ТС debian oldstable с ядром 2.6.32, не понятно даже какой патч версии.

Можешь врубить, он тут не помешает.

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

Точно? Я перед тем как это писать порылся в сырцах itk, там всё на месте. Собстно, itk это патч для prefork.

Значит я тупанул, попробую врубить сейчас.

[some*some:/]>  cat /proc/sys/vm/oom_dump_tasks 
0

какой тогда смысл врубать в апаче?

Чтобы nginx не надо было на каждый запрос устанавливать новое соединение до бэкенда. Впрочем, если nginx оочень древний то он так не умеет и ему на это будет пофиг.

И вруби уже oom_dump_tasks.

nginx 1.4.1, стараюсь обновлять по мере появления.

Врубил, это типа verbose для oom-killer который полетит в dmesg/syslog насколько я понял?

да, это оно.

2.2.16, апач такой же.

Спасибо тру, надеюсь выявить что это за фигня творится. Кстати еще была похожая мулька пару часов назад, опять резкий скачок, памяти осталось уже 200, но никто не умер, как говорится. Даже если это боты поисковые то не должно быть такого выжирания памяти.

Недавно слегка доснули похожую vps, кроме огромного LA, и потребления памяти +15% ничего страшного не было. Проапргрейдиться что ли.

Я бы прогнал нагрузочные тесты и посмотрел воспроизводится ли ситуация. Есть подозрение что надо просто подкрутить апач, например.

Так проблема в том что есть аналогичные тачки с рубями и перлами, и прочим хламом, тоже с Машкой, аналогичными конфигами - вот ниразу не было такого. Хотя все бывает в первый раз :)

Хотел еще спросить, как можно цивилизованно промониторить какие запросы шли к апачу извне, кроме как парсить логи?

аналогичными конфигами - вот ниразу не было такого

Это не аргумент. Чудес не бывает, надо разбираться.

как можно цивилизованно промониторить какие запросы шли к апачу извне,

Логами.

кроме как парсить логи?

O_O а как ещё? Можешь на nginx писать отдельный лог для внешних запросах.

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

Вместо того чтобы запустить какой-нить apache benchmark, посмотреть что происходит под нагрузкой и подкрутить MaxClients (о чём я писал кучу постов выше), вы решили вручную мониторить ситуацию и ждать пока проблема сама возникнет. Люди — странные существа.

Я не могу в данный момент делать бенчмарк, так как там запущен сайтик который нужен. MaxClients я конечно уменьшил, но трабл в том что сайтик оказался тяжелым.

Какие бенчмарки на будещее посоветуешь?

Из простых средств siege (не забудь про флаг -b).

Есть более умные которые умеют иммитировать пользователей (ходить по ссылкам, добавлять посты), но это пока избыточно.

там запущен сайтик который нужен

Скачай виртуалку себе на комп погоняй :)

Cпс. Ну у меня есть еще парочка серваков для теста. Просто хотел на той же конфе.

Если ещё не советовали. Срани выхлоп sysctl -a с проблемной виртуалки и нормальной.

Ну и посмотреть кто там память кушает. По крону раз в минуту дёргать сякрипт записывающий в лог список процессов и потребляемую ими память (думаю хватит просто выхлопа ps vxa, хотя парсить его потом будет неудобно)