mysql стоит переносить в первую очередь если дисковая система не справляется с нагрузкой, которою дает сервер БД. Возможно у вас в основном скрипты загружают процессор, а не БД дисковую систему. Хотя если вынести mysql на второй сервер - результат будет заметен. Бюджетней варианта видимо нет. Есть много хостеров которые так и используют БД на отдельном сервере, по обычному каналу.
netwind: local123, я не понял, у вас mysql за два дня так и не заработал? судя по графику, он продолжал работать после пика. если заработал, какая нафиг разница, что СЕЙЧАС показывает программа quota.
Я искренне благодарен за такое внимание моей проблеме.
Если разложить все по полочках, то получается следующее:
-Упал мускул
-Система мониторинга ISPManager подняла его
Если подробнее рассмотреть проблему, то: На сервере Debian 5, ISPManager Pro, включена опция учета размера баз мускула. В нескольких юзеров закончилось свободное место на диске.
Вы здесь немножко подискутировали, и я не могу понятий следующего:
1) Мускул упал потому что закончилась квота дискового пространства в юзера?
2) Что за скачек на графике? Что означает данный график, это увеличилось количество процессов (потоков) мускула?
3) Как мне быть дальше с такими падениями?, Они и раньше били, и будут продолжаться, так можно базы вгрохать
4) Отключение опции учета размера БД в ISPManager теоретически решит проблему падения сервера БД?
5) Как быть если я хочу учитывать размер БД в квоту юзера?
delicate: Судя по логам, то в /var закончилось место, поэтому mysql и рухнул. Выключите логирование, так же если не используете InnoDB, то тоже выключите.
если отправлять почту с помощью php_mail, почта отправляетса через smtp сервер postfix?
mysql стоит переносить в первую очередь если дисковая система не справляется с нагрузкой, которою дает сервер БД. Возможно у вас в основном скрипты загружают процессор, а не БД дисковую систему. Хотя если вынести mysql на второй сервер - результат будет заметен. Бюджетней варианта видимо нет. Есть много хостеров которые так и используют БД на отдельном сервере, по обычному каналу.
netwind, Огромное спасибо!
local123, я не понял, у вас mysql за два дня так и не заработал? судя по графику, он продолжал работать после пика. если заработал, какая нафиг разница, что СЕЙЧАС показывает программа quota.
Я искренне благодарен за такое внимание моей проблеме.
Если разложить все по полочках, то получается следующее:
-Упал мускул
-Система мониторинга ISPManager подняла его
Если подробнее рассмотреть проблему, то: На сервере Debian 5, ISPManager Pro, включена опция учета размера баз мускула. В нескольких юзеров закончилось свободное место на диске.
Вы здесь немножко подискутировали, и я не могу понятий следующего:
1) Мускул упал потому что закончилась квота дискового пространства в юзера?
2) Что за скачек на графике? Что означает данный график, это увеличилось количество процессов (потоков) мускула?
3) Как мне быть дальше с такими падениями?, Они и раньше били, и будут продолжаться, так можно базы вгрохать
4) Отключение опции учета размера БД в ISPManager теоретически решит проблему падения сервера БД?
5) Как быть если я хочу учитывать размер БД в квоту юзера?
а квоты для группы пользователя?
// ключек -g если правильно помню
local123, mysql запускается из под пользователя mysql и квота закончилась у этого пользователя.
надо както по другому проврять квоту для mysql наверное.
Заметил вот такой скачок, в момент когда возникли проблеми с mysql:
использую ISPManager Pro, на Debian 5, если ето чтото меняет
т.е. в некоторых пользователей закончилась квота на диске.
Я правильно понял, это из-за этого mysql перегружаеться???
Судя по логам, то в /var закончилось место, поэтому mysql и рухнул. Выключите логирование, так же если не используете InnoDB, то тоже выключите.
/var - на общем разделе
Но там квоты для каждого пользователя, и в некоторых свободного места не осталось
Разве мускулы падает от того что в некоторых пользователей закончилась квота?? Это возможно?
Юзай putty