apache drupal mysql

Главные вкладки

Аватар пользователя skiller_07 skiller_07 27 октября 2010 в 9:25

Такая непонятная ситуация: У ноды до краха сервера (апач) было 800 просмотров. После краха(после того как подняли сервер) этой ноды стало 5000 просмотров. Так же еще у нескольких нод выросли просмотры. В чем может быть проблема??

Комментарии

Аватар пользователя skiller_07 skiller_07 27 октября 2010 в 10:38

На сервере стоит 1 сайт. Постепенно(за 2 -3 месяца) отъедается память(не понятно чем, в логах ничего нет). Потом сайт не доступен пока не перезагрузишь сервер. После этого и растут просмотры.

Аватар пользователя G.A. Vinogradov G.A. Vinogradov 27 октября 2010 в 10:45

Наверное у вас эстонский сервер - до него долго доходит, что просмотры были Smile А после перезагрузки количество просмотров приходит в норму.

Аватар пользователя Softovick Softovick 27 октября 2010 в 10:52

Странно у вас как-то настроен сервер, что память не освобождается... Сколько не пытался так воспроизвести на своих "лошадках", все время после нагрузки память освобождалась....

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 27 октября 2010 в 10:54

"Softovick" wrote:
Странно у вас как-то настроен сервер, что память не освобождается... Сколько не пытался так воспроизвести на своих "лошадках", все время после нагрузки память освобождалась....

дык, cgi небось + память течёт

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 27 октября 2010 в 11:02

"skiller_07" wrote:
Что значит сыпится? То есть он может и удалить что-нибудь?

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

Аватар пользователя andribas@drupal.org andribas@drupal.org 27 октября 2010 в 11:14

А крах это ребут имелся ввиду?
У меня на одном сервере тоже апач течет, помог скрипт который его перезапускает по крону, может из-за apc + mod_php, может еще из-за чего протекать стал.
Но даже если он всю память отжирает, все равно перед этим за сутки-двое тормозить все начинало и можно было зайти ssh и убить его (апач) без ребута.
мускуль при этом тоже себя вел неадекватно при утечке, однако искажения данных не заметил, ну и также перезапускал его после такой утечки. Там просто видимо слишком много памяти выделено на apache+php+apc+mysql, до оптимизации ничего не протекало. После оптимизации стало быстрее в 30 раз, но и течь начало.

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 27 октября 2010 в 11:14

"<a href="mailto:andribas@drupal.org">andribas@drupal.org</a>" wrote:
ну и также перезапускал его после такой утечки.

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

Аватар пользователя G.A. Vinogradov G.A. Vinogradov 27 октября 2010 в 12:01

RxB wrote:
"<a href="mailto:andribas@drupal.org">andribas@drupal.org</a>" wrote:
ну и также перезапускал его после такой утечки.

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

Ну не такой уж мускуль и хилый, чтобы сыпаться от ребута. Все-таки не на коленке написан.

Аватар пользователя Azerot Azerot 27 октября 2010 в 12:05

Скажу свои две копейки:
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

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