- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Если честно, я что-то в небольшом шоке от того, что написано по этой ссылке.
Я думаю, что это может дать совершенно обратный эффект. У ТС очередь останавливается на одном количестве коннектов, а тут ещё и до дикого количества может дойти. Потом либо упадёт всё, либо mysql может не выйти из ступора.
Либо произойдет разблокировка таблиц на большом числе коннектов (а мускул на мощном железе спокойно их вытянет десятки тысяч) и очередь рассосется. Других решений без корректировки скриптов и просмотра, где именно идет блокировка, не получится дать. Так что только так :)
на мой взгляд, кеш запросов просто гигантский. Запросы на обновления могут залипать как угодно.
в 5.1 в slow.log уже можно наблюдать Lock time и отделить заблокированные запросы от действительно тормозящих.
Но вообще, очень уж это неблагодарное дело эта диагностика по icq. Искать и гадать будете долго.
Вы бы лучше переехали обратно на linux и поставили сборки 5.0 от percona или ourdelta - существенно выиграете в диагностических возможностях.
Например, тут бы пригодилось автоматическое профилирование медленных запросов. В официальных сборках его нет, а оно точно бы дало ответ не тратится ли куча времени на очистку query cache. Для freebsd ничего подобного нет.
Либо произойдет разблокировка таблиц на большом числе коннектов (а мускул на мощном железе спокойно их вытянет десятки тысяч) и очередь рассосется. Других решений без корректировки скриптов и просмотра, где именно идет блокировка, не получится дать. Так что только так :)
Ну это не решение проблемы :)
Тут скорее просто позволим mysql обрабатывать ещё запросы в момент "тормозов", но саму причину так вряд ли получится ликвидировать.
Либо другая ситуация, когда запросы в состоянии locked и новые запросы просто не обрабатываются. Тогда получим так же на 100% забитую очередь, но уже бОльшего количества.
мускуль затыкается и пока какой-то запрос не отработает,
все остальные запросы ждут
Скорее всего блокировки, если действительно они, переведите таблицы, на которых чаще всего возникают блокировки, в InnoDB.
Скорее всего блокировки, если действительно они, переведите таблицы, на которых чаще всего возникают блокировки, в InnoDB.
Кстати, вот этой уже дельная мысль.
mysqltuner не пробовали? как вариант для гармонизации и исключения момента кривых настроек my.cnf, на пути решения проблемы как таковой?
Что касается настроек.., иногда такие вещи показывает - полезные, можно исходя "из" игратся дальше руками.
Пробовали - ничего интересного не дало
Знакомая ситуация, стучите, расскажу в чем там дело
Andreyka, ну вам не стыдно? рассказывайте всем вашу версию, о великий повелитель пишуших обезьянок.
Вы бы лучше переехали обратно на linux и поставили сборки 5.0 от percona или ourdelta - существенно выиграете в диагностических возможностях.
Например, тут бы пригодилось автоматическое профилирование медленных запросов. В официальных сборках его нет, а оно точно бы дало ответ не тратится ли куча времени на очистку query cache. Для freebsd ничего подобного нет.
Обычно, специалисты по высоконагруженным системам рекомендуют именно freebsd для mysql, т.к. оно может давать гораздо лучшую производительность чем на линуксе. Есть общедоступные бенчмарки.
Я подозреваю, что my.cnf не в порядке. Сказать что именно сложно, попробуйте как уже советовали mysqltunner, переведите в innodb и посмотрите другие средства (в том числе патчи) по мониторингу и логам, которые могут помочь. + поставьте этот сервер на общий мониторинг (CPU, Memory, кол-во запросов mysql и т.п.)
MIRhosting.com добавил 11.03.2010 в 21:31
Andreyka, ну вам не стыдно? рассказывайте всем вашу версию, о великий повелитель пишуших обезьянок.
Это его стиль)
Обычно, специалисты по высоконагруженным системам рекомендуют именно freebsd для mysql
пруф? так как есть абсолютно противоположная информация. Например широкоизветсная в узких кругах тема на 3nity.ru.