как проверить размер rx ring, max_backlog и max_syn_backlog

Довольно часто в ходе устранения неполадок и настройки я думаю о следующих настройках ядра Linux:

net.core.netdev_max_backlog
net.ipv4.tcp_max_syn_backlog
net.core.somaxconn

Кроме fs.file-max, net.ipv4.ip_local_port_range, net.core.rmem_max, net.core.wmem_max, net.ipv4.tcp_rmem, иnet.ipv4.tcp_wmem они , кажется, важные ручки замарать , когда вы настраиваете ящик для высоких уровней параллелизма.

Мой вопрос: как я могу проверить, сколько элементов в каждой из этих очередей? Обычно люди просто устанавливают их слишком высоко, но я хотел бы зарегистрировать эти размеры очереди, чтобы помочь предсказать будущие сбои и выявить проблемы, прежде чем они проявятся для пользователя заметным образом.

Я тоже задумался над этим и был мотивирован вашим вопросом!

Я понял, насколько близко я могу подойти к каждой из перечисленных вами очередей, с некоторой информацией, связанной с каждой из них. Я приветствую комментарии / отзывы, любое улучшение мониторинга облегчает управление!

net.core.somaxconn

net.ipv4.tcp_max_syn_backlog

net.core.netdev_max_backlog

$ netstat -an | grep -c SYN_RECV 

Будет показано текущее глобальное количество соединений в очереди, вы можете разбить его на порты и поместить это в инструкции exec в snmpd.conf, если вы хотите опросить его из приложения мониторинга.

От:

netstat -s

Они покажут вам, как часто вы видите запросы из очереди:

146533724 packets directly received from backlog
TCPBacklogDrop: 1029
3805 packets collapsed in receive queue due to low socket buffer

fs.file-макс

От:

http://linux.die.net/man/5/proc

$ cat /proc/sys/fs/file-nr
2720    0       197774

Этот (только для чтения) файл показывает количество открытых файлов. Он содержит три числа: количество выделенных файловых дескрипторов, количество свободных файловых дескрипторов и максимальное количество файловых дескрипторов.

net.ipv4.ip_local_port_range

Если вы можете создать список исключений служб (netstat -an | grep LISTEN), то вы можете определить, сколько соединений используется для эфемерной активности:

netstat -an | egrep -v "MYIP.(PORTS|IN|LISTEN)"  | wc -l

Также следует следить (из SNMP):

TCP-MIB::tcpCurrEstab.0

Также может быть интересно собрать статистику обо всех состояниях, видимых в этом дереве (установленный / time_wait / fin_wait / etc):

TCP-MIB::tcpConnState.*

net.core.rmem_max

net.core.wmem_max

Вы должны были бы отследить / связать свою систему для запросов setsockopt. Я не думаю, что статистика по этим запросам отслеживается иначе. Это не то значение, которое меняется от моего понимания. Развернутое приложение, вероятно, запросит стандартную сумму. Я думаю, что вы могли бы «профилировать» свое приложение с помощью strace и соответствующим образом настроить это значение. (Обсудить?)

net.ipv4.tcp_rmem

net.ipv4.tcp_wmem

Чтобы отследить, насколько близко вы находитесь к пределу, вы должны смотреть на среднее и максимальное значения из полей tx_queue и rx_queue (регулярно):

# cat /proc/net/tcp
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode                                                     
   0: 00000000:0FB1 00000000:0000 0A 00000000:00000000 00:00000000 00000000   500        0 262030037 1 ffff810759630d80 3000 0 0 2 -1                
   1: 00000000:A133 00000000:0000 0A 00000000:00000000 00:00000000 00000000   500        0 262029925 1 ffff81076d1958c0 3000 0 0 2 -1                

Чтобы отслеживать ошибки, связанные с этим:

# netstat -s
    40 packets pruned from receive queue because of socket buffer overrun

Также следует отслеживать глобальный буферный пул (через SNMP):

HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: Memory Buffers
HOST-RESOURCES-MIB::hrStorageSize.1 = INTEGER: 74172456
HOST-RESOURCES-MIB::hrStorageUsed.1 = INTEGER: 51629704

Я думаю, что вы можете получить эти данные с помощью SystemTap. Вот справочное руководство Redhat ^(pdf) . Существует также руководство для начинающих ^(PDF) .

Инструмент выглядит достаточно универсальным, чтобы позволить вам получать эти данные, в частности probe::netdev.rxвыглядит как то, что даст вам информацию о входящих записях, теперь вам «нужно только» найти либо чистый размер очереди в буфере, либо что-то, что подсчитывает вещи выходя из очереди…