it-swarm-ru.tech

Огромное количество соединений TIME_WAIT говорит netstat

Ладно, это меня пугает - я вижу около 1500-2500 из них:

[email protected]:# netstat

Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 localhost:60930         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60934         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60941         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60947         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60962         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60969         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60998         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60802         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60823         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60876         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60886         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60898         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60897         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60905         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60918         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60921         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60673         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60680         localhost:sunrpc        TIME_WAIT  
[etc...]

[email protected]:# netstat | grep 'TIME_WAIT' |wc -l
1942

Это число быстро меняется.

У меня довольно плотный конфиг iptables, поэтому я понятия не имею, что может вызвать это. Любые идеи?

Спасибо,

Тамас

Правка: вывод 'netstat -anp':

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:60968         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60972         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60976         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60981         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60980         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60983         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60999         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60809         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60834         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60872         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60896         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60919         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60710         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60745         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60765         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60772         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60558         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60564         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60600         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60624         127.0.0.1:111           TIME_WAIT   -               
28
KTamas

EDIT: tcp_fin_timeout НЕ ДЕЛАЕТ контролировать длительность TIME_WAIT, она жестко закодирована в 60 с

Как уже упоминалось, наличие некоторых соединений в TIME_WAIT является нормальной частью соединения TCP. Вы можете увидеть интервал, просмотрев /proc/sys/net/ipv4/tcp_fin_timeout:

[[email protected] ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout
60

И измените его, изменив это значение:

[[email protected] admin]# echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

Или навсегда, добавив его в /etc/sysctl.conf

net.ipv4.tcp_fin_timeout=30

Кроме того, если вы не используете службу RPC или NFS, вы можете просто отключить ее:

/etc/init.d/nfsd stop

И выключи его полностью

chkconfig nfsd off
22
Brandon

TIME_WAIT это нормально. Это состояние после закрытия сокета, которое используется ядром для отслеживания пакетов, которые могут быть потеряны и опозданы на вечеринку. Большое количество соединений TIME_WAIT является признаком получения большого количества коротких соединений, и не о чем беспокоиться.

16
David Pashley

Это не важно Все, что означает, это то, что вы открываете и закрываете большое количество Sun RCP TCP соединений (1500-2500 из них каждые 2-4 минуты). TIME_WAIT состояние - это то, во что входит сокет при закрытии, чтобы предотвратить поступление сообщений для неправильных приложений, как если бы сокет использовался слишком быстро, и для нескольких других полезных целей. Не беспокойся об этом.

(Если, конечно, вы на самом деле не выполняете ничего, что должно обрабатывать столько операций RCP. Тогда беспокойтесь.)

5
chaos

Что-то в вашей системе выполняет много RPC (удаленных вызовов процедур) в вашей системе (обратите внимание, что источником и получателем является localhost). Это часто наблюдается для lockd для монтирования NFS, но вы также можете увидеть это и для других вызовов RPC, таких как rpc.statd или rpc.spray.

Вы можете попробовать использовать "lsof -i", чтобы увидеть, у кого открыты эти сокеты, и посмотреть, что это делает. Это, вероятно, безвредно.

4
Paul Tomblin

tcp_fin_timeout НЕ контролирует TIME_WAIT задержка. Вы можете увидеть это, используя ss или netstat с -o, чтобы увидеть таймеры обратного отсчета:

cat /proc/sys/net/ipv4/tcp_fin_timeout
3

# See countdown timer for all TIME_WAIT sockets in 192.168.0.0-255
ss --numeric -o state time-wait dst 192.168.0.0/24

NetidRecv-Q  Send-Q    Local Address:Port    Peer Address:Port                             
tcp  0       0         192.168.100.1:57516   192.168.0.10:80    timer:(timewait,55sec,0)   
tcp  0       0         192.168.100.1:57356   192.168.0.10:80    timer:(timewait,25sec,0)   
tcp  0       0         192.168.100.1:57334   192.168.0.10:80    timer:(timewait,22sec,0)   
tcp  0       0         192.168.100.1:57282   192.168.0.10:80    timer:(timewait,12sec,0)   
tcp  0       0         192.168.100.1:57418   192.168.0.10:80    timer:(timewait,38sec,0)   
tcp  0       0         192.168.100.1:57458   192.168.0.10:80    timer:(timewait,46sec,0)   
tcp  0       0         192.168.100.1:57252   192.168.0.10:80    timer:(timewait,7.436ms,0) 
tcp  0       0         192.168.100.1:57244   192.168.0.10:80    timer:(timewait,6.536ms,0)

даже если для tcp_fin_timeout установлено значение 3, обратный отсчет для TIME_WAIT все еще начинается с 60. Однако, если для net.ipv4.tcp_tw_reuse установлено значение 1 (echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse) тогда ядро ​​может повторно использовать сокеты в TIME_WAIT, если определит, что при TCP нумерации сегментов) не будет никаких возможных конфликтов.

2
Greg Bray

У меня тоже была такая же проблема. Мне потребовалось несколько часов, чтобы выяснить, что происходит. В моем случае причиной этого было то, что netstat пытается найти имя хоста, соответствующее IP-адресу (я предполагаю, что он использует API gethostbyaddr). Я использовал встроенную установку Linux, которая не имела /etc/nsswitch.conf. К моему удивлению, проблема существует, только когда вы фактически выполняете команду netstat -a (выясните это, запустив portmap в подробном режиме и режиме отладки).

Теперь произошло следующее: По умолчанию функции поиска также пытаются связаться с демоном ypbind (Sun Yellow Pages, также известным как NIS), чтобы запросить имя хоста. Чтобы запросить этот сервис, необходимо связаться с portmapper portmap, чтобы получить порт для этого сервиса. Теперь в моем случае с portmapper связались через TCP. Затем portmapper сообщает функции libc, что такой службы не существует, и соединение TCP закрывается. Как мы знаем, закрытые TCP соединения переходят в состояние TIME_WAIT для некоторых время. Таким образом, netstat перехватывает это соединение при перечислении, и эта новая строка с новым IP-адресом выдает новый запрос, который генерирует новое соединение в состоянии TIME_WAIT и так далее ...

Чтобы решить эту проблему, создайте файл /etc/nsswitch.conf, который не использует службы NIS rpc, т.е. со следующим содержимым:

passwd:         files
group:          files
hosts:          files dns
networks:       files dns
services:       files
protocols:      files
netmasks:       files
1
leecher