Я вижу аналогичную проблему в Ubuntu 18.04 LTS (с ядром 4.15.0 -38 ). Но этого не происходит на моей машине Debian 9.5 (ядро 4.9.110 -3 ). Кажется, это ошибка в новых ядрах?
Простой способ воспроизвести проблему — использовать netcat. клиент и сервер могут быть локальными или на разных ящиках.
В Ubuntu принимающий сокет udp будет иметь не -пустой recv -q (768 байт для 2-байтового сообщения ), даже если netcat прочитал сообщение из сокета и распечатал его. У меня recv -q продолжает расти примерно до 52 КБ, а затем сбрасывается до нуля.
В Debian значение recv -q всегда равно нулю, если сокет udp опустошается быстрее, чем принимаются пакеты.
Также обнаружен этот отчет об ошибке ядра:UDP rx _неверный расчет очереди в /proc/net/udp
Извините, что я новичок в этой части StackExchange, поэтому я публикую ответ вместо комментария.
У меня возникла та же проблема, что и у @Neopallium, наUbuntu 18.04 LTS
(ядре4.15.0-36
). Из моего тестирования, искусственно установив net.core.rmem_max=26214400
и net.core.rmem_default=26214400
(, то есть 25MB
соответственно ), и запустив мое серверное приложение UDP без невыполненных дейтаграмм UDP на протяжении всего теста, я вижу, что счетчик rx_queue
поднимается примерно до 00000000:006xxxxx
или ~6MB+
и вдруг счетчик сбрасывается на 0
. Это примерно в 1/4
из net.core.rmem_max
до сброса счетчика. В Ubuntu 18.04 LTS
значениями по умолчанию для net.core.rmem_default
и net.core.rmem_max
являются 212992
, и поэтому неудивительно, что @Neopallium видит, что его счетчик поднимается примерно до52k
(примерно 1/4
из 212k
, прежде чем он сбрасывается.
Вот вывод приложения в /proc/net/udp
, приближающегося к точке сброса:
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops
1256: 00000000:7530 00000000:0000 07 00000000:00632240 00:00000000 00000000 0 0 94457826 2 0000000000000000 0
Вот скрин моего графика сокетов grafana за последние 45 минут: