управление долгими запросами в mysql
| zubastiy |
|
|
Темы:
136
Сообщения:
548
Участник с: 18 сентября 2009
|
Есть сайт на LAMP Вылезла сейчас проблема с тем, что есть очень долгие запросы, локающие таблицы. C одной стороны это нужные для работы запросы, с другой стороны это затупы на сайте. У меня пока только мысли об автокилл запроса если он длится больше чем определенное время и оповещатор о проблеме на мыло. SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE TIME > 15 AND INFO NOT LIKE 'NULL' ORDER BY TIME LIMIT 1\G Думаю вызывать bash скрипт, который парсит вывод данного запроса и если есть ID задания, шлет вывод на почту и грохает задание. Или будет правильно написать продцедуру которая делает тоже самое, но силами самого mysql? |
| User6260 |
|
Темы:
1
Сообщения:
53
Участник с: 08 мая 2013
|
Я думаю, что правильнее попробывать оптимизировать сами запросы. Т.к. убивание запроса все равно нарушает нормальную работу сайта. |
| corner |
|
|
Темы:
6
Сообщения:
773
Участник с: 21 июля 2011
|
Не знаю, насколько это относится к ArchLinux. Во-первых, нужно собрать сначала длинные запросы в лог. Как это сделать Во-вторых, посмотреть в сети, учебниках методы оптимизации таблиц и запросов. Например, нелишне будет делать выборку только нужных полей, а также построение дополнительных индексов. Да и ревизия самой таблицы не помешает. Также необходимо проверить загруженность сервера, на котором работает mysql. Память, место на разделах и т.д. По поводу запросов, например, известно, что замена * именами полей существенно ускоряет запрос. Но, вообще-то, говорят, если в таблице меньше 300000 записей, то не стоит париться о быстродействии. Это я прочитал на одном из блогов разработчиков. Где - уже не помню. И сам запрос в части AND INFO NOT LIKE 'NULL'смущает. На что не похоже? На NULL? Не проще ли будет поступить так - SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE TIME > 15 AND INFO IS NOT NULL ORDER BY TIME LIMIT 1 |
| zubastiy |
|
|
Темы:
136
Сообщения:
548
Участник с: 18 сентября 2009
|
спасибо за рекомендации. имхо сайт должен жить несмотря на то, что есть долгие запросы. и желательно жить без моего вмешательства в решение проблемы - убивание долгого запроса ) оптимизация запросов - тема отдельная и оповещатор на мыло разработчику, как раз для того, чтобы не оставить проблему без внимания. мне более важно понять - как поступают другие люди в схожих случаях. по идее внешняя обработка, нормально-быстро-удобно. но в случае переезда на другой сервере, ее нужно снова настраивать, хранить пароль в открытом виде где то. продцедура - переедет вместе с базой и думать об этом (восстановлении) не надо. минусов не вроде как не вижу. |
| Natrio |
|
|
Темы:
47
Сообщения:
4763
Участник с: 08 января 2011
|
Как насчёт переписать скрипты, которые порождают эти запросы? Их просто не должно быть изначально. Если генерятся слишком долгие запросы – надо разбить задачу на более мелкие части, чтобы запросы не были слишком долгими. Если вас интересует – я в своё время примерно наполовину переписал код поиска в phpbb2, чтобы исключить долгие операции. |
| zubastiy |
|
|
Темы:
136
Сообщения:
548
Участник с: 18 сентября 2009
|
Natrio Вы правы, скрипты надо переписывать и они будут разработчиком переписаны (собственно уже сделано). Смысл в том, чтобы поддерживать доступность сайта и работоспособность большей части функционала в любой момент времени. Скрипт ведь делает тоже самое что и я. В случае проблем с доступностью сайта будет проверять базу на предмет долгих запросов, логировать инфу, отправлять на почту разработчику, убивать запрос, убеждаться что сайт работает, слать сообщение, что сайт работает (снова не работает). |