Проблема с MySQL

Непонятная беда c mysql. Последние пару дней load average зашкаливает, сервер практически не дышит. После перезагрузки в течении часа-двух примерно все относительно нормально, но ЛА растет и в конце концов опять все, кирдык. После mysqladmin reload ЛА падает опять же резко, в течении 5-10 минут опять кирдык. Потенциально проблемные скрипты отключил, хотя работали до этого нормально. С неделю назад апач, мускуль, пхп были обновлены до последних стабильных версий. Но беда началась не с этого момента, а позже. В чем загвоздка может то быть?

P.S. К НГ подарочек, блять.

Поставь mytop, или хотя бы в мускуле show full processlist; выполни во время пика нагрузки, может будет видно что за запросы его грузят.
И включи лог медленных запросов. Ну и покажи my.cnf на всякий случай.

ну так хотя бы mysqladmin processlist посмотри для начала чтобы понять что грузит, раз считаешь что проблема в mysql

сделай repair таблиц, должно нормализоваться.
часто такое бывает когда таблицы битые.

включи логирование длинных запросов (больше 3-4 секунд).
по логу станет понятно, что именно грузит систему.

Не совсем в mysql проблема оказывается. Да, в процесслист убил один процесс зависший, пошустрее стало немного, но все равно, ЛА скачет как сумасшедшая =(

Ну дык ищи какой процесс жрет CPU
А что за сервак и что за скрипты по крону идут? стримротатор?
WP есть гденить?

сервак старенький селерон, но мой то траф тянул безпроблемно. по крону ничего нет, стримов нет, вп есть, но там трафа меньше 1к на 5 блогов
CPU загрузка до 10% в пике, средняя 1-2%, все отваливается по lost connection to...

Последний раз редактировалось: pashtet (31/12/09 в 13:31), всего редактировалось 1 раз

посмотри в top-e какие процессы жрут cpu, там же посмотри не используется ли своп, и нет ли большого iowait, может с дисками что-то не так.

top - 10:45:09 up 11:59, 1 user, load average: 17.76, 30.08, 43.55
Tasks: 193 total, 1 running, 192 sleeping, 0 stopped, 0 zombie
Cpu(s): 4.3%us, 1.3%sy, 0.0%ni, 0.0%id, 94.0%wa, 0.3%hi, 0.0%si, 0.0%st
Mem: 514872k total, 500868k used, 14004k free, 1104k buffers
Swap: 2097144k total, 1506972k used, 590172k free, 17488k cached

Это относительно нормальное состояние.

вполне вероятно, что мало памяти

Да, своп почти весь забит, и 94.0%wa -> высокий лоад и тормоза.
Смотри в топе что жрёт память, хотя конечно память бы добавить надо, но если ты говоришь что раньше нормально работало, может что-то там левое память жрёт.

у меня такая же херня была из-за битых индексов в таблицах

а вот нефиг myisam использовать

В общем, пока вроде решилось апдейтом ядра и каких-то библиотек. Отдельная благодарность админам HQHost typhoon и makc =)
Хотя, и битые индексы тоже были, но без апдейта repair валил мускуль намертво.

Цитата:

а вот нефиг myisam использовать

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

pashtet: яж тебе говорил

Stek писал:

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

для блогов или мини-сайтов для фултекст нужен - то что нужно, для проектов с нагрузкой использование myisam - это прошлый век. хотя на mysqlperformanceblog писали, что видели своими глазами базы на 50гигов с MYI таблицами ))

Цитата:

для проектов с нагрузкой использование myisam - это прошлый век

А что простите вы предложите ?
Были у меня планы перейти на InnoDB , даже на домашнем компе крутил на тесты. Может я проспал, но не перешел из за:

- нет средств восстановления базы данных после креша. А это реально при сбоях питания, проблемах с дисковой системой. После очередного ребута подвисшей системы, мой innodb контейнер просто не поднялся, а в нем было с несколько десятков баз и сотни таблиц.

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

Эхх, рано обрадовался, снова рухнул. Но сейчас внимательно понаблюдал этот процес: часа два все шло как по часам, потом ради теста запустил кодирование в flv небольшого ролика. После кодирования ЛА минут 5-10 было в норме, свапа не было практически. И все, ЛА, свап, wa стали расти в геометрической прогрессии, через 3 часа "кирдык", сервер лежит. Запросов длиннее 32ms не было, таблицы восстановлены. Такое чувство, что мускуль не закрывает соединения, все растет как на дрожжах.

Stek писал:

А что простите вы предложите ?

это кто тебе такие глупости сказал?

почитай про этот формат, он давно уже стандартом стал для больших проектов с нагрузкой (в пределах мускула). в innodb более чем адекватное журналирование, потому, в отличии от myisam, проблемы после хард-ребутов не грозят. после repair-a в myisam еще не ясно, что останется, а innodb хоть и долго поднимается после ребута, за-то сохранность данных в порядке.

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

есть более развитые (чем в myisam) локи, транзакции, роллбеки, кластеризация. одни только локи чего стоят - myisam лочит всю таблицу, вместо одного ряда. тут не вопрос "винда" или "линукс" или "перл" или "пхп", здесь всё очень однозначно.

Минус один - нет fulltext индекса, но он нигде кроме говносайтов, блогов и других мелких проектов не нужен. Согласись. Еще count работает тормознуто и alter table может длиться часами, если в таблице большие индексы. Но, опять-таки, для крупных проектов это не играет никакой роли.

Ну и вообще использование ресурсов железа более выгодное.
Я, к примеру, использую под таблицы не файлы, а raw раздел. Тем самым операции чтения/записи проходят быстрее, потому что нет прослойки в виду работы ОС с файловой системой.

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

Цитата:

о он нигде кроме говносайтов, блогов и других мелких проектов не нужен.

Пиздец, когда же вы наконец поймете, что инет - это 99% говносайты, блоги и прочая мелочь. Тут мало у кого есть сайты, где "alter table может длиться часами".
У ТС к примеру сервер на целероне, вот нахуй там ему вся ебатня с raw разделами и подстройкой "нужны инсерты - сетапь под инсерты, нужны операции чтения - сетапь под них". А если на сервере и вордпресс с селектами и сидж с инсертами типа кристала ? Разорваться ?

Это как человек спрашивает про выпечку булочек в духовке, мол подгорают, а ему начинают про настройку мини пекарен объяснять. Ну хоть не сразу хлебозавод предлагают купить, и то счастье

pashtet: а ты уверен что именно mysql у тебя виноват ? У тебя может просто тупо перестало ресурсов хватать на сервере. Ограничивать память в мускуле, апаче - смотреть кто сколько жрет.

я писал "для проектов с нагрузкой" и именно на это сообщение ты отреагировал вопросом "что простите вы предложите".

ладно, с новым годом всех

Stek писал:

Еugene: а у меня нет проблем с myisam , не вижу причин почему от него надо отказываться. Пиздец,

Нет нет, вы продолжайте, люблю холивары между грамотными людьми =)

Stek писал:

а ты уверен что именно mysql у тебя виноват ? У тебя может просто тупо перестало ресурсов хватать на сервере. Ограничивать память в мускуле, апаче - смотреть кто сколько жрет.

Уже не уверен абсолютно. Просто релоад именно мускуля помогал на некоторое время, вот и уверился. Суть в том, что этот же сервак, бОльший траф держал без проблем то. Он и сейчас эти несчастные 10к держит. Просто в какой-то момент что-то случается и все сыпется. По крайней мере последние наблюдения именно это и показывают. Кстати, мой "селерон" 4 года назад был неплохим и недешевым выбором =)

Если считаешь что скрипты не закрываюь конекты к мускулю, поставь таймауты в my.cnf поменьше, будет рвать конекты само.
Но вообще, ты посмотрел что именно в топе сжирает память? может и не мускуль совсем, врядли он 1.5 гига свопа забивал.