- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Возникла вчера непонятная для меня проблема при огромном числе посетителей. При первом открытии сайта страница грузилась очень долго (точнее долго не соединялось). То что видел я лично - от 5 до 15 секунд. Проверка по хост-трекеру давала от 3 до 10 таймаутов соединения (в т.ч. несколько Unknown reason). После того как соединение установилось - страница открывались мгновенно, все последующие страницы - тоже. Можно было бы предположить, что в этом случае помогал keep_alive, но он установлен всего на 15 секунд, в то время как страницы нормально открывались и через несколько минут простоя. Сначала сам проверил все логи и никаких ошибок не нашёл, затем попросил сотрудника из systemintegra посмотреть (хвала им за то, что в новогоднюю ночь работают и цены не меняют!) - Антон также подтвердил что никаких ошибок на сервере нет. Ресурсы - в избытке. Всё время top выглядел примерно следующим образом:
top - 20:24:40 up 1 day, 17:31, 1 user, load average: 0.37, 0.40, 0.43
Tasks: 110 total, 1 running, 109 sleeping, 0 stopped, 0 zombie
Cpu(s): 6.3%us, 2.1%sy, 0.0%ni, 90.7%id, 0.2%wa, 0.0%hi, 0.7%si, 0.0%st
Mem: 4055312k total, 1884468k used, 2170844k free, 51952k buffers
Swap: 2104508k total, 0k used, 2104508k free, 1321688k cached
Канал загружен был от силы на 50%. Постоянное обновление server-status апача показывало, что одновременно работает максимум 2-3 соединения. Количество запросов в секунду >100 (статику раздаёт nginx). Т.е. вроде бы и апач не был перегружен. Начал было грешить на проблемы хостера/дата-центра, но можно сказать чудом в новогоднюю ночь удалось пообщаться с руководством дата-центра и мне сказали что проблем нет. Получается что проблема была именно в моём сервере. А дальше чисто случайно обнаружил такую вещь - если рестартануть апач или nginx, то сайт какое-то время сразу открывался мгновенно и ошибок по хост-трекеру вообще не было. Спустя какое-то время всё становлось как было - и частичная недоступность по хост-трекеру, и медленное первое открытие. Когда трафик немного спал - проблема исчезла сама собой.
Такое ощущение, что где-то какая-то очередь забивалась и из-за этого были такие проблемы. Может быть кто-то сможет подсказать в каком направлении стоит "копать"?
Спасибо.
Может быть кто-то сможет подсказать в каком направлении стоит "копать"?
Доверять решение проблем тем, кто это умеет. Покуда не стало поздно. Может теперь вы поняли почему люди покупают услуги администрирования, в то время как "все работает"...
Ничего плохого не хочу сказать про systemintegra - но имея явно максимум информации (были на месте) - они не узнали абсолютно ничего существенного. Боюсь, без существенно более полной информации от вас (тот же вывод mod_status на момент проблемы, top, mysql processlist, статистика munin, настройки _всех_ замешанных сервисов от nginx до апача/sql, и т.п. и т.д.) - угадайки от местных телепатов будут еще менее полезны.
Доверять решение проблем тем, кто это умеет.
Дак тут на форуме каждый второй пишет что он профессионал и "ацкий сотона". Как определить кто действительно умеет?
Аналогично ничего сказать не могу. Но почему такого не может быть, что действительно на первый взгляд (т.е. просмотрев стандартный набор параметров) - действительно ничего криминального не было видно? Ведь, теоретически, в медленном коннекте и провалах на хост-трекере мог быть виноват хостер? Это я уже позже выяснил, что у него проблем не было.
mod_status - описывал в первом посте: ничего особенного там не было. висит 10 свободных процессов (maxclients стоит 150), из них при постоянном обновлении - занято было 2-3, а то и вообще один.
top - прикладывал выше, на протяжении нескольких часов особых изменений также не было.
mysql - фактически не использовался. Сайт самописный - ещё до роста нагрузки я включил своё собственное "кэширование" (страница один раз генерируется и валяется обычным файлом на tmpfs диске. php скрипт проверяет есть ли файл, если есть - считывает его и отдаёт. Запросы к БД отсутствуют).
munin - каюсь, отсутствует. надо будет поставить.
настройки всех сервисов - в целом стандартные для debian 5 + ispmanager lite.
За исключением увеличенных worker_processes до 4, worker_connections 4000 и worker_rlimit_nofile 16000, keep_alive 15 для nginx. Возможно, что-то ещё по мелочи, что не должно оказывать существенного влияния на производительность.
Согласен с myhand - надо смотреть.
Дак тут на форуме каждый второй пишет что он профессионал и "ацкий сотона". Как определить кто действительно умеет?
TC - myhand не кричит, что он Адский СоТоНа ;)
myhand - мне вот что понравилось ;)
Антон также подтвердил что никаких ошибок на сервере нет.
В то время как сайты тупят, сотрудник из systemintegra - говoрит нету ошибок ;) новогодняя сказка ;)
1. У вас выделенный сервер или VPS?
2. Первая страница долго грузится у каждого нового посетителя или только у первых посетителей?
3. Попробуйте зайти сразу на бэкенд http://site.ru:8080/ Проблема в этом случае остается?
4. Попробуйте зайти сразу на бэкенд по IP http://11.22.33.44:8080/ (сайт сделайте сайтом по умолчанию) Проблема в этом случае остается?
1. У вас выделенный сервер или VPS?
2. Первая страница долго грузится у каждого нового посетителя или только у первых посетителей?
3. Попробуйте зайти сразу на бэкенд http://site.ru:8080/ Проблема в этом случае остается?
4. Попробуйте зайти сразу на бэкенд по IP http://11.22.33.44:8080/ Проблема в этом случае остается?
1. Да, выделенный. Core 2 Quad 8300, 4GB.
2. За каждого я не могу говорить, но проверялось с 3х компов (2 разных провайдера) и первое открытие сайта (любой страницы) - происходило медленно. По ощущениям - даже не открытие, а именно соединение. Все последующие запросы к сайту отрабатывались мгновенно. Если даже ничего не открывать в течении нескольких минут (я не засекал, но минут 10 проходило, а то и больше) - а потом снова открыть сайт, то он открывался мгновенно. Если подождать дольше - то снова первое соединение происходило медленно.
3,4. Не догадался проверить :( Сейчас-то уже поздно :) как трафик упал меньше 70-80 запросов к апачу в секунду - всё нормализовалось.
На проблемы с ДНС не было похоже. К сожалению не сохранил результаты проверки site-perf, там больше всего времени (по 5 секунд и больше) тратилось на "connect" (красная полоска), а с некоторых источников - вообще с первой попытки не соединяло, только со второй. причем если запускать повторно - то отрабатывало быстро.
Аналогично ничего сказать не могу. Но почему такого не может быть, что действительно на первый взгляд (т.е. просмотрев стандартный набор параметров) - действительно ничего криминального не было видно?
Вы поставили задачу "определи мне причину такой-то проблемы" или "посмотри что криминального"?
Как определить кто действительно умеет?
Например, не берется за задачу, если не может ее выполнить или она глупа.
Сайт самописный - ещё до роста нагрузки я включил своё собственное "кэширование" (страница один раз генерируется и валяется обычным файлом на tmpfs диске. php скрипт проверяет есть ли файл, если есть - считывает его и отдаёт. Запросы к БД отсутствуют).
Может и в этом дело.
Возможно, что-то ещё по мелочи, что не должно оказывать существенного влияния на производительность.
Дъявол в мелочах. Не хотите предоставлять информацию - продолжайте надеяться на телепатов.
1. У вас выделенный сервер или VPS?
Тебе не видно?
По ощущениям - даже не открытие, а именно соединение.
Может ДНС. Проблема повторялась, если попытаться через несколько минут с того же клиента? Либо тот самый "кеш".
3,4. Не догадался проверить :( Сейчас-то уже поздно :)
Чудо, man ab осилишь самостоятельно?
homer18, у нас была похожая ситуация на похожей конфигурации сервера, кроме одного момента - LA взлетал до 25.0 - 30.0 и держался до 10 минут. Оказалось что, самописные движки сыпали всякий хлам в error.log и ежедневная ротация логов (00:00 по МСК) совпадала со временем пикового посещения посетителей (22.00 по Украине). Ребята из systemintegra заметили и подправили ротацию.
А вообще Вам надо приглашать админа чтобы наблюдал. На форуме, в слепую, Вы диагноз не узнаете ...
homer18, у нас была похожая ситуация на похожей конфигурации сервера, кроме одного момента - LA взлетал до 25.0 - 30.0 и держался до 10 минут. Оказалось что, самописные движки сыпали всякий хлам в error.log и ежедневная ротация логов (00:00 по МСК) совпадала со временем пикового посещения посетителей (22.00 по Украине). Ребята из systemintegra заметили и подправили ротацию.
А вообще Вам надо приглашать админа чтобы наблюдал. На форуме, в слепую, Вы диагноз не узнаете ...
Что-бы вы знали, на будущее, у вас разные ситуации ( земля и небо )
Что-бы вы знали, на будущее, у вас разные ситуации ( земля и небо )
Одинаковые. "Все итак работает, а если я замечу проблему - придет валшебник и исправит за 5 минут и 5$" (тм)
Чудо, man ab осилишь самостоятельно?
По манере общения сразу видно - профессионал.
Document Path: /
Document Length: 21841 bytes
Concurrency Level: 100
Time taken for tests: 1.838 seconds
Complete requests: 2000
Failed requests: 368
(Connect: 0, Receive: 0, Length: 368, Exceptions: 0)
Write errors: 0
Total transferred: 43995608 bytes
HTML transferred: 43681608 bytes
Requests per second: 1087.86 [#/sec] (mean)
Time per request: 91.923 [ms] (mean)
Time per request: 0.919 [ms] (mean, across all concurrent requests)
Transfer rate: 23369.75 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 1.1 0 6
Processing: 5 89 11.3 91 108
Waiting: 3 89 11.4 91 108
Total: 8 90 10.6 91 108
Percentage of the requests served within a certain time (ms)
50% 91
66% 93
75% 94
80% 94
90% 96
95% 98
98% 100
99% 102
100% 108 (longest request)
Посмотрел в логах почему 368 Failed - там размер у них на 1 байт отличается.
P.S. Сервер сейчас под нагрузкой. По статистике LiveInternet >5000 online. Проблемы были вчера когда онлайн было >25000.