LINUX.ORG.RU
ФорумAdmin

Падает mariadb

 , , ,


0

1

Странная штука творится:

есть несколько vps на kvm, на нескольких из них Машадб и все отлично, на одном из серверов время от времени приходим oom-killer и гасит машу (с дефолтным конфигом). При том что памяти везде одинаково, а нагрузка там где падает Маша даже ниже чем на остальных.

Хочу спросить можно ли увидить сколько требовала памяти maria-db по syslog? Для мониторинга пока ничего не ставил. Хочу посмотреть на производительность этой vps.

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

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

конфиг

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

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

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

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

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

invokercd ★★★★ ()
Ответ на: комментарий от i_gnatenko_brain

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

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

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

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

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

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

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

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

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от invokercd

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

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

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

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

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

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

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

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

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

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

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

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

Посему 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 :)

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

До твоего поста я был уверен что 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

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

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

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

  /*
   * 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);
true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

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

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

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

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

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

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

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

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

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

4) MaxClients стоит?

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

1) в 01:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И вруби уже oom_dump_tasks.

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

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

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

invokercd ★★★★ ()
Ответ на: комментарий от true_admin

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

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

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

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

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

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

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

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

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

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

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

Логами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

invokercd ★★★★ ()

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

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

MrClon ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.