Comments 19
Так и в чем мораль? не юзать bitrix?
Это конечно увлекательно так искать проблемы, но если бы у вас стоял newrelic хватило бы одного взгляда.
после обнаружения долгого session_start при хранении сессий в файлах, надо искать долгоиграющий параллельный запрос от того же пользователя, очевидно же
что интересно, хранение сессии в memcached проблему не решало. К тому же сыграло роль то что похожая проблема была относительно недавно на другом сервере, и там в итоге виноваты оказались винты, которые пришлось заменять. Вот мысль и ушла не в том направление :(
Так не важно же файлы или не файлы в этом случае.
И вообще по факту session_start тут только усугубляет проблему производительности и ни о чем не говорит.
И вообще по факту session_start тут только усугубляет проблему производительности и ни о чем не говорит.
> Цепляемся с помощью strace.
Всегда делаю это сразу после того, как посмотрю в логи. Если нагрузка большая, то сначала смотрю в tcpdump на исходящие коннекты к 80/443, потом уже иду к владельцу проекта с просьбой положить всё это дело минут на 10, чтобы снять strace с тормозящих запросов.
Ни разу не подводило, хотя бы косвенно, но проблема всегда находилась сразу после прочтения одного трейса тормозящего запроса.
Чего и вам советую )
Всегда делаю это сразу после того, как посмотрю в логи. Если нагрузка большая, то сначала смотрю в tcpdump на исходящие коннекты к 80/443, потом уже иду к владельцу проекта с просьбой положить всё это дело минут на 10, чтобы снять strace с тормозящих запросов.
Ни разу не подводило, хотя бы косвенно, но проблема всегда находилась сразу после прочтения одного трейса тормозящего запроса.
Чего и вам советую )
тут немного мешало то что было сложно поймать какой именно процесс обрабатывает тормозящий запрос. Потому что тормоза наблюдались в одном процессе. И strace тоже бы привел к ожиданию сессии, хотя другой процесс в этот момент и подвисал :(
Но да, strace надо было использовать раньше. Сэкономило бы время. Как я и написал в итоге.
Но да, strace надо было использовать раньше. Сэкономило бы время. Как я и написал в итоге.
Можно на пару минут запустить strace на все процессы апача, записать всё в один лог, потом по логу nginx найти тех, кто ушел с 499 (или 502 с 60 секунд в вашем случае, скорее всего, или 200-кой с адским временем ответа), потом грепом найти нужный трейс.
> тоже бы привел к ожиданию сессии
Ну там в 3-4 раза процесс медленнее начинает работать, до 60 секунд не дошло бы.
А ещё можно сразу писать с -r и искать те сисколлы, которые выполняются несколько секунд (в вашем случаем можно было бы сразу 50+ секунд искать), так даже быстрее (но это работает только в случаях, когда нужно найти сильные тормоза, на тормозах меньше секунды так сложнее искать).
> тоже бы привел к ожиданию сессии
Ну там в 3-4 раза процесс медленнее начинает работать, до 60 секунд не дошло бы.
А ещё можно сразу писать с -r и искать те сисколлы, которые выполняются несколько секунд (в вашем случаем можно было бы сразу 50+ секунд искать), так даже быстрее (но это работает только в случаях, когда нужно найти сильные тормоза, на тормозах меньше секунды так сложнее искать).
У меня был такой же сложный сайт на битриксе. Подобные проблемы, действительно, быстро решались с помощью XHProf (XHGui лучше сразу ставить).
Иначе, можно искать тормоза месяцами.
Иначе, можно искать тормоза месяцами.
Спасибо за интересную статью!
Раскрылись глаза на такую казалось мелочь — session_start() и блокировки файлов сессий!
А я всё понять не мог, почему на нашем небольшом бэкэнде невозможно открытие на загрузку одновременно нескольких страниц, а выдавал только по одной… думал ограничения в браузере какое-то, или веб-сервер на одного клиента не дает больше процессов выполнять… а оказалось это просто блокировки файлов от session_start!
Раскрылись глаза на такую казалось мелочь — session_start() и блокировки файлов сессий!
А я всё понять не мог, почему на нашем небольшом бэкэнде невозможно открытие на загрузку одновременно нескольких страниц, а выдавал только по одной… думал ограничения в браузере какое-то, или веб-сервер на одного клиента не дает больше процессов выполнять… а оказалось это просто блокировки файлов от session_start!
Тут стоить заметить, что это совсем не мелочь и, что в официальной доке по start_session про блокировки сказано, а вот в разных «учебниках» обычно нет.
Да что-то совсем про это ничего не сказанно: http://php.net/session_start
Грусть, однако, в переводе нет, а вам похоже по умолчанию как раз перевод отдается.
Я то специально вот сюда смотрел, тут есть, в блоке options:
php.net/en/session_start
Я то специально вот сюда смотрел, тут есть, в блоке options:
php.net/en/session_start
Собственно, информация там о блокировка есть в базовом описании работы с сессиями, например вот тут даже в переводе:
php.net/manual/ru/session.examples.basic.php
Процитирую оттуда:
php.net/manual/ru/session.examples.basic.php
Процитирую оттуда:
Замечание:
Сессии, использующие файлы (по умолчанию в PHP), блокируют файл сессии сразу при открытии сессии функцией session_start() или косвенно при указании session.auto_start. После блокировки, ни один другой скрипт не может получить доступ к этому же файлу сессии, пока он не будет закрыт или при завершении скрипта или при вызове функции session_write_close().
Скорее всего это станет проблемой для сайтов, которые активно используют AJAX и делают несколько одновременных запросов. Простейшим путем решить эту проблему будет вызов функции session_write_close() сразу же как только все требуемые изменения в сессии будут сделаны, предпочтительно ближе к началу работы скрипта. Также можно использовать другой механизм сессии, который поддерживает конкурентный доступ.
Блокировка сессии — это перебдение в 99% проектов.
Sign up to leave a comment.
Плохая «Весна» или как причины задержек искали