Админка грузится 17 секунд, а виноват DNS

Что показывал профайлер

Первое, что стоит сделать при жалобе на скорость, — перестать гадать и посмотреть, где уходит время. Встроенный профайлер разложил страницу так:

Такое распределение сразу отсекает половину гипотез. База отвечает за девятнадцать миллисекунд — значит дело не в индексах и не в тяжёлых выборках. Компоненты укладываются в пятнадцать миллисекунд — значит дело не в шаблоне и не в отсутствии кеша. Всё время съедает пролог, то есть то, что происходит до единой строки полезной работы.

Разница между авторизованным и анонимным заходом — важнейшая подсказка. Она означает, что медленный код выполняется только для тех, у кого есть права: проверки лицензии, обновлений, уведомлений. Аноним до этого кода просто не доходит.

Почему пролог может занимать 17 секунд

В прологе админ-режима живёт проверка обновлений. Она ходит наружу по HTTPS. Пока сеть отвечает, это незаметно — десятки миллисекунд. Если внешний адрес не отвечает, страница честно ждёт таймаута, и никакой кеш тут не поможет: запрос уходит раньше, чем начинается полезная работа.

Проверяется это одной командой — и проверять надо не «интернет вообще», а именно исходящие запросы с самого сервера:

# Сколько на самом деле занимает обращение наружу
curl -o /dev/null -s -w 'код %{http_code}, время %{time_total}\n' \
  https://www.1c-bitrix.ru/

# было: код 000, время 20.001   ← ровно таймаут, ответа нет
# стало: код 200, время 0.213

Двадцать секунд ровно — это не «медленно», это таймаут. Число, подозрительно похожее на круглое, почти всегда означает не нагрузку, а ожидание того, чего не будет.

Где именно рвалось

Дальше вопрос простой: сеть не работает вообще или не работает разрешение имён? Это разные диагнозы с разной ценой.

# Резолв через DNS-сервер, прописанный на машине
dig www.1c-bitrix.ru
# ;; connection timed out; no servers could be reached

# Тот же запрос, но мимо него — к публичному резолверу
dig @8.8.8.8 www.1c-bitrix.ru +short
# 178.248.233.117        ← 50 мс

# Что вообще прописано в системе
cat /etc/resolv.conf
# nameserver 192.168.137.1     ← он и не отвечает

Картина сложилась: TCP-трафик через шлюз идёт, а DNS-запросы к нему уходят в никуда. Сервер — виртуальная машина, адрес резолвера ей выдавал по DHCP хост, и в какой-то момент хост перестал отвечать на запросы имён, продолжая маршрутизировать остальное. Снаружи это выглядит как «сайт работает, но админка тормозит».

В журнале ошибок самой CMS нашлась запись, сделанная за четыре дня до обращения клиента: «getaddrinfo failed: Name or service not known». Проблема была старше жалобы почти на неделю.

Почему это заметили только сейчас

Самая поучительная часть истории. До нашего появления вход в админку падал с фатальной ошибкой — после прерванного обновления ядра на диске осталась папка-двойник модуля. Никто не мог войти, а значит никто и не видел, что после входа всё медленно.

• Мёртвый резолвер существовал минимум четыре дня и никого не беспокоил
• Вход в админку был сломан грубее — до фатальной ошибки
• Мы починили фатальную ошибку, вход заработал, проверка обновлений начала реально ходить наружу
• И только тогда «тормоза» стали видимыми — хотя существовали и раньше

Отсюда практическое правило: после починки крупной поломки проверяйте систему заново целиком. Грубая ошибка часто работает как заглушка и прячет за собой вторую, более тихую. Клиенту при этом кажется, что «после вашей правки стало хуже».

Починка, и почему одной команды мало

Предыдущий администратор уже пытался прописать рабочие резолверы и решил, что не помогает. Команда была правильной, но применялась к соединению с именем `eth0`, а в системе соединение называлось иначе — «Wired connection 1». Команда отрабатывала вхолостую.

# Сначала смотрим, как соединение называется на самом деле
nmcli -g NAME,DEVICE con show
# Wired connection 1:eth0     ← имя соединения ≠ имя устройства

nmcli con mod "Wired connection 1" ipv4.dns "8.8.8.8 1.1.1.1"

# Ключевая строка: без неё DHCP при обновлении аренды
# вернёт мёртвый резолвер обратно, и всё повторится
nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes

# Применяем без разрыва SSH-сессии
nmcli device reapply eth0

Второй флаг здесь важнее первого. Без него настройка живёт до следующего обновления аренды DHCP: резолверы молча вернутся к прежним, а проблема — через неделю, когда связь с правкой уже забудется.

Результат проверяется теми же командами, которыми ставился диагноз. Разрешение имён — 50 мс вместо таймаута, обращение наружу — 0,21 с вместо двадцати секунд, страница админки открывается нормально.

Что забрать себе

• Круглое время ответа — 20, 30, 60 секунд — это таймаут, а не нагрузка. Ищите, чего сервер ждёт, а не что он считает
• Разница между анонимом и авторизованным пользователем сужает поиск быстрее любого профайлера
• Проверяйте исходящие запросы с самого сервера, а не «интернет работает». Маршрутизация и разрешение имён ломаются по отдельности
• После починки крупной поломки перепроверяйте систему целиком: она могла прятать вторую
• Правя сетевые настройки, всегда фиксируйте их так, чтобы DHCP не откатил их обратно

И общий вывод, ради которого стоит помнить эту историю: «тормозит» — это не диагноз, а симптом, и в половине случаев причина лежит вне кода. Профайлер, который показывает пустую базу и пустые компоненты, говорит именно об этом.