Я работаю аналитиком-программистом в своей организации и обнаруживаю некоторую временную проблему с тайм-аутом при использовании запросов CVS и HTTP в нашей сети.
После тайм-аута запрос действительно завершается, хотя это занимает чуть более 60 секунд, поэтому я предполагаю, что это какая-то проблема с переключением на тайм-аут.
Я хочу попытаться выяснить, как определить, если возможно, в чем проблема, я предполагаю, что где-то выполняется неправильный маршрут или что-то не так с одним из DNS-серверов. Команда инфраструктуры сказала мне, что с сетью нет никаких проблем, и лично я считаю, что это отговорка.
У меня есть root-доступ к двум машинам Linux (RHEL 5.4).
Прошу прощения, если эта задача очевидна, так как я разработчик программного обеспечения, а не сетевой инженер.
ОБНОВИТЬ
Я подумал, что могу упомянуть, что эта проблема возникает между клиентами и сервером CVS и клиентами, использующими VPN и сервер HTTP. Наши клиенты VPN не изменяют разрешение, и я попросил сетевых инженеров исправить это, но они не видят в этом проблемы.
Часто места ставят свои обратные рекорды. Вы можете сказать, что испортили обратные записи, потому что если вы запустите что-то вроде netstat -a и это занимает очень много времени, и вы получаете обратно кучу IP-адресов в rfc1918 адресное пространство. Отсутствие обратных записей в этом пространстве само по себе не проблема, но является проблема, если ваши DNS-люди пересылают свои DNS-запросы поставщикам или неработающему DNS-серверу.
Быстрый способ проверить, является ли это проблема DNS, - войти в систему и найти IP-адрес кого-то, кто подключен к системе (посмотрите netstat -a и найдите установленные соединения), а затем запустите
nslookup a.b.c.d (or whatever the IP of that host is)
если у вас более старая система, вам может потребоваться ввести
nslookup d.c.b.a.in-addr.arpa.
В любом случае результатом может быть что-то вроде «не могу найти этот адрес», но ответ должен быть возвращен. быстро. Тайм-ауты DNS могут составлять порядка секунд, и если у вас есть 3 DNS-сервера в вашем resolv.conf, ваш сервер будет пробовать каждый из них, прежде чем он откажется. Это может легко привести к действительно утомительному количеству времени.
Быстрый способ проиллюстрировать проблему своему боссу - запустить netstat -an а затем запустить netstat -a а затем скажите: «Если бы наш DNS работал должным образом, они оба работали бы примерно за одинаковое время.
Если это проблема с обратной записью, вы, вероятно, можете «исправить» проблему, отключив обратный поиск в своих приложениях. В этой ситуации это может быть проще, чем вовлекать другую группу.
Также существует удаленная возможность несоответствия дуплексного режима между вашими серверами и их коммутаторами. Это можно проверить, посмотрев на вывод (windows) netstat -e или (unix) netstat -i. Вы ищете «ошибки» или «коллизии». Если вы видите «коллизии», значит, ваш конец настроен неправильно; это полудуплекс и должен быть полнодуплексным. Если вы видите «ошибки», конец коммутатора полудуплексный, а вы полудуплексный. Оба счетчика должны быть нулевыми или хотя бы маленькими и не увеличиваться. Эти проблемы может быть очень сложно отследить, потому что ссылка будет работать очень хорошо, если она будет выгружена, и полностью развалится при большом трафике.
Если запрос завершается, значит, проблема не в тайм-ауте. Если бы это была проблема тайм-аута, запрос никогда бы не завершился, отсюда и название «тайм-аут». Вы имеете в виду, что некоторые запросы истекли по таймауту, а некоторые завершились по прошествии длительного периода времени, потому что это имеет больше смысла, чем то, что вы заявили в своем сообщении.
Что касается отслеживания проблемы, есть много областей, на которые стоит обратить внимание. Вот несколько советов, с которых можно начать:
Запустите tracert с клиентской машины на рассматриваемый сервер. Посчитайте, через сколько хмелей он проходит. Каждый переход - это своего рода маршрутизатор. Если tracert идет напрямую с вашего клиентского компьютера на сервер, значит на пути нет маршрутизаторов.
Выполните переход от клиентской машины к рассматриваемому серверу и посмотрите, нет ли задержки и потери пакетов между ними.
Установите на сервер анализатор пакетов и начните захват. Отправьте запрос от клиента и посмотрите вывод анализатора пакетов на сервере. Если вы видите значительную задержку между запросом и ответом в выходных данных сниффера, то это проблема сервера. Если нет значительной задержки, это проблема сети.