Shi3A: Ну в чем проблема-то ребят?
Ставим для проблемных айпишников (а лучше плюс для юзерагентов) принты, колбэки, что душе угодно в скриптах. Гоняем пользователей - находим где затуп, если он в движке.
Вторым, чтобы я посмотрел - что там с БД происходит, может ее косяк и она обрабатывает по 3 минуты запросы, ну мало ли, бывает.
Если все нормально, мониторим nginx или что у вас там стоит в качестве веб-сервера (фаербаг в мозилле найтли криво работает, зараза :( ), на предмет его косяков в настройке.
Если и тут ничего нет, смотрел бы трафик на сетевой, куда что приходит и почему не уходит, если все чисто - то проблема где-то на стыке между сервером и клиентом. (Хотя наверно с этого можно и начать, чтобы сразу отбросить муторный мониторинг сервисов :) )
UPD:
yarp1: >>>Да запросто может быть вирус! Если он живет у вас на сервере и отвечает только ХР'шкам
Этот вариант тоже исключен.
Почему вы так категорически исключаете этот вариант?
Да и потом, может проблема вовсе не в вас, а в каком-либо внешнем подключаемом js-скрипте?
Ставим для проблемных айпишников (а лучше плюс для юзерагентов) принты, колбэки, что душе угодно в скриптах. Гоняем пользователей - находим где затуп, если он в движке.
Вторым, чтобы я посмотрел - что там с БД происходит, может ее косяк и она обрабатывает по 3 минуты запросы, ну мало ли, бывает.
Если все нормально, мониторим nginx или что у вас там стоит в качестве веб-сервера (фаербаг в мозилле найтли криво работает, зараза :( ), на предмет его косяков в настройке.
Если и тут ничего нет, смотрел бы трафик на сетевой, куда что приходит и почему не уходит, если все чисто - то проблема где-то на стыке между сервером и клиентом. (Хотя наверно с этого можно и начать, чтобы сразу отбросить муторный мониторинг сервисов :) )
mvolgin: Вот я непониманию как человек может арендовать сервер и не понимать где проблемы у него или в дата центре. Это же блин на гране элементарного.
Какой ты агрессивный, однако :)
Мало ли какие у меня были причины спросить?
P.S. Я убегал по очень срочным делам, и возрастание пинга с 90 на 250 не пересекало по критичности моих дел. А так я потом с телефона зашел и увидел что ни у кого никаких проблем. :-P Значит можно расслабиться
yarp1: Так вот мы голову и ломаем.. как будто перед местными выборами (а был и ддос) всем персональные вирусы послали, чтобы наш адрес не открывался.
но почему у всех, у кого глючит, именно xp-шки... никаких мыслей нет? нет, у подавляющего числа клиентов на xp всё норм. но у тех, у кого выявлены глюки, только xp... единственное, что их объединяет
Пуск - выполнить - cmd - и там команду tracert yarportal.ru или какой у вас там сайт, посмотрите, какой айпишник отзывается последним (должен быть натуральный ip-сервера, на котором сайт висит), это раз, второе - где самый большой скачок отклика ответа будет. Ну и там уже решайте, что да как.
netwind: вот этим не увлекайся : wait_timeout = 120 interactive_timeout = 15
Судя по манам, эти значения задаются в секундах, мне же сервер отвечает в момент, как только нажимаю enter после запроса. или для консоли mysql закрывается соединение в течение 15 секунд безактивности?
Но теперь посмотрел mysql, он мне на каждый запрос отвечает
CREATE DATABASE `db_name` DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci; ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect... Connection id: 67946 Current database: *** NONE ***
Query OK, 1 row affected (0.00 sec)
GRANT ALL PRIVILEGES ON db_name.* TO 'my_user'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION; ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect... Connection id: 67993 Current database: *** NONE ***
netwind: А почему не может? Связана или нет проблема с кешем может подтвердить профилирование запросов, но попробовать проще.
Отключил кеш, забегало в разы лучше, спасибо! Видимо запросы каждый раз перестраивали кеш, что только вредило. Буду профилировать запросы, может еще что добьюсь, но за наводку спасибо огромное!
И раз уж пошла такая пьянка, не подскажите, как мне сократить число Temporary tables created on disk? И что порекомендуете? Все же оптимизировать запросы под кеш, или насиловать диски?
Pavel.Odintsov: Покажите iostat -x. Если последние поля у винтов более 20%, то в магазин за нормальными SAS жесткими дисками либо SSD.
19.88 и 20.30
madoff: TC надо смотреть вашу БД - на предмет оптимизаций.
Могу ошибаться (не я администрирую сайт), но кажется там стандартный набор друпаловских модулей, никаких своих не писано.
Andreyka: У drupal куча механизмов кеширования, их просто надо задействовать.
Увы, на высокопосещаемом сайте кеширование друпала только вредило (как минимум на еще одного такого наткнулся, как я)
Поставил модуль boost - шикарный модуль, но за 2 часа аптайма mysql только он рапортует о медленных запросах (>5 секунд), но я уверен что его еще можно поднастроить. Буду признателен, если дадите еще ссылки на какие-либо модули для оптимизации.
Ну в чем проблема-то ребят?
Ставим для проблемных айпишников (а лучше плюс для юзерагентов) принты, колбэки, что душе угодно в скриптах. Гоняем пользователей - находим где затуп, если он в движке.
Вторым, чтобы я посмотрел - что там с БД происходит, может ее косяк и она обрабатывает по 3 минуты запросы, ну мало ли, бывает.
Если все нормально, мониторим nginx или что у вас там стоит в качестве веб-сервера (фаербаг в мозилле найтли криво работает, зараза :( ), на предмет его косяков в настройке.
Если и тут ничего нет, смотрел бы трафик на сетевой, куда что приходит и почему не уходит, если все чисто - то проблема где-то на стыке между сервером и клиентом. (Хотя наверно с этого можно и начать, чтобы сразу отбросить муторный мониторинг сервисов :) )
UPD:
>>>Да запросто может быть вирус! Если он живет у вас на сервере и отвечает только ХР'шкам
Этот вариант тоже исключен.
Почему вы так категорически исключаете этот вариант?
Да и потом, может проблема вовсе не в вас, а в каком-либо внешнем подключаемом js-скрипте?
Ну в чем проблема-то ребят?
Ставим для проблемных айпишников (а лучше плюс для юзерагентов) принты, колбэки, что душе угодно в скриптах. Гоняем пользователей - находим где затуп, если он в движке.
Вторым, чтобы я посмотрел - что там с БД происходит, может ее косяк и она обрабатывает по 3 минуты запросы, ну мало ли, бывает.
Если все нормально, мониторим nginx или что у вас там стоит в качестве веб-сервера (фаербаг в мозилле найтли криво работает, зараза :( ), на предмет его косяков в настройке.
Если и тут ничего нет, смотрел бы трафик на сетевой, куда что приходит и почему не уходит, если все чисто - то проблема где-то на стыке между сервером и клиентом. (Хотя наверно с этого можно и начать, чтобы сразу отбросить муторный мониторинг сервисов :) )
полную диагностику на вирусы делали. да и не может вирус так избирательно на наш сайт (сервер) был направлен..
Да запросто может быть вирус! Если он живет у вас на сервере и отвечает только ХР'шкам
Может хватит спамить свой "портал"?
После его второго сообщения у меня точно такое же стойкое впечатление.
Вот я непониманию как человек может арендовать сервер и не понимать где проблемы у него или в дата центре. Это же блин на гране элементарного.
Какой ты агрессивный, однако :)
Мало ли какие у меня были причины спросить?
P.S. Я убегал по очень срочным делам, и возрастание пинга с 90 на 250 не пересекало по критичности моих дел. А так я потом с телефона зашел и увидел что ни у кого никаких проблем. :-P Значит можно расслабиться
Доброго времени суток, у всех наплывами тормозит сетка? С 80-90мс пинги задерживаются до 200-250, или это мои локальные проблемы?
В частности пока заметил на сервере в DC13.
Так вот мы голову и ломаем.. как будто перед местными выборами (а был и ддос) всем персональные вирусы послали, чтобы наш адрес не открывался.
но почему у всех, у кого глючит, именно xp-шки... никаких мыслей нет?
нет, у подавляющего числа клиентов на xp всё норм. но у тех, у кого выявлены глюки, только xp... единственное, что их объединяет
Пуск - выполнить - cmd - и там команду tracert yarportal.ru или какой у вас там сайт, посмотрите, какой айпишник отзывается последним (должен быть натуральный ip-сервера, на котором сайт висит), это раз, второе - где самый большой скачок отклика ответа будет. Ну и там уже решайте, что да как.
вот этим не увлекайся :
wait_timeout = 120
interactive_timeout = 15
Судя по манам, эти значения задаются в секундах, мне же сервер отвечает в момент, как только нажимаю enter после запроса. или для консоли mysql закрывается соединение в течение 15 секунд безактивности?
Добрый день, снова я.
Сайт забегал, всем спасибо.
Но теперь посмотрел mysql, он мне на каждый запрос отвечает
С чем это связано? О_О
Кешируй для анонимных пользователей через nginx.
Это все настроено, но к друпалу отношение это не имет =)
А почему не может?
Связана или нет проблема с кешем может подтвердить профилирование запросов, но попробовать проще.
Отключил кеш, забегало в разы лучше, спасибо! Видимо запросы каждый раз перестраивали кеш, что только вредило. Буду профилировать запросы, может еще что добьюсь, но за наводку спасибо огромное!
И раз уж пошла такая пьянка, не подскажите, как мне сократить число Temporary tables created on disk? И что порекомендуете? Все же оптимизировать запросы под кеш, или насиловать диски?
Покажите iostat -x. Если последние поля у винтов более 20%, то в магазин за нормальными SAS жесткими дисками либо SSD.
19.88 и 20.30
TC надо смотреть вашу БД - на предмет оптимизаций.
Могу ошибаться (не я администрирую сайт), но кажется там стандартный набор друпаловских модулей, никаких своих не писано.
У drupal куча механизмов кеширования, их просто надо задействовать.
Увы, на высокопосещаемом сайте кеширование друпала только вредило (как минимум на еще одного такого наткнулся, как я)
Поставил модуль boost - шикарный модуль, но за 2 часа аптайма mysql только он рапортует о медленных запросах (>5 секунд), но я уверен что его еще можно поднастроить. Буду признателен, если дадите еще ссылки на какие-либо модули для оптимизации.