Мы сталкиваемся с какой-то странной потерей пакетов и хотим узнать причину этого.
У нас есть сервер изображений и сервер для нагрузки сервера изображений. Оба расположены в одном центре обработки данных.
Сначала мы запускаем такой нагрузочный тест (команда сокращена для удобства чтения):
ab -n 50 -c 5 http://testserver/img/de.png
В образе всего около 300 байт. Результаты - очень быстрые ответы:
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 0
Processing: 1 3 0.7 3 4
Waiting: 1 3 0.7 3 3
Total: 1 3 0.7 3 4
Когда мы увеличиваем параллелизм, мы видим некоторые лаги (команда сокращена для удобства чтения):
sudo ab -n 500 -c 50 http://testserver/img/de.png
Результатов с параллелизмом 50:
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.2 0 1
Processing: 2 35 101.6 12 614
Waiting: 2 35 101.6 12 614
Total: 3 36 101.7 12 615
Итак, мы видим, что большинство запросов выполняются довольно быстро, а некоторые из них довольно медленно.
Мы сбросили весь сетевой трафик с помощью tcpdump и увидели несколько странных повторных передач.
альтернативный текст http://vygen.de/screenshot1.png
этот дамп взят на имидж-сервер!
Итак, вы видите, что исходный пакет (№ 306), содержащий запрос GET, поступает на сервер изображений, но кажется, что пакет теряется после того, как tcpdump зарегистрировал его. Мне кажется, что этот пакет не доходит до сервера изображений tomcat.
повторная передача запускается запрашивающим сервером через 200 мс, и после этого все работает нормально.
Знаете ли вы причину, по которой посылка может потеряться после получения?
Наши машины:
Так что проблем с памятью или загрузкой процессора у нас нет.
Некоторое время назад у нас были проблемы с нашим контроллером nic. Мы справились с этим с помощью другого драйвера, теперь мы используем r8168 вместо r8169
Но у нас были те же проблемы с потерянными пакетами с контроллером Intel NIC - Ethernet: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)
Таким образом, мы видим ту же проблему с одинаковыми машинами, но с разными картами Ethernet.
До сих пор я думал, что потеря пакетов будет происходить только между серверами на линии, когда пакет будет поврежден или что-то в этом роде.
Мы действительно хотим знать, какие причины могут быть для этих потерь пакетов после того, как tcpdump их зарегистрировал.
Ваша помощь очень ценится.
мы нашли первопричину этого. У нас было acceptCount 25 в нашем tomcat server.xml.
acceptCount задокументирован следующим образом:
acceptCount
Максимальная длина очереди для входящих запросов на соединение, когда используются все возможные потоки обработки запросов. Любые запросы, полученные при заполнении очереди, будут отклонены. Значение по умолчанию - 100.
Но это еще не все, что касается acceptCount. Кратко: acceptCount - это параметр невыполненной работы при открытии сокета. Таким образом, это значение важно для журнала ожидания прослушивания, даже если не все потоки заняты. Это важно, если запросы поступают быстрее, тогда tomcat может принять и делегировать их ожидающим потокам. По умолчанию acceptCount равен 100. Это все еще небольшое значение для резкого увеличения количества запросов.
Мы проверили то же самое с apache и nginx и получили такую же странную потерю пакетов, но с более высокими значениями параллелизма. Соответствующее значение в apache - ListenBacklog, по умолчанию - 511.
НО, с debian (и другими ОС на базе Linux) максимальное значение по умолчанию для параметра backlog равно 128.
$ sysctl -a | grep somaxc
net.core.somaxconn = 128
Итак, что бы вы ни вводили в acceptCount или ListenBacklog, оно не будет больше 128, пока вы не измените net.core.somaxconn
Для очень загруженного веб-сервера 128 недостаточно. Вы должны изменить его на что-то вроде 500, 1000 или 3000, в зависимости от ваших потребностей.
После установки acceptCount на 1000 и net.core.somaxconn на 1000 у нас больше не было этих отброшенных пакетов. (Теперь у нас есть узкое место где-то еще, но это уже другая история ..)
200 мс - время ожидания повторной передачи TCP по умолчанию (RTO; описано в RFC2988, хотя и не с этим минимальным значением).
Итак ... что-то задерживается или теряется, так что RTO попадает под удар. Возможно, пакет был задержан таким образом, что RTO сработал, но wirehark сгладил это во время анализа / рендеринга пакета? Вам следует исследовать след более подробно.
Можете ли вы предоставить увеличенное изображение захвата вашего пакета?