Новая тема   Ответить

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

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

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

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

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

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

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

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

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

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

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

 pashtet
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

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

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

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

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

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

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

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

 _s_[sov]
pashtet: яж тебе говорил

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

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

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

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

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

 Еugene
Stek писал:
это кто тебе такие глупости сказал?

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

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

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

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

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

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

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

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

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

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

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

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

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

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