Такая непонятная ситуация: У ноды до краха сервера (апач) было 800 просмотров. После краха(после того как подняли сервер) этой ноды стало 5000 просмотров. Так же еще у нескольких нод выросли просмотры. В чем может быть проблема??
На сервере стоит 1 сайт. Постепенно(за 2 -3 месяца) отъедается память(не понятно чем, в логах ничего нет). Потом сайт не доступен пока не перезагрузишь сервер. После этого и растут просмотры.
Странно у вас как-то настроен сервер, что память не освобождается... Сколько не пытался так воспроизвести на своих "лошадках", все время после нагрузки память освобождалась....
Странно у вас как-то настроен сервер, что память не освобождается... Сколько не пытался так воспроизвести на своих "лошадках", все время после нагрузки память освобождалась....
Что значит сыпится? То есть он может и удалить что-нибудь?
Сыпится это значит в прямом смысле сыпится.
Вот вы, сидите, делаете что-нить важное, тут вам раз, ведро на голову и молотком стунуть, тоже самое испытывает мускуль когда вы заканчивается память и вы сервер ребутите
А крах это ребут имелся ввиду?
У меня на одном сервере тоже апач течет, помог скрипт который его перезапускает по крону, может из-за apc + mod_php, может еще из-за чего протекать стал.
Но даже если он всю память отжирает, все равно перед этим за сутки-двое тормозить все начинало и можно было зайти ssh и убить его (апач) без ребута.
мускуль при этом тоже себя вел неадекватно при утечке, однако искажения данных не заметил, ну и также перезапускал его после такой утечки. Там просто видимо слишком много памяти выделено на apache+php+apc+mysql, до оптимизации ничего не протекало. После оптимизации стало быстрее в 30 раз, но и течь начало.
Перезапуск это одно. Мускуль закрывает таблицы и готовится к отходу в мир иной, ну свой, электронный.
А когда вы ребутите и мускуль в это время работает, то как повезёт
Перезапуск это одно. Мускуль закрывает таблицы и готовится к отходу в мир иной, ну свой, электронный.
А когда вы ребутите и мускуль в это время работает, то как повезёт
Ну не такой уж мускуль и хилый, чтобы сыпаться от ребута. Все-таки не на коленке написан.
Скажу свои две копейки:
1. apache в связке с mod_php - это гарантированная утечка памяти со временем и вопрос его перезапуска - это лишь вопрос времени. Чем навороченней код сайта и чем больше на нём активность, тем быстрее оно загнётся. Решение - писать скрипт остлеживающий количество памяти и как только её станет мало - рестартить apache. Как известно таковой рестарт никаких опасностей в себе не таит - 5 секунд и снова всё работает, а на не очень посещаемом сайте никто даже ничего не заметит.
2. даже после ребута сервера и аварийного завершения MySQL, вероятность сбоя в MySQL очень невелика, если используется журналируемая файловая система типа ext3, ext4 и т.д. Однозначный ответ о том, чем закончился ребут сервера для MySQL можно получить прочитав логи MySQL. Бывает ситуация, когда какая-либо таблица оказывается повреждённой, типа:
101027 0:36:59 [ERROR] /usr/libexec/mysqld: Table './database2/table1' is marked as crashed and should be repaired
тогда необходимо её починить командой:
mysqlcheck --auto-repair database2 table1
но при этой починке некоторые записи из таблицы могут исчезнуть. Поэтому на критичных данных, самое время вспомнить про бакапы.
Комментарии
mysql посыпался drupal таблица
А расскажите как апач "рухнул", интересно очень![Wink](https://drupal.ru/sites/all/modules/contrib/smiley/packs/kolobok/wink.gif)
Может кто-то запустил ab -n 5000 -c 1000 на Вашу ноду?
Логи апача смотрели? там статистика тоже пишется.
На сервере стоит 1 сайт. Постепенно(за 2 -3 месяца) отъедается память(не понятно чем, в логах ничего нет). Потом сайт не доступен пока не перезагрузишь сервер. После этого и растут просмотры.
Наверное у вас эстонский сервер - до него долго доходит, что просмотры были
А после перезагрузки количество просмотров приходит в норму.
Да у нас столько просмотров не может быть. Да замечено, что после каждого краха такая проблема возникает.
Да мускуль у вас сыпится после падений
Странно у вас как-то настроен сервер, что память не освобождается... Сколько не пытался так воспроизвести на своих "лошадках", все время после нагрузки память освобождалась....
дык, cgi небось + память течёт
Что значит сыпится? То есть он может и удалить что-нибудь?
Сыпится это значит в прямом смысле сыпится.
Вот вы, сидите, делаете что-нить важное, тут вам раз, ведро на голову и молотком стунуть, тоже самое испытывает мускуль когда вы заканчивается память и вы сервер ребутите
Понятно, так он ведь может и удалить что-то?
А крах это ребут имелся ввиду?
У меня на одном сервере тоже апач течет, помог скрипт который его перезапускает по крону, может из-за apc + mod_php, может еще из-за чего протекать стал.
Но даже если он всю память отжирает, все равно перед этим за сутки-двое тормозить все начинало и можно было зайти ssh и убить его (апач) без ребута.
мускуль при этом тоже себя вел неадекватно при утечке, однако искажения данных не заметил, ну и также перезапускал его после такой утечки. Там просто видимо слишком много памяти выделено на apache+php+apc+mysql, до оптимизации ничего не протекало. После оптимизации стало быстрее в 30 раз, но и течь начало.
Спасибо за помощь всем. Будем искать проблему.
Перезапуск это одно. Мускуль закрывает таблицы и готовится к отходу в мир иной, ну свой, электронный.
А когда вы ребутите и мускуль в это время работает, то как повезёт
Ну не такой уж мускуль и хилый, чтобы сыпаться от ребута. Все-таки не на коленке написан.
Скажу свои две копейки:
1. apache в связке с mod_php - это гарантированная утечка памяти со временем и вопрос его перезапуска - это лишь вопрос времени. Чем навороченней код сайта и чем больше на нём активность, тем быстрее оно загнётся. Решение - писать скрипт остлеживающий количество памяти и как только её станет мало - рестартить apache. Как известно таковой рестарт никаких опасностей в себе не таит - 5 секунд и снова всё работает, а на не очень посещаемом сайте никто даже ничего не заметит.
2. даже после ребута сервера и аварийного завершения MySQL, вероятность сбоя в MySQL очень невелика, если используется журналируемая файловая система типа ext3, ext4 и т.д. Однозначный ответ о том, чем закончился ребут сервера для MySQL можно получить прочитав логи MySQL. Бывает ситуация, когда какая-либо таблица оказывается повреждённой, типа:
101027 0:36:59 [ERROR] /usr/libexec/mysqld: Table './database2/table1' is marked as crashed and should be repaired
тогда необходимо её починить командой:
mysqlcheck --auto-repair database2 table1
но при этой починке некоторые записи из таблицы могут исчезнуть. Поэтому на критичных данных, самое время вспомнить про бакапы.