Высокие случаи сообщений нулевого окна
На моих веб-серверах я наблюдаю высокую скорость (106 на ~13 секунд или 300 000 пакетов) сообщений обновления нулевого окна, отправленных с моих веб-серверов на серверы баз данных во время пикового трафика.
Прошивка обновлена:
Я обновил прошивку и драйвер до последних версий, которые Dell предлагает для карт BCM5709C.
Разгрузка TCP включена:
Если исходить из того, что в интерфейсе Broadcom Advanced Control Suite (BACs) включена активная "Всего разгрузочных TCP-соединений", то разгрузка TCP включена. Я также не вижу привязки процессора на серверах.
Масштабирование окна включено:
Масштабирование окна включено, но не используется много. Я вижу 20 пакетов с масштабированием окна из 300 000 пакетов.
Статистика:
Среднее время прохождения туда и обратно составляет ~2 мс с макс. ~3 мс. Загрузка ЦП на веб-серверах не достигает пика вообще.
Вопросы:
- Я не верю, что буферы должны так сильно заполнять веб-серверы.
- Есть ли другие показатели помимо CPU, на которые я должен обратить внимание, чтобы понять, почему буферы заполняются?
- Учитывая, что все обновлено, я должен смотреть на настройку параметров TCP на моих веб-серверах Windows 2008 Server R2? Какие корректировки я должен сделать, если это так?
2 ответа
Вопрос уже несколько состарился. Я не уверен, что это все еще не решено, но все же попробую совет по устранению неполадок.
Прежде всего, важно проверить, где происходят объявления с нулевым окном. В определенные моменты при обмене протоколами для них может быть вполне допустимым, если веб-сервер просто не ожидает, что какие-либо данные вернутся в качестве ответа в данный момент, и, возможно, установил для буфера приема значение 0 для данного сокета. или заполнен приемный буфер, просто какое-то время не получая оттуда ничего. Отладка этого потребует знания используемого протокола (еще лучше реализации).
Вам не нужно настраивать какое-либо значение параметров TCP для какой-либо общей настройки локальной сети, TCP в основном самонастраивается, за исключением крайних случаев, таких как сети с переменными задержками или непредсказуемой потерей пакетов.
Я никогда не сталкивался с этим, но у меня есть догадка, проблема в прикладном уровне. Я бы начал с рассмотрения счетчиков perfmon, связанных с веб-процессами. "Ресурсный комплект служб IIS 7.0" и "Карманный консультант администратора служб IIS 7.0" содержат информацию о мониторинге и настройке производительности, к сожалению, ни один из них не является бесплатным.
http://www.microsoft.com/learning/en/us/book.aspx?ID=9550&locale=en-us
http://www.microsoft.com/learning/en/us/book.aspx?ID=10442&locale=en-us
РЕДАКТИРОВАТЬ:
Один из возможных способов отследить это (по общему признанию, очень грубый) состоит в том, чтобы временно остановить веб-службы на сервере и загрузить большой файл или большое количество маленьких файлов на веб-сервер и проверить, есть ли у вас такое же условие нулевого окна. Если вы это сделаете, то, вероятно, можете исключить любые проблемы с ресурсами, связанные с веб-службами, как причину. Если вы этого не сделаете, вы можете сосредоточить все свои усилия на анализе использования ресурсов веб-служб, чтобы найти причину.