Jump to content
Калькуляторы

Проседание пинга при нагрузке

Добрый день. У меня проблема :) Укажите, в какую сторону копать.

 

имеется vpn сервер:

 

[root@vpn11 ~]# cat /etc/redhat-release 
CentOS release 5.7 (Final)

[root@vpn11 ~]# uname -a
Linux vpn11.company.ru 2.6.18-274.12.1.el5 #1 SMP Tue Nov 29 13:37:46 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

[root@vpn11 ~]# lspci |grep Eth
03:00.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)
03:01.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller

[root@vpn11 ~]# ethtool -i eth0
driver: e1000
version: 8.0.35-NAPI
firmware-version: N/A
bus-info: 0000:03:00.0
[root@vpn11 ~]# ethtool -i eth1
driver: e1000
version: 8.0.35-NAPI
firmware-version: N/A
bus-info: 0000:03:01.0

 

Суть проблемы: при возрастании нагрузки на сетевые интерфейсы (когда количество юзеров переваливает примерно за 300-400 человек) начинает скакать пинг. Если без нагрузки пинг до шлюза как и положено <1мс, то с нагрузкой возрастает до 20-40мс.

 

Ядро стоковое из репозитория. Драйвер для сетевушек был версии 7.3.хх. Обновил до последней 8.0.35. Проблема как была так и осталась. Сетевые параметры не крутил.

 

Даже не знаю, в какую сторону смотреть.

Спасибо за любую помощь :)

 

 

Добавлю, что парк vpn-серверов состоит из 11 машин. На 2 из них наблюдается такая проблема. На остальных такой проблемы нет.

Edited by rainbo

Share this post


Link to post
Share on other sites

Даже не знаю, в какую сторону смотреть.

1) поставить ядро поновее.

2) PPTP из poptop или accel-pptp?

Share this post


Link to post
Share on other sites

pppoe не вариант.

 

ядро пересобирать руками ой как не хочется. Данный вариант оставлю на десерт. Есть репозитории с ядрами для центоса? :)

 

accel-pptp-0.8.5 стоит, но мне кажется, не в нем дело, т.к. пинг растет не только через vpn туннель, но даже если с самой тачки пинговать...

Share this post


Link to post
Share on other sites

ядро пересобирать руками ой как не хочется. Данный вариант оставлю на десерт. Есть репозитории с ядрами для центоса? :)

http://elrepo.org/tiki/kernel-ml

Найдено через Гугл по запросу "centos kernel backport".

 

Инструкция по использованию: http://centos.alt.ru/?p=471

Share this post


Link to post
Share on other sites

Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller

http://www.intel.com/design/network/products/lan/controllers/82541pi.htm

High-performance, power-optimized Gigabit connection for mobile and desktop PCI-based designs

 

64KB FIFO

Как думаете сколько пакетов карточка прожует?

Share this post


Link to post
Share on other sites

64KB FIFO

Как думаете сколько пакетов карточка прожует?

Если бы дело было в размере буфера на карте, должна была бы подпрыгнуть загрузка CPU из-за частых прерываний.

Автор темы про этот очевидный параметр ничего не написал - значит, пока считаем, что параметр в порядке.

Share this post


Link to post
Share on other sites

С нагрузкой CPU все в порядке. В данный момент ставлю 2.6.32 от Oracle (в комментах http://centos.alt.ru/?p=471#comment-2674 говорят, что встает как влитое)

Share this post


Link to post
Share on other sites

Шлюз на pci карте. 300-400 юзеров онлайн.

Да у вас карта больше 500-700 пакетов не может.

Вы бы хоть трафик и ппс показали

Share this post


Link to post
Share on other sites

Почему-то ни ядро от оракл, ни ядро из elrepo не встали. Кернел паник при загрузке.

 

По поводу не может - сомневаюсь. На других впн серверах висит по 500-800 человек и не булькает. Правда там только одна такая сетевуха. вторая встроенная. Например:

[root@vpn9 ~]# lspci |grep Eth
00:19.0 Ethernet controller: Intel Corporation 82567V-2 Gigabit Network Connection
04:02.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)

 

Кстати, натолкнуло на мысль... Оба впн которые глючат, имеют по 2 82541PI сетевухи. Остальные впн которые не глючат - имеют одну 82541PI и вторую встроенную сетевуху.

Надо будет попробовать пропустить таким же макаром...

Edited by rainbo

Share this post


Link to post
Share on other sites

если дропов и ошибок нет, может просто поднять приоритет icmp трафика?

 

у нас для транзитного трафика у каждого юзера icmp высшим приоритетом и отдельным шейпером. Пока не подняли приоритет тоже скакал.

Share this post


Link to post
Share on other sites

производительность упёрлась в общую шину PCI.

обновляйте парк, и юзайте PCI-Express.

то, что на других машинах 82567 - вас не сильно спасёт, при росте нагрузки затык очень скоро наступит и там.

82567V-2 - это сетёвка интегрирована в ICH10, и она даже хуже чем rtl8139

Share this post


Link to post
Share on other sites

загрузку процессора чем смотрите? vmstat не покажет, а вот "mpstat -P ALL 1" во время тормозных пингов должен показать 100% softirq как минимум на одном из CPU - на том, к которому "прикреплена" проблемная сетёвка.

всё потому что карточка работает с одним процессором (ядром).

вывод - надо ставить сетевые, имеющие несколько очередей, каждая из которых может обрабатываться отдельным CPU. например, на базе 82576.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.