Может, кто-нибудь сможет мне в этом помочь. Я пытаюсь выяснить, есть ли что-нибудь, что можно оптимизировать на стороне сервера, чтобы уменьшить задержки в случае потери пакетов.
Среда: клиент Windows 2012, сервер CentOS 6.x [Couchbase], тот же центр обработки данных, загруженная локальная сеть с межсетевыми экранами для прохождения. Оба являются большими физическими серверами с большим количеством резервных мощностей.
Проблема: по данным клиента, время отклика хорошо распределяется примерно на 1 мс, но мы видим всплеск на уровне примерно 200 мс.
Трассировка сети показывает это:
Есть идеи, откуда берется эта задержка в 200 мс и как ее уменьшить? Я бы предположил, что какая-то комбинация tcp delayed acks, nagle и алгоритмов перегрузки / RTO, но настройка ядра Linux для меня немного загадка.
Любое предложение?
да, wirehark с обеих сторон, tcpdump, сетевые трассировки, снятые на уровне коммутатора (довольно дорогие коммутаторы Arista 10G), трассировки, снятые на межсетевом экране (Fortinet) и т. д.
Проблема не в том, почему клиент не получает ответа. Это загруженная сеть с интенсивным трафиком, поэтому потеря одного пакета из 10 000 не является неожиданным. Но мне нужно предоставить SLA, даже если я теряю пакет, а задержка в 200 мс сбрасывает его.
Я имею в виду, что экспериментируя с DEV, я могу «исправить» проблему, установив TCP RTO для клиентской подсети на 5 мс с помощью команды маршрута [на стороне сервера]. При этом 99,999% моих запросов получают ответ менее чем за 10 мс, и я выполняю свое SLA. Хорошо, но каковы недостатки этого в продакшене? Является ли RTO реальной проблемой, или я исправляю ее случайно? Это лучшее возможное решение проблемы, или есть что-то более умное / лучшее (настроенный профиль? Параметр sysctl? Молитва богам minix?)?
ри-спасибо