Задавайте вопросы, мы ответим
Вы не зашли.
Уважаемые форумчане и гуру MYSQL, я сам не программист, у меня есть сайт, где стоит SocialEngine, народу уже много, и у меня по логу медленных запросов вылазиет один запрос, который долго выполняется, но я не знаю как его оптимизировать помогите пожалуйста, из за него очень сильно тормозит сайт, хотя сервер выделенный и мощный. Очень надеюсь на вас, вот лог:
# Time: 100914 21:15:13
# User@Host: vocalist_mysql[vocalist_mysql] @ localhost []
# Query_time: 7.529639 Lock_time: 0.000110 Rows_sent: 0 Rows_examined: 0
SET timestamp=1284484513;
(
SELECT
'0' AS notify_grouped,
count(se_notifys.notify_id) AS total_notifications,
se_notifytypes.notifytype_id,
se_notifytypes.notifytype_desc,
se_notifytypes.notifytype_icon,
se_notifytypes.notifytype_url,
se_notifys.notify_urlvars,
se_notifys.notify_text
FROM se_notifys
LEFT JOIN se_notifytypes
ON se_notifys.notify_notifytype_id=se_notifytypes.notifytype_id
WHERE
notify_user_id='6'
AND
notifytype_group=1
GROUP BY se_notifys.notify_notifytype_id
) UNION ALL (
SELECT
se_notifys.notify_object_id AS notify_grouped,
count(se_notifys.notify_id) AS total_notifications,
se_notifytypes.notifytype_id,
se_notifytypes.notifytype_desc,
se_notifytypes.notifytype_icon,
se_notifytypes.notifytype_url,
se_notifys.notify_urlvars,
se_notifys.notify_text
FROM se_notifys
LEFT JOIN se_notifytypes
ON se_notifys.notify_notifytype_id=se_notifytypes.notifytype_id
WHERE
notify_user_id='6'
AND
notifytype_group=0
GROUP BY se_notifys.notify_notifytype_id, se_notifys.notify_object_id
);
# User@Host: vocalist_mysql[vocalist_mysql] @ localhost []
# Query_time: 7.533834 Lock_time: 0.000099 Rows_sent: 2 Rows_examined: 34
SET timestamp=1284484513;
(
SELECT
'0' AS notify_grouped,
count(se_notifys.notify_id) AS total_notifications,
se_notifytypes.notifytype_id,
se_notifytypes.notifytype_desc,
se_notifytypes.notifytype_icon,
se_notifytypes.notifytype_url,
se_notifys.notify_urlvars,
se_notifys.notify_text
FROM se_notifys
LEFT JOIN se_notifytypes
ON se_notifys.notify_notifytype_id=se_notifytypes.notifytype_id
WHERE
notify_user_id='3287'
AND
notifytype_group=1
GROUP BY se_notifys.notify_notifytype_id
) UNION ALL (
SELECT
se_notifys.notify_object_id AS notify_grouped,
count(se_notifys.notify_id) AS total_notifications,
se_notifytypes.notifytype_id,
se_notifytypes.notifytype_desc,
se_notifytypes.notifytype_icon,
se_notifytypes.notifytype_url,
se_notifys.notify_urlvars,
se_notifys.notify_text
FROM se_notifys
LEFT JOIN se_notifytypes
ON se_notifys.notify_notifytype_id=se_notifytypes.notifytype_id
WHERE
notify_user_id='3287'
AND
notifytype_group=0
GROUP BY se_notifys.notify_notifytype_id, se_notifys.notify_object_id
);
Неактивен
Нужны еще как минимум структуры таблиц (SHOW CREATE TABLE tablename)
и EXPLAIN от запросов (EXPLAIN SELECT …). В случае с UNION лучше отдельно
EXPLAIN верхней и нижней части.
Сходу кажется, что
a) лишние UNION в принципе, т.к. можно просто верхнее поле переписать
через IF();
б) лишние LEFT JOIN (больше подозрение, что notifytype_group — это поле из
se_notifytypes).
Неактивен
Вот Show create table
Отредактированно godzeus (15.09.2010 09:34:40)
Неактивен
Эм. Вы выбираете 2 строки этим запросом по ключу. Даже те изменения,
которые я написал, не принесут большой производительности.
Оно в диск упирается или в процессор? Посмотрите, сколько памяти выделено
под буфер ключей (key_buffer_size). Ну и статистику интересно посмотреть:
SHOW GLOBAL STATUS LIKE 'key%';
Неактивен
Нет, в таблице se_notifys сейчас около 8000 (сколько и пользователей) а их становится все больше. В se_notifytype (хранятся типы уведомлений), а в se_notifys (хранятся списки настроек уведомлений пользователей, сколько пользователей, столько и записей, а их не мало).
Вот такие настройки сейчас у меня
key_buffer_size = 128M
sort_buffer_size = 128M
Вот статистика:
Variable_name Value
Key_blocks_not_flushed 0
Key_blocks_unused 105352
Key_blocks_used 1820
Key_read_requests 4874694
Key_reads 1873
Key_write_requests 18661
Key_writes 2599
Отредактированно godzeus (15.09.2010 12:58:20)
Неактивен
Кошмар. У Вас с настройками всё хорошо. Запросы действительно тормозят?
Если его выполнить вручную — он и правда медленно отрабатывает?
Неактивен
В ручную он выполняется моментально, вот сделал вручную (всего, запрос занял 0.0066 сек.) не понимаю, почему он попадает в лог медленных (((
Вложил лог, я уже не знаю что делать (( прямо руки опускаются
Хотя сервер просто отдыхает: Средняя загрузка 0.01 0.01 0.02, что делать? как узнать, что происходит?
Отредактированно godzeus (15.09.2010 14:34:47)
Неактивен
Поставьте atop, посмотрите нагрузку на сервер в моменты, когда
сыпятся сообщения в журнал медленных запросов. Скорее всего,
просыпается какая-то страшная ужасная штука, которая нагружает
сервер целиком.
Неактивен
А как их отловить ? Эти моменты ?
Неактивен
atop пишет на диск состояние раз в некоторое количество времени.
А потом можно побегать по времени назад и посмотреть, что грузит
машинку.
Неактивен
а я подумал что вы про mytop говорите сижу уже ловлю запросы
Неактивен
У меня FREEBSD 64 для нее нет atop
Отредактированно godzeus (15.09.2010 22:23:36)
Неактивен
Хм. Кто ж ее знает, как эту операционку админить. У меня было несколько
случаев попыток, и все негативные — очень уж она напоминает «сделай сам»
Хотя и среди линукса есть любители пособирать из исходников, да
Если хотите сделать самостоятельно — можете сделать что-нибудь типа
while true; do ( date ; uptime ; ps axu ) >> logfile; done
В screen это запустить, а потом смотреть по нагрузке, когда пик, и что реально
грузит систему. Это в баше, в csh, который по умолчанию, не знаю.
Кстати, вроде, в бсд можно сделать какой-то обрезанный /proc, тогда и atop
может собраться.
Ну и, разумеется, приветствуются ответы людей, читающих форум, и умеющих
администрировать эту ОС
Неактивен
Понаблюдал по htop
в основном такая картина что апач грузит сильно сервер, но почему не понятно
Неактивен
mod_php? Значит, такой код. Можете перейти на какую-нибудь человеческую
схему, запустив быстрый вебсервер (nginx, lighttpd, …) и php через fastcgi.
Выиграете процентов двадцать производительности. Ну и готовьтесь переписывать
код, если Вы действительно в него упираетесь
Неактивен