LINUX.ORG.RU

Низкая производительность сетевого интерфейса


2

3

Всем привет, столкнулись на серверах с проблемой, - 1гбит/с сетевой интерфейс справляется только на половину, или чуть больше.

Суть в том, что на серверах имеются 2 интерфейса: WAN, LAN. На WAN стоит HTB шейпер, по сути сервер гонит через себя транзитный трафик, который берет с LAN и отдает в WAN. При этом сервер еще принимает файлы от пользователей и выгружает их в локальную сеть. Проблема в том, что когда достигли 650Мбит/с скорости транзитного трафика, сервер стал очень медленно выгружать файлы в локальную сеть (примерно 200Мбит). Если же подрезать шейпером скорость транзита до 600, то выгрузка начинает происходить на полной мощности (вплоть до гигабита). Количество коннектов к WAN интерфейсу - порядка 3000.

В чем может быть затык?



Последнее исправление: Hett (всего исправлений: 1)

Ответ на: комментарий от Revent

Да смотрел, ничего там особо отличающегося от того что сейчас (в период минимальной нагрузки) нету. proftpd только время от времени показывает высокий IO.

Hett
() автор топика
Ответ на: комментарий от Hett

io - ввод-вывод дисковой подсистемы:

atopsar -d - покажет нагрузки на диски за последние сутки

dmesg | grep sda - поиск сообщений о проблемах с диском

hdparm -tT /dev/sda - тестирование производительности винчестера

iostat - пакет (sysstat) показывает нагрузку на дисковую подсистему

iotop -oPa - показывает процессы активно использующие дисковую подсистему

vmstat - информация о процессах, виртуальной памяти, дисках и процессорной активности

atop 1 | grep ^DSK - мониторинг в режиме реального времени нагрузки на диски

top - параметр wa (iowait) процессорное время, затраченное на завершение ввода-вывода, косвенный показатель, при достижении больших значений (>80%) указывает на возможные проблемы с дисковой подсистемой

vxzvxz ★★★
()
Ответ на: комментарий от vxzvxz

С диском точно все в норме. Транзитный трафик диск не затрагивает, а для выгрузки хватает вполне, там SSD диски. Если убрать весь транзитный трафик, то загрузка-выгрузка проходит на полной скорости, а если добавить транзит, то выгрузка сразу сильно падает по скорости (хотя это трафик совсем в другом направлении на данном интерфейсе)

Hett
() автор топика
Ответ на: комментарий от Hett

Может просто сетевые буфферы заканчиваются ?

Учитывая специфику TCP, он получает данные транзитные, отправляет и ждет ACK т.е. пока ждет данные занимают сетевой буффер, размеры этих буфферов по умолчанию не такие уж и большие и чем выше задержка тем большие буфферы нужны.

netstat показывает Recv-Q Send-Q если в момент деградации много соединений висят с цифрами в Send-Q то вероятно нужно увеличить количество памяти выделяемой для сетевых буфферов.

hidden_4003
()

Хочу уточнить как именно проводились измерения? А то

650 + 200 = 850 Мбит/с  — это понятно, а

Если же подрезать шейпером скорость транзита до 600, то выгрузка начинает происходить на полной мощности (вплоть до гигабита).

не понятно, если от гигабита взять 600 Мбит, то как выгрузка будет происходить «вплоть до гигабита»?

И, используются ли jumbo-фреймы? А то, может в вас выгрузка файлов идёт jumbo-фреймами, а интернет маленькими пакетами. И вобще, хорошо бы оценить pps (пакеты в секунду), а не МегаБиты.

mky ★★★★★
()
Ответ на: комментарий от Hett

хотя это трафик совсем в другом направлении на данном интерфейсе

А вы там случаем не зашейпили вместе с транзитным трафиком ACK-пакеты от выгрузки файлов?

mky ★★★★★
()
Ответ на: комментарий от mky

мы шейпили WAN интерфейс, он на выгрузку никак не влияет, она идет через LAN.

Hett
() автор топика
Ответ на: комментарий от mky

Попробую на примерах: Если пользователи качают с WAN на скорости 650 мегабит, то машина берет в свою очередь трафик с LAN интерфейса, и на LAN это получается входящий трафик в таком же объеме (этот трафик я назвал транзитным выше). При этом этот же сервер вливает файлы в LAN интерфейс (исходящий трафик), но скорость уже не поднимается выше 200 мегабит. Если же ограничить шейпером скорость на WAN до 600, например, то исходящая скорость на LAN значительно увеличивается (почти до потолка)

Hett
() автор топика
Ответ на: комментарий от hidden_4003

надо посмотреть, что-то про TCP буферы сразу не подумали.

Hett
() автор топика
Ответ на: комментарий от mky

джамб-фреймы не используются, думали про них, но пока дело не дошло

Hett
() автор топика
16 августа 2013 г.

В общем тюнинг TCP ничего не дал, IRQ тоже в ручную раскидали, эффекта особо нету. Что можно еще поковырять?

Hett
() автор топика
Ответ на: комментарий от Hett

atop не показывает высокой нагрузки где-либо.

Hett
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.