Протестировал с другого сервера из того же города (Дубай).
т.е. оба сервера находятся там в ОАЭ, совсем рядом.
DNS на CloudFlare.
Локальных кэширующих DNS нет.
Запускал данный скрипт с VPS, расположенной рядом с dedic продом, 2-мя способами:
1. Без модификаций hosts. (DNS запросы идут в интернет)
2. С модификацией hosts (явно прописал IP)
Оба сервера подключены к интернет через серый IPv4, подсеть датацентра. Без IPv6.
Результаты:
1. Продолжительность теста: ~1 час. Результат: 16 запросов словили ощутимую задержку до 5сек (см. скрин в прикреплении)
2. Продолжительность теста: ~2 часа. Результат: 12 просадок с временем ответа всего до 1 сек, за ДВА часа.
Получается, сам CloudFlare DNS даёт такую просадку? Получается, так.
В варианте 2 (с hosts), случаи, когда запрос занял ~1сек, рассматриваю как погрешность из-за прочего сетевого трафика. Это не 5 и не 17 секунд на запрос, всё-таки.
Получается, раскрутке и продвижению сайта среди юзеров того региона (ОАЭ) это может мешать, и они могут ловить эту задержку в 5 секунд,
а при доступе из РФ - все 17 секунд - и всё это в 0,44% случаев. Получается, так.
И всё из-за DNS..
А чтобы исключить проблему - только ставить свои DNS, и больше серверов с балансером на случай задержек в сети(?). Получается, вроде так.
Только что:
из браузера запрашиваю robots.txt: проблема ЕСТЬ (17 сек)
но локально запущенный на сервере скрипт не выдаёт задержек (в hosts 127.0.0.1 на URL сайта там прописан, обращение идёт на 127.0.0.1)
Виктор Таран, накапливаю результаты, пока что ждём.
Прописал на этом же сервере в hosts имя домена, и с того же сервера запустил скрипт. Пока всё гладко.
(больше не от куда запускать, это единственная машина)
Поймать глюк очень трудно: может проявиться уже через 20 минут, может через несколько часов, а может только на следующий день.
Также, удалось поймать этот же глюк с задержкой 17 секунд на "пустом" файле php, который выводит только текущее время (new DateTime) и простую строку а-ля HelloWorld.
Удаление куки, очистка данных браузера, перезагрузка браузера, - погоды не делают (думал, может где-то глюк в кэше, мало ли).
Пробовал также принудительный вызов session_destroy() со стороны PHP в качестве эксперимента.
Принудительно не получается вызвать проблему. Природа явления пока не ясна.
Примечательно:
1. В системе свободно всего 3Гб оперативной памяти из 64Гб. Из них 50+Гб занимают кэши и прочее: кэш БД, +много пулов php-fpm, + много воркеров nginx. (сервер под постоянной нагрузкой со стороны ERP через Woocommerce REST API. Ошибок по этой части в логах нет.)
2. На системном разделе SSD свободно всего ~5-7Гб.
3. В логах не нашёл явной причины обсуждаемой проблемы. Перелопатил всё: системные логи ОС, логи nginx, php-fpm, mariadb и все остальные.
Также: как только словил данную проблему, повторно словить не получается. Сразу после этого всё "летает". Приходится по-новой подолгу ждать, когда проблема проявится.
На что только не думал: и на медленное создание новых воркеров nginx, и на стек TCP, но ведь ОЗУ свободной хоть сколько-то есть, всё выглядит достаточно цивильно. Не понимаю
+ещё: TCP slow start = 0. Отключен. Дело не в нём.
Провёл strace nginx и php-fpm.
У меня получилось, что в течение этих 17 секунд Wordpress грузит файлы php. Не нашёл явной проблемы именно в куке.
В моём случае, расход ОЗУ близок к лимитам. Как понимаю, сервер компилит/подгружает все файлы php для нового пользователя, но не для каждого. Памяти не хватает, видимо.
(3Гб свободно из 64Гб. 50+Гб занимает кэш, сайт под регулярной нагрузкой и имеет большой кэш)
Оказалось, тормозит в совсем неожиданном месте: при установке cookie для woocommerce.
Запрос поступает на сервер, дальше setcookie для woocommerce, дальше ~17 секунд система тупит. Затем выставляет куку.
Что там происходит, не представляю, т.к. отловить снова эту задержку пока не удалось.
Придётся копать strace, видимо.
Кто-нибудь знает, как правильно мониторить всё, что происходит на сервере при поступлении запроса к сайту?
Именно с strace опыта нет. Как-то не нужно было.
По-видимому, нужно мониторить nginx при помощи strace, прежде всего, и дальше по цепочке (PHP и т.д.)
Вопрос в том: а если проблема, например, где-то в неправильных настройках TCP? За это ведь ОС отвечает. Как это проверить.. не знаю.
Удалось поймать момент, когда проблема есть.
Дамп трафика:
Вот эти строки появляются моментально. Уже хорошо. Значит сигнал доходит на сервер сразу, и проблема не в DNS. Уже конкретика.
Попробую, спасибо. Думал в эту сторону, но это мне представляется практически нереальным: со стороны сервера запускать tcpdump в произвольный момент, отлавливая не очень часто воспроизводимый случай возникновения проблемы.
Надеялся, может есть способ более верный и быстрее.
Но спасибо большое, буду пробовать.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
