ncux

Рейтинг
101
Регистрация
05.09.2005
Alexei42:
В логах-то (messages, syslog) что-нибудь есть?

В еррор_логах куча записей

[client 127.0.0.1] Directory index forbidden by Options directive: /var/www/html/

В access_log куча

"GET / HTTP/1.0" 403 5043 "-" "Apache/2.2.3 (CentOS) (internal dummy connection)"

На обоих ВПС

Syslog вообще не нашел, a в messages множатся записи вида:

START: smtp pid

EXIT: smtp status=

С разных IP.

ncux добавил 21.08.2008 в 21:49

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

Что именно писать? У меня каждые 5 минут стоит на крон запись ps -aux и netstat. Ничего особенного в момент падения я не видел. Сегодня сервер упал при нагрузке базы 5,8% (отоптимизировал FULLTEXT), раньше эта цифра доходила до 13%. При чем после перезагрузки сервера эта цифра была равна 4% и росла, примерно по 0,1 каждые полчаса.

Kpd:
Посмотрите vmstat, скорее всего это mysql тормозит на операциях с диском (последний или предпоследний столбец, не помню). Прибавьте памяти для буфера но чтобы это не уходило в swap. Погуглите оптимизацию mysql. Скорее всего индекс базы данных не помещается в оперативку, которую вы ему выделили в my.cnf

Вот что интересно. Раньше не было индексов - база падала раз в день. Потом проставил индексы, отключил кучу update (считали посещаемость отдельных страниц на лету), снял тяжелые поисковые формы - результат не изменился. Очень странно..

vmstat вот что говорит:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------

r b swpd free buff cache si so bi bo in cs us sy id wa st

2 0 0 14670408 110984 388996 0 0 0 0 0 290 1 0 99 0 0

Так понимаю, что инпут/аутпут вообще не задействован, в свопе никого нет. Жаль не получается посмотреть данную статистику в момент падения, т.к. весь сервер валится и не получается даже подключиться по руту :(

ncux добавил 21.08.2008 в 21:32

manman:
проц до 25-30%. - это холодный , скорее всего на сортировках отжирает.
в общем вывод - для начала выдать ему оперативы чтобы индексы влезли, чтобы открытые таблицы держал, чтобы кеш запросов влез.
и внимательно смотрите что за процесс висит - одного процесса достаточно чтобы все лагануло,
( у меня это например delete по условию где в условие попадет 10 млн записей- удаяет до 8часов ...

У меня база-то малюсенькая! Две таблицы по 35мб (22к и 45к строк), остальные (штук 20) - на много меньше. Уже 2 недели не сплю, мануалы и форумы читаю - там у людей проблемы начинаются с 8гб базами на MyISAM.

manman:
20-25 чего? проц? или loadaverage?

хотя бы 20 % оперативы ему дайте под кейбуфер. хотя некторые рекоммендуют до 1\2.
второе - тупняки процессора на селектах или на delete?
и посмотрите собственно - что во время тупняка делается в запросах к муслкулю. вдумчивое чтение процесслиста позволяет или опимизировать базу, или запросы.
логи помотрите - может мускуль падает уже после всех остальных демонов типа апачей?

Речь о loadaverage. Top в среднем оказывает:

Cpu(s): 1.0% us, 0.3% sy, 0.0% ni, 98.7% id, 0.0% wa, 0.0% hi, 0.0% si

При этом mysqld периодически загружает проц до 25-30%.

Поставил кейбуферу 96 метров, посмотрим что будет. В процесслисте в любое время висит не более 3-х спящих запросов. Чаще всего - один. Ни разу не видел там ни одного зависшего запроса работы с базой. Собственно, поэтому и не могу понять какие процессы вешают базу...

Alexei42:
key_buffer

key_buffer_size 8388600

Еще и процессор начинает жрать кучу ресурсов. Раньше доходило до 20-25 и падало. после оптимизации страниц стало доходить до 3-4 и все равно падает :(

Kpd:
Собственно, вы сами ответили
Сколько всего памяти? Сколько выделили под индекс базы?

На одном ВПС - 2 Гб, на другом 768.

Не подскажете, где посмотреть размер по индекс? В май.цфг похожего не нашел.

301 редирект поставить со старых урлов на новые.

header("HTTP/1.1 301 Moved Permanently");

Спустя два месяца после выхода из фильтра из-за сапы опять под него попал:) На этот раз сразу написал Платону. В ответ мне сказали, что все хорошо, и это проблемы с индексацией. Но на следующий день "в догонку" получил письмо о том, что мой сайт ссылается на спам-ресурсы.

Всего у меня было около 100 продажных ссылок (не более двух на страницу), всего страниц - 90 000. Все сайты проверял вручную (видимо, просмотрел...). Саповский код был "замаскирован".

Получается, никуда от яшки не деться.

Еще раз убедился в "правильности" апа:

http://yandex.ru/yandsearch?rpt=rad&text=%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%20%D0%B1%D0%B0%D0%BB%D0%B0%D1%88%D0%B8%D1%85%D0%B0

Места: 5,7,9. Вроде, получается, ТОП-3 посмотрел и хватит, дальше можно даже не пытаться что-то найти.

У меня похожая ситуация. Сапу не употреблял:) Вчера пришел ответ Платона:

"Благодарим Вас за то, что обратили наше внимание на проблемы с индексированием

Ваших сайтов. Мы постараемся в скором времени определить, по какой причине они

отсутствуют в поиске."

location header, на сколько я знаю, отдает 302 ошибку. Вот что о ней написано в хелпе Яндекса.

302 Ресурс временно перемещен

Запрошенный ресурс временно находится под другим адресом (получен код 302 Moved Temporarily).

Так как пользователи не смогут увидеть подобные документы, показывать их в поиске не имеет смысла, и робот их не индексирует. Однако робот обязательно проиндексирует страницу, на которую установлено перенаправление.

Всего: 185