Друзья, такая ситуация — есть отдельный сервер под мускуль, на котором крутится один сайт с относительно небольшой посещаемостью(100k хитов в сутки), сайт сам по себе достаточно крупный, в нем много логики и отдельных сервисов, поэтому присутствуют и медленные запросы, при этом сервер базы спокойно живет несколько недель, пока в один момент не уходит в даун, помогает остановка веб-сервера на несколько минут, чтобы mysql завершил все запросы, после чего тот снова в строю
так вот, мой вопрос — как узнать из-за каких именно запросов(или их совокупности) сервер уходит в даун? подскажите плз средства для этого
просмотр slow query log и show proccesslist особо ничего не дает т.к. медленные запросы есть и от них никуда не деться, но ведь и с ними он прекрасно может работать месяцами
Есть утилита mysqldumpslow которая анализует лог медленных запросов и выводит самые частые медленные запросы, жаль, раньше не знал о ней, надеюсь поможет решить хотя бы часть проблемы.
щас смотрю top — mysqld жрет 150-200% CPU, смотрю SHOW PROCESSLIST(и mytop) — с обновлением в секундуто проскакивает 5-10 запросов, то пусто, долго никто не висит… при этом база откровенно поттупливает даже на элементарных запросах
поставил пакет sysstat в который входит iostat, запустил как вы написали, тока с интервалом в 1 секунду
параметр %util выглядит очень скачущим — несколько секунд выдает 1-10%, потом скачки 30,50,100% потом опять 1-10%, иногда несколько секунд держится 60-80%
наверное это означает что в mysql периодически приходят тяжелые запросы которые и сжирают ресурсы на несколько секунд?
из описания я не очень понял что означает эта утилизация, если вы знаете поясните плз
диски RAID 1, так что ОС вместе с базой, но на разных разделах (на этом сервере крутится только база, веб-сервер на другой физической машине)
утилиту запустил
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours - recommendations may be inaccurate
Reduce your overall MySQL memory footprint for system stability
Adjust your join queries to always utilize indexes
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
join_buffer_size (> 128.0M, or always use indexes with joins)
tmp_table_size (> 128M)
max_heap_table_size (> 128M)
Из вашего объяснения я понял что база не уходит в даун, а просто собирается большая очередь запросов?
Какого рода запросы? insert/select/update?
Посещаемость сайта имеет не большую роль в нагрузке… Все зависит от структуры базы, ее размеров, действием над данными в ней. Можно повесить mysql и одним запросом на очень долгий период.
Если проблема в выборке, используйте кеш если это возможно. Почти на любых проектах не везде нужны актуальные данные за эту секунду. Кеш slow query запросов может дать прирост в производительности в разы!
Возможно у вас проблема с апдейтами данных. Если таблица имеет структуру myisam, при апдейте поля лочиться вся таблица и запросы стают в очередь пока запрос не выполнится.
капитанские истины про кеш и оптимизацию я тоже понимаю, можно это опустить
вопрос не в том, как решить проблему падения сервера, а как выяснить что конкретно к этому приводит, почему он 3 недели работает норм даже с тяжелыми запросы(которые кстати выполняются в бэкенде и очень трудно поддаются оптимизации), а в один момент перестает отвечать, мне нужно понять где конкретно затык
пока в один момент не уходит в даун, помогает остановка веб-сервера на несколько минут
Уходит в даун или собирается огромная очередь? Ваши действия и объяснения говорят только о том, что база то работает! То что вы стопите веб-сервер просто не дает новых запросов и база оживает.
Или вы все таки базу ребутите?
на сколько знаю, мониторинг Slow Queries есть, он должен помочь с разбором ситуации. Но есть ли, просмотр запросов которые спровоцировали падение — я не в курсе.
В принципе, только что напоролся, на вот такой список: www.thehub.net/index.php?page=search/web&search=mysql+performance+monitor
Думаю, он Вам будет интересен =)
Вот она, Поведение INSERT…ON DUPLICATE KEY UPDATE в крайней ситуации. Проблема будет воспроизводиться, в случае большого количества «INSERT…ON DUPLICATE KEY UPDATE», когда исчерпываются значения auto increment -а
Ошибки не обязательны. На одиночном диске мы столкнулись как-то с проблемой: при отсутствии ошибок и нормальном SMART на каких-то местах пошли сильные провалы по скорости чтения/записи с зависанием системы (Windows) в процессе.
В нашем случае мы «проверили» тупо заменой винта (склонировали всю инфу на новый с помощью Acronis MigrateEasy). Как конкретно в Вашем RAID такие вещи делать, не знаю.
а если индексов нет или он не правильный, и записей мильоны, будет ли разница между таблицей в 4 поля и в 100 полей, если в запросе фигурируют только 4 поля?
Простой
