Ладно, меня это вымораживает - я вижу около 1500-2500 этих:
root@wherever:# 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...]
root@wherever:# netstat | grep 'TIME_WAIT' |wc -l
1942
Это число стремительно меняется.
У меня есть довольно жесткие правила iptables конфиг, так что я понятия не имею, что может привести к этому. любые идеи?
Спасибо,
Тамас
Редактировать: выход 'команды netstat -АНП':
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 -
Редактировать: tcp_fin_timeout не контроль продолжительности TIME_WAIT, прежде чем, это прописано в 60-х годах
Как упомянуто другими, имея связи в TIME_WAIT, прежде чем-это нормальная часть TCP-соединение. Вы можете ознакомиться с интервала путем изучения /труды/системы/нетто/протоколов IPv4/tcp_fin_timeout
:
[root@host ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout
60
И изменить его, изменив это значение:
[root@dev admin]# echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
Или постоянно добавляя его в /etc/sysctl-переменной.конф
net.ipv4.tcp_fin_timeout=30
Также, если вы Don'т использовать службу RPC и NFS, вы можете просто выключить его:
/etc/init.d/nfsd stop
И полностью отключить его
chkconfig nfsd off
\Время _WAIT нормально. Это'ы государства после того, как сокет был закрыт, используется ядром, чтобы отслеживать пакеты, которые, возможно, заблудился и оказался на этом празднике жизни. Большое количество времени\подключения _WAIT является симптомом становится много кратковременных связей, не волноваться.
Это'т важно. Все это означает, что вы'повторного открытия и закрытия много солнца РКП TCP-соединений (1500-2500 их каждые 2-4 минуты). В `TIME_WAIT, прежде чем государства-это то, что сокет переходит в, когда он закрывается, чтобы предотвратить сообщения не поступали за неправильную приложений, как они могут, если гнездо было использовано слишком быстро, и за пару других полезных целей. Дон'т беспокоиться об этом.
(Если, конечно, вы не'т на самом деле работает все, что должно быть обработки, что многие операции РКП. Потом, переживай.)
Что-то в системе делает много RPC (удаленный вызов процедур) в системе (заметьте оба источника и назначения является localhost). Что'ы часто видел lockd для монтирование по NFS, но вы также можете увидеть другие вызовы RPC, такие как RPC.он или RPC.спрей.
Вы можете попробовать использовать "и как lsof -я", чтобы увидеть, кто имеет эти сокеты открыть и посмотреть, что'ов, делаю это. Это'ы, вероятно, безвредны.
tcp_fin_timeout
не контролирует `TIME_WAIT, прежде чем опоздания. Вы можете увидеть это с помощью сс или 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. Однако если у вас нет.протокол IPv4.tcp_tw_reuse значение 1 (Эхо 1 > /труды/системы/нетто/протоколов IPv4/tcp_tw_reuse
), то ядро может использовать сокеты в TIME_WAIT, прежде чем, если он устанавливает там выиграл'т быть любые возможные конфликты в TCP сегменте нумерации.
У меня тоже такая же проблема. Я стоило мне несколько часов, чтобы выяснить, что происходит. В моем случае, поводом для этого стало то, что команды netstat пытается найти имя, соответствующее IP (я предполагаю, что это's используя функцию gethostbyaddr АНП). Я был с помощью встроенного установка Linux, который не имел в /etc/файл nsswitch.конф. К моему удивлению, проблема существует только когда вы на самом деле делаете команду netstat-а (выяснил это путем запуска и portmap в вербальном и режим отладки).
Сейчас произошло следующее: По умолчанию функции поиска также попробовать связаться демон ypbind (Желтые страницы Солнца, также известный как "НИС") на запрос имени хоста. Для запроса данной услуги, сопоставления и portmap должен быть контакт, чтобы получить порт на эту услугу. Теперь portmapper работает в моем случае, получил извещение через TCP. Затем сопоставления дает функции библиотеки libc, что не существует такой службы и TCP-соединение закрывается. Как известно, закрыт TCP-подключений войти в состояние TIME_WAIT, прежде чем какое-то время. Так что команды netstat ловит этой связи при перечислении и новый состав с новым IP выдает новый запрос, который создает новое подключение в состоянии TIME_WAIT и так далее...
Для того, чтобы решить эту проблему, создайте файл /etc/файл nsswitch.conf, который не использует службы RPC НИС, т. е. со следующим содержанием:
passwd: files
group: files
hosts: files dns
networks: files dns
services: files
protocols: files
netmasks: files