Есть приложение на Java, которое собирает условные логи. Приложение слушает TCP порт. К нему подключаются клиенты (совсем немного, от 3 до 5) и после подключения больше не отключаются (логи же). Все клиенты находятся в одном сетевом сегменте (свич, vlan, подсеть - всё одинаковое). Сервер клиенту ничего не пишет в ответ (и не должен), он просто читает с него TCP поток, разбивает на отдельные сообщения и скидывает в очередь для обработки (0 логики и задержек при чтении сообщений).
Проблема:
Спустя какое-то непродолжительное время, примерно 10 мин. с одного (и только одного) из клиентов начинают идти потери. Предположительно, это происходит во время кратковременных всплесков нагрузки. В дампе это видно как множественные Dup ACK и «previous segment not captured». Ну то есть, TCP нам говорит забейте на проверку ошибок на стороне приложения, я ГАРАНТИРУЮ доставку и … не гарантирует.
UDP использовать нельзя, он не поддерживается клиентами. С той стороны промышленная железка для которой нагрузка, при которой на сервере происходит потеря, это 1% от её возможностей. Сервер тоже даже близко не перегружен, иначе это должно было бы сказываться на других клиентах.
Отличие проблемного клиента от не проблемных только в том, что с него payload пожирнее (там XML на ~1Kb внутри, а в других нет) и пакеты бегут почаще. Соответственно, подозрение падает на TCP стек линукса (Centos 7) и параметры сокета, в частности.
Выкручивал параметры net.core.rmem_max и net.core.wmem_max до 1MB, что достаточно много. Контролировал, что и ОС и приложение увидели эти настройки. Не помогло.
Подскажите, пожалуйста, где ещё можно покрутить и с чем ещё могут быть связаны такие потери TCP фреймов.
