Ja też się nad tym zastanawiałem i motywowało mnie twoje pytanie!
Zbadałem, jak blisko mogłem podejść do każdej z wymienionych kolejek, podając informacje dotyczące każdej z nich. Czekam na komentarze / opinie, wszelkie ulepszenia w monitorowaniu ułatwiają zarządzanie!
net.core.somaxconn
net.ipv4.tcp_max_syn_backlog
net.core.netdev_max_backlog
$ netstat -an | grep -c SYN_RECV
Pokaże bieżącą globalną liczbę połączeń w kolejce, możesz podzielić to na port i umieścić to w instrukcjach exec w snmpd.conf, jeśli chcesz sondować je z aplikacji monitorującej.
Od:
netstat -s
Pokażą Ci, jak często widzisz żądania z kolejki:
146533724 packets directly received from backlog
TCPBacklogDrop: 1029
3805 packets collapsed in receive queue due to low socket buffer
fs.file-max
Od:
http://linux.die.net/man/5/proc
$ cat /proc/sys/fs/file-nr
2720 0 197774
Ten plik (tylko do odczytu) podaje liczbę aktualnie otwartych plików. Zawiera trzy liczby: liczbę przydzielonych uchwytów plików, liczbę wolnych uchwytów plików i maksymalną liczbę uchwytów plików.
net.ipv4.ip_local_port_range
Jeśli możesz zbudować listę wykluczeń usług (netstat -an | grep LISTEN), możesz wywnioskować, ile połączeń jest używanych do efemerycznych działań:
netstat -an | egrep -v "MYIP.(PORTS|IN|LISTEN)" | wc -l
Powinien także monitorować (z SNMP):
TCP-MIB::tcpCurrEstab.0
Interesujące może być również zebranie statystyk dotyczących wszystkich stanów widocznych w tym drzewie (ustanowione / time_wait / fin_wait / etc):
TCP-MIB::tcpConnState.*
net.core.rmem_max
net.core.wmem_max
Będziesz musiał śledzić / śledzić swój system dla żądań setsockopt. Nie sądzę, żeby statystyki tych żądań były śledzone inaczej. To nie jest tak naprawdę wartość, która zmienia się w moim rozumieniu. Wdrożona aplikacja prawdopodobnie poprosi o standardową kwotę. Myślę, że możesz „profilować” swoją aplikację za pomocą strace i odpowiednio skonfigurować tę wartość. (omawiać?)
net.ipv4.tcp_rmem
net.ipv4.tcp_wmem
Aby sprawdzić, jak blisko jesteś limitu, musiałbyś patrzeć na średnią i maksimum z pól tx_queue i rx_queue z (regularnie):
# 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
Aby śledzić związane z tym błędy:
# netstat -s
40 packets pruned from receive queue because of socket buffer overrun
Powinien również monitorować globalną pulę „buforów” (przez SNMP):
HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: Memory Buffers
HOST-RESOURCES-MIB::hrStorageSize.1 = INTEGER: 74172456
HOST-RESOURCES-MIB::hrStorageUsed.1 = INTEGER: 51629704