мы видим следующее:
[root@primary data]# netstat -s | grep buffer ; sleep 10 ; netstat -s | grep buffer
20560 packets pruned from receive queue because of socket buffer overrun
997586 packets collapsed in receive queue due to low socket buffer
20587 packets pruned from receive queue because of socket buffer overrun
998646 packets collapsed in receive queue due to low socket buffer
[root@primary data]#
Не забывайте, что это только что перезагруженный компьютер ... Время безотказной работы около 1 часа. Недавно у нас был ящик, который продлился 2 месяца, и эти счетчики выйдут на миллионы (XXX миллионов).
Мы пробовали изменять различные переменные sysctl ...
Вот наши sysctl-переменные, которые, как мне кажется, связаны:
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
Кто-нибудь знает, как разрешить эти обрезанные пакеты из-за переполнения буфера сокета / сворачивания пакетов (что, как я понимаю, не так плохо, как обрезанные пакеты)?
Спасибо.
На самом деле вам необязательно увеличивать буферы; просто максимально возможный размер очередей.
Когда вы открываете сокет, очереди устанавливаются на значение: net.core.rmem_default = 212992 net.core.wmem_default = 212992
Так что увеличение максимума ничего не даст если только приложение вызывает setsockopt () для увеличения размера очереди (и терпит неудачу, если максимальное значение меньше размера, который оно пытается выделить).
Попробуйте увеличить значения выше.
Судя по предоставленной вами информации и поскольку вы, кажется, уже увеличили буферы, проблема, скорее всего, кроется в вашем приложении. Основная проблема здесь в том, что даже если ОС получает сетевые пакеты, они обрабатываются недостаточно быстро и, следовательно, заполняют очередь.
Это не обязательно означает, что приложение само по себе работает слишком медленно, также возможно, что ему не хватает процессорного времени из-за слишком большого количества других процессов, запущенных на этой машине.