Re: Отказ в обслуживании на определенном порту.

Виктор Вислобоков corochoone at gmail.com
Mon Apr 1 11:19:18 UTC 2013


У меня такое бывает на серверах с CentOS 5.x/6.x. Помогает рестарт
iptables. Попробуйте.


1 апреля 2013 г., 13:31 пользователь psevdokot <nginx-forum at nginx.us>написал:

> по tcpdump-у видим, что syn-пакет на сервер приходит, но syn+ack в ответ не
> отправляется.
>
> Un Lexx Wrote:
> -------------------------------------------------------
> > Tcp пакет то на указанный порт приходит? вообще судя по тому что то
> > появляется то исчезает думаю где то выше у вас стоит какое то
> > фаерволл
> > который отфильтровывает по кол-ву запросов на указанный порт X
> >
> >
> >
> > 1 апреля 2013 г., 14:13 пользователь vstaf <nginx-forum at nginx.us>
> > написал:
> >
> > > Коллеги, надеюсь на помощь в решении периодически возникающей
> > проблемы.
> > >
> > > Суть:
> > >
> > > Есть 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
> > > nginx-ru at nginx.org
> > > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru at nginx.org
> > 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
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130401/6e3ce393/attachment.html>


Подробная информация о списке рассылки nginx-ru