Как отследить какая база подвешивает сервер? ($50 reward)

на сервере несколько десяток баз MySQL.
MySQL вешает сервер.
как отследить какая конкретно база подвешивает сервер?

награза за работающий солюшн - $50

Вообще, если одна база приходится на одного пользователя, то отследить можно по загрузке процессов этого пользователя.
Если все базы висят на одном логине, то делать запрос, потипу 'SHOW PROCESSLIST' и смотреть время работы и нагрузку каждой базы.

А по хорошему поставить на сервере PRM (Process Resource Monitor), который отслеживает и убивает процессы, которые грузят сервер больше заданного числа.

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

PRM (Process Resource Monitor) - - точно хорошая штука?

Что бы весь мускуль не отгрызал память, сконфигурируется его под ВАШ объем памяти.

Далее для анализа используйте вот это
http://dev.mysql.com/doc/refman/4.1/en/slow-query-log.html

Просто уменьшайте время, которое считает запрос медленным , так и дойдете до виновника.

А вообще просто так сказать нельзя. Может кстати помочь обновления мускуля до последней стабильной версии.

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

CKA3KA писал:

видно только что весь мускул отжирает память. PRM (Process Resource Monitor) - - точно хорошая штука?

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

А нафига монитор если и так ясно что жрет.
Логи включили, my.cnf поправили, ну и админам смотреть что в логи валится .

пробуем смотреть при помощи
http://dev.mysql.com/doc/refman/4.1/en/slow-query-log.html

про PRM админ сказал что "не выйдет - демон mysql 1, и если его грубо убить - навернутся базы"

вообще я так понимаю мускул повесить могут:

1) несколько долгих процессов, это лечится при помощи
http://dev.mysql.com/doc/refman/4.1/en/slow-query-log.html

2) либо куча мелких процессов. хз как лечится.

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

А так, из теории это пожалуй все

Stek писал:

Повесить мускуль много что может. Вообще бери своих админов и программистов и давай им для прочтения вот этот топик

гранд мерси

Stek писал:

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

рекомендованные спецы есть в этой области?

С моей стороны нет, всегда сам все делал и поэтому таким вопросом не задавался

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

slow-query-log.html весьма познавательная штука оказалась
щаз стоит вопрос как ограничить длинные запросы

50 баксов гони, за солушен и умные вещи

slow query ты не ограничишь, ты можешь от них только избавится. Опять же правильность структуры хранения информации, наличие или отсутствие индексов.

Потом , в мускуле есть команда explain , которая показывает число строк, индексов участвующих в выборке.

А собрать mytop и посмотреть?
http://jeremy.zawodny.com/mysql/mytop/

Судя по выводу это аналог "SHOW PROCESSLIST"
Гораздо легче подключится к серверу любым клиентом и получить тот же результат.

Stek писал:

50 баксов гони, за солушен и умные вещи slow query ты не ограничишь, ты можешь от них только избавится.

прогоню, как только солушн будет

CKA3KA писал:

прогоню, как только солушн будет

ступил
давай в фете акк в аську

Stek писал:

Судя по выводу это аналог "SHOW PROCESSLIST" Гораздо легче подключится к серверу любым клиентом и получить тот же результат.

Ну да. А вместо обычного top - пользоваться ps, vmstat и uptime. А что, показывает-то то же самое

А автору думаю стоит посмотреть my.ini/my.cnf на предмет
set-variable = key_buffer=384M
set-variable = sort_buffer=2M
set-variable = myisam_sort_buffer_size=64M
раз уж сам запрос оптимизировать не удается.

Цитата:

Ну да. А вместо обычного top - пользоваться ps, vmstat и uptime. А что, показывает-то то же самое

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

А по поводу памяти, тут два варианта:
1 - увеличивая память частично снижаем нагрузку на винт и процц , но жрем память сильно
2 - снижаем память, сильно увеличивается нагрузка на винт и проц, но память кушается мало.

Тоже хочу 50$ ну или рейтинг хотябы ;)

Вообщем SHOW PROCESSLIST конечно весчь, хотя подобные пробелмы не исчерпывает. Лучше смотреть bin лог запросов, который в data лежит при помощи mysqlbinlog и естественно оптимизить наиболее тяжелые запросы, ОДНАКО!!! Надо учитывать, что не каждый запрос, требующий много времени на выполнение является тяжелым!!!

Дело в том, что в MyISAM базе реализованна блокипровка на уровне базы! По этому, если идет UPDATE, то пока он будет идти, все остальные за ним UODATEs будут ждать, ровно как и SELECTы. И если таких выстраивается большая очередь, а запрос оптимизировать не удается, то надо менять тип таблицы с MyISAM на InnoDB

И еще один момент - если базу чтото вешает в один прекрасный (неизвестный) момент, то не в SHOW PROCESSLIST, не в бинарных логах этого запроса не появляется, ибо он пишется туда после выполнения! Но отследит такой зависон можно, но по другому -
mysqladmin -i10 processlist status
задаете в командной строке и спокойно идете спать.. после падения на экране останутся последние выполняемые запросы, среди которых самый тяжелый - он, больной зуб!
(если вдруг не поможет, уменьшите интервал)

И все таки интересно, топикстартер смог выявить эту база?
CKA3KA: распиши порядок действия, как выявил.

Судя по всему топикстартер просто где то отсутствует

Stek писал:

Судя по всему топикстартер просто где то отсутствует

Оффтопик: Типа $50 на фет так и неприслал? Уверен, что отправит =)))
Хотя у меня сомнения есть, что четверть(?) твоего дневного заработка меньше... хотя с другой стороны, писят баксов то, они нелишние =)))

Stek писал:

Судя по всему топикстартер просто где то отсутствует

дык, ты в аську то появись

как выявили базу:
зарядили мускул чтобы писал логи как написано тут: http://dev.mysql.com/doc/refman/4.1/en/slow-query-log.html

сервер проработал сутки и в обычное время начал как обычно висеть. останосили мускул - начали копать логи. и вот оно - 60% загрузки давал один юзер с длинными запросами больше 1 секунды. списались с юзером - у него Invision Power Board(U) v1.3 Final + рост траффа. имперически пришли к выводу что надо отрубить поиск по сайту. отрубили. смотрим что выйдет

зы: но метод не до конца красивый, щаз думаем как обрубить запросы длинные или на худой конец конфиги мучать.