У меня такое бывает на серверах с CentOS 5.x/6.x. Помогает рестарт iptables. Попробуйте.
1 апреля 2013 г., 13:31 пользователь psevdokot <[email protected]>написал: > по tcpdump-у видим, что syn-пакет на сервер приходит, но syn+ack в ответ не > отправляется. > > Un Lexx Wrote: > ------------------------------------------------------- > > Tcp пакет то на указанный порт приходит? вообще судя по тому что то > > появляется то исчезает думаю где то выше у вас стоит какое то > > фаерволл > > который отфильтровывает по кол-ву запросов на указанный порт X > > > > > > > > 1 апреля 2013 г., 14:13 пользователь vstaf <[email protected]> > > написал: > > > > > Коллеги, надеюсь на помощь в решении периодически возникающей > > проблемы. > > > > > > Суть: > > > > > > Есть nginx, обслуживающий 1 домен на 5 портах + SSL. Периодически > > (раз в > > > несколько недель) возникает ситуация, что при попытке коннекта на > > > определенный порт (назовем его "Х") не проходят даже syn - ack. > > Обычно это > > > возникает при цифре 6к syn-запросов в секунду к серверу на > > пресловутый порт > > > "Х". На других портах nginx работает нормально и без проблем > > выполняет все > > > свои функции. > > > > > > О сервере: 2хXeon E5620, HT on, 12 gb ram. Centos 5 > > (2.6.18-238.19.1.el5PAE > > > i386) > > > Пиковая статистика из stub_status: rps ~1k, active connections ~8k > > > > > > sysctl.conf: > > > > > > net.ipv4.tcp_syncookies = 0 > > > net.ipv4.netfilter.ip_conntrack_max = 10000000 > > > > > > net.ipv4.tcp_fin_timeout = 1 > > > net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 1 > > > net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 1 > > > net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 1 > > > net.ipv4.netfilter.ip_conntrack_tcp_timeout_close=1 > > > net.ipv4.ip_local_port_range = 5000 65000 > > > > > > net.ipv4.tcp_max_syn_backlog = 3240000 > > > net.core.somaxconn = 3240000 > > > net.ipv4.tcp_max_tw_buckets = 1440000 > > > net.core.netdev_max_backlog=10000 > > > > > > net.core.rmem_default = 8388608 > > > net.core.rmem_max = 16777216 > > > net.core.wmem_max = 16777216 > > > net.ipv4.tcp_mem = 1048576 2097152 3145728 > > > net.ipv4.tcp_rmem = 4096 65536 16777216 > > > net.ipv4.tcp_wmem = 4096 65536 16777216 > > > > > > nginx:conf: > > > > > > worker_processes 16; > > > > > > events { > > > worker_connections 16384; > > > use epoll; > > > multi_accept on; > > > } > > > > > > http { > > > > > > tcp_nopush on; > > > tcp_nodelay on; > > > sendfile on; > > > keepalive_timeout 10; > > > keepalive_requests 100000; > > > reset_timedout_connection on; > > > send_timeout 2; > > > client_header_timeout 10; > > > client_body_timeout 10; > > > proxy_buffering off; > > > > > > fastcgi_buffers 4 256k; > > > fastcgi_buffer_size 256k; > > > > > > client_max_body_size 10m; > > > > > > > > > Понимаю, что по сути сам nginx тут не при чем, но хотелось бы > > понять > > > направление куда копать. Экспериментировал с разными параметрами > > ядра - > > > профита так и не получил. Когда количество синов в секунду падает > > (до > > > 1-1.5к) - все приходит в норму. > > > > > > Заранее спасибо. > > > > > > Posted at Nginx Forum: > > > http://forum.nginx.org/read.php?21,237998,237998#msg-237998 > > > > > > _______________________________________________ > > > nginx-ru mailing list > > > [email protected] > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > > nginx-ru mailing list > > [email protected] > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,237998,238000#msg-238000 > > _______________________________________________ > nginx-ru mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx-ru >
_______________________________________________ nginx-ru mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
