явно есть куда уменьшать это в nginx.
даже если это хостинг картинок, уместно будет и 5-10 секунд.
Опять же, в присутствии мониторинга состояний nginx можно было бы более уверенно рассуждать. Допустим, видно было бы сколько живых запросов, а сколько keep-alive сделать выводы о соотношении и насколько это общее число соединений приближается к критическому 64k. Сделайте мониторинг.
jano, если все действительно правильно сделано и лог все равно пустой, то пробуйте уменьшать пороговое время для запросов - должны появиться. Там же можно дробные значения записывать.
Если даже после 0.1 секунды не появляются, то возможно нагрузка вызвана большим числом простых запросов. Это можно заметить по числу выполненных запросов. Пожалуй, выше 1000 в секунду - уже многовато.
А подтвердить быстрым включением и выключением long_query_time = 0 . Переменные же можно менять на ходу через set global . Запросы там точно должны быть все.
Вот эта настройка редко кому нужна. Только отвлекать будет вас от действительно важных запросов. Уберите и просто считайте по времени.
Dimka, самое очевидное решение - закупить еще IP и в DNS отдавать сразу пачку.
Ну а пока таймауты для TIME_WAIT можно понизить.
это статистика аж с момента перезапуска.
А на самом деле правильно ли вы оцениваете остроту этой проблемы ? Просто посчитайте все типы строчек соединений в netstat .
Плагины для систем мониторинга есть соответствующие чтобы этот ресурс графически представить . Например вот - http://munin-monitoring.org/browser/munin-contrib/plugins/network/tcp-states
Желательно вообще не использовать такую конструкцию.
Если DNS для некоторых IP работает медленно или не работает вообще, вы получите замедление обработки запросов для этих IP секунд на 5-10. Это значит что ресурсы Apache будут заняты в течении 5-10 секунд. То есть, в общем масштабе бесполезный перерасход ресурсов.
daga,как террористы будете по одной картиночке присылать ? огласите ваши требования )
Нет, серьезно. Так дело не сдвинется. Всем вам пишут возможные варианты для размышлений, а не куда именно нажимать.
Ну картинки как картинки. Загрузка ночью подозрительная. Какой-то процесс потреблял 100% одного ядра. Но больше ничего по двум картинкам не сказать. И по трем тоже.
daga, например, встроенный (и не работающий правильно) мониторинг от ispmanager. Там есть галочки специальные -выключите раз на то пошло
Но все равно мало информации. настраивайте munin или хотя бы atop - смотрите историю.
Понятно.
Не забыть, что нет такого бизнеса, который не может простаивать.
Может. Особенно если это сайты для Яндекса, который вообще-то никуда не спешит.
но ведь не все панели используют опцию perl_startup.
ну может быть какой-то пробельный символ? удаляйте все.
Запрос нормально выглядит.
