У меня два сайта, размещенных в двух разных дата-центрах. В последнее время один сайт стал очень медленным. Ответ на эхо-запрос от сервера приложений к серверу БД недостаточно быстрый. Как мне исследовать проблему?
On fast server:
10 packets transmitted, 10 received, 0% packet loss, time 8998ms
rtt min/avg/max/mdev = 0.243/0.279/0.502/0.074 ms
On slow server:
21 packets transmitted, 21 received, 0% packet loss, time 20011ms
rtt min/avg/max/mdev = 1.131/1.816/3.584/0.560 ms
Команда tracert показывает следующее:
On fast server:
tracert db
traceroute to db (xxx.xxx.100.101), 30 hops max, 40 byte packets
1 db (xxx.xxx.100.101) 0.552 ms 0.530 ms 0.527 ms
On slow server:
tracert xxx.16.55.140
traceroute to xxx.16.55.140 (xxx.16.55.140), 30 hops max, 40 byte packets
1 xxx.16.55.140 (xxx.16.55.140) 1.859 ms 1.845 ms 1.842 ms
Выполните переход от веб-сервера к серверу базы данных и посмотрите, где сообщается о замедлении. Затем подтвердите, выполнив переход от сервера базы данных к веб-интерфейсу. Используйте IP-адреса узлов, а не DNS-имена. Как указал Уомбл, это может быть замедление работы rDNS.
К вашему сведению, pathping, как и tracert, может предоставлять вводящую в заблуждение информацию о пути просто на основе того, как пакеты могут быть маршрутизированы в одну сторону вперед и в другую сторону в обратном направлении в зависимости от перегрузки сети. Кроме того, не гарантируется, что прямой путь будет одинаковым с каждым увеличенным интервалом. Однако на данный момент это лишние темы. Двигаемся дальше ...
Как только вы определите, где происходит замедление, вы можете продолжить устранение неполадок. Возможно, конечные узлы сами замедляют работу, если они находятся под большой нагрузкой или неправильно настроены каким-либо образом. Если вы узнаете, что такое медленный узел, обновите свои вопросы, добавив соответствующую информацию.
Вы можете использовать traceroute, чтобы увидеть, есть ли на пути точка, которая все замедляет.
Traceroute (mtr даже лучше) путь между двумя машинами, ища определенные переходы, которые увеличивают задержку. После того, как вы определили местоположение, вы можете найти причину (проверьте статистику портов по обе стороны от рассматриваемой ссылки, чтобы увидеть, есть ли очереди или какие-либо другие проблемы); вы не отбрасываете пакеты (ну, не слишком большое их количество - 21 пинг не совсем статистически значимый), поэтому вы наверное нигде не переполняются буферы.
Тем не менее, вы по-прежнему видите задержку только 1,8 мс для «более медленного» канала, что действительно отлично по сравнению с любым видом канала WAN. Если вы что-то не делаете невероятно Чувствительный к задержке (например, высокоскоростная торговля), я изо всех сил пытаюсь представить, как это может быть «очень медленным» в каком-либо значимом смысле.
Передано 10 пакетов, принято 10, потеря пакетов 0%, время 8998 мс
8998 мс - это огромная сетевая задержка. Вы можете использовать mtr, чтобы узнать, не работает ли он в какой-то момент? Как далеко находится дата-центр? Он подключается к Китаю из США? Какая средняя загрузка сервера?
В своем вопросе вы указываете, что сайт стал медленным, а затем спрашиваете о времени пинга. Возможно ли, что сайт работает медленно по другим причинам?
Если вы размещаете два веб-сайта в двух разных центрах обработки данных только с одной базой данных, пропускная способность между двумя центрами обработки данных может быть ограничивающим фактором.
Возможно, стоит проверить, сколько данных вы извлекаете из базы данных в каждом запросе. Нет ничего необычного в том, что 10 МБ возвращаются в запросе к базе данных только для того, чтобы язык сценариев анализировал / искажал / отбрасывал данные, пока не осталось всего несколько КБ для отправки пользователю. Многие люди используют «SELECT *», даже когда им нужно только одно поле. Также стоит проверить, какой объем трафика вы можете видеть на порту вашей базы данных в целом. Если у вас есть только 10-мегабайтная ссылка на другой центр обработки данных, и вы откатываете даже 1-мегабайтный запрос, доставка займет почти секунду.
Если на самом деле ваша проблема связана с задержкой, а не с полосой пропускания, использование постоянных подключений может помочь, поскольку оно позволяет избежать создания совершенно нового TCP-соединения для каждого запроса. Настройка подчиненной базы данных только для чтения во втором центре обработки данных также может помочь, поскольку запросы только для чтения могут выполняться локально.
Стандартное отклонение (mdev) пакетов на "медленном" высоком уровне по сравнению со средним значением. Я бы сказал, что сеть перегружена (либо на уровне хоста, либо на коммутаторе / маршрутизаторе)
Вы можете попробовать использовать iperf в режиме UDP вы получите джиттер.