Justas Опубликовано 12 декабря, 2012 · Жалоба И да, еще. Не знаю, насколько это важно, но. Вот приближенный график загрузки ядер процессора. Видно, что с 08:15 до 08:20 CPU2 уходит в ноль. То есть не загружено вовсе, хотя это невозможно, потому как на него привязкой к ядру назначено прерывание одного из векторов сетевой карты: /bin/echo 4 > /proc/irq/`cat /proc/interrupts | grep 'eth2-TxRx-2' ................... Заметил только сейчас. Не знаю что и думать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Justas Опубликовано 12 декабря, 2012 · Жалоба Еще мысли. Дельта = 299966086829 нс 299966086829/1000/1000/1000 = 299.96 сек = 5 минут. Коррелирует с графиком падения нагрузки CPU2 в ноль. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shafiev Опубликовано 24 января, 2013 · Жалоба Поднял отдельно тему(чтобы сторонним было легче искать) подбора железки которая в принципе подходит и под софт-раутер. Вообще если кому http://forum.nag.ru/...showtopic=82136 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Justas Опубликовано 24 января, 2013 · Жалоба Коллеги, поставил машину самосбор под софтроутер на серверной маме Supermicro (чипсет Intel C202) + 4-ядерный процессор Intel i5 (без гипертрединга). ... С чем может быть связано такое поведение оперсистемы? Стоит ли отказаться от ACPI для решения вопроса? Может, какие-то опции ядра поправить? Что еще можно предпринять? TSC нужен как воздух. Проблема разрешилась путем отключения ACPI. До этого я еще успел заменить процессор на двухядерный i3 и 4-ядерный Xeon E3. На i3 проблема не проявляла себя, то есть процессор и оперсистема работали штатно. При установке Xeon E3 проблема снова вылезла - оперсистема уходила на hpet. Отключение ACPI разрешило вопрос. Не очень красивое решение, но пока так, на основные функции не влияет, а со временем докопаюсь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Victor Safronov Опубликовано 10 марта, 2013 · Жалоба Прочитал все 29 страниц, и понял, что лучше бы этого не делал. Потому что теперь от разных и порой противоречащих рецептов у меня в голове настоящая каша :) Хорошо бы какие-нибудь базовые вещи вынести в первое сообщение. Своего рода FAQ и чеклист. Ну да ладно. У меня имеется сервер с центосом 6.3, Помимо встроенных сетевых на 82567LM-2 и 82574L есть отдельная двухпортовая Intel ET (82576). В сервере установлены два четырёхядерных Xeon E5606. Имеется два аплинка с fullview примерно по 300 мегабит каждый. Суммарная нагрузка в пике до 550 мегабит/с в каждую сторону (примерно по 80-90 kpps входящего и столько же исходящего). Аплинки вланами заведены в одну голову, три влана потребителей (один для всех и два отдельных для крупных клиентов) на другой голове. Встроенные сетевые не используются. Помимо роутинга есть htb-шейпинг с хэшами, плюс блокировка через ipset. Сейчас после ребута я никак вручную не прибивал прерывания к ядрам, и топ выглядит так: top - 22:58:35 up 2:37, 2 users, load average: 0.08, 0.20, 0.24 Tasks: 219 total, 1 running, 218 sleeping, 0 stopped, 0 zombie Cpu0 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 0.0%us, 1.0%sy, 0.0%ni, 27.6%id, 0.0%wa, 0.0%hi, 71.4%si, 0.0%st Cpu2 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 0.0%us, 0.3%sy, 0.0%ni, 21.5%id, 0.0%wa, 0.0%hi, 78.2%si, 0.0%st Cpu4 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 : 0.0%us, 0.0%sy, 0.0%ni, 23.2%id, 0.0%wa, 0.0%hi, 76.8%si, 0.0%st Cpu6 : 0.0%us, 0.3%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu7 : 0.0%us, 0.0%sy, 0.0%ni, 26.5%id, 0.0%wa, 0.0%hi, 73.5%si, 0.0%st Драйвер igb стандартный из поставки центоса (3.2.10-k), никаких доп. параметров при загрузке не устанавливается. Очереди связанные tx-rx, по восемь штук на каждой сетевой. Нужно ли сейчас что-то оптимизировать? В теме я часто видел, что эти две головы объединяют в бонд. Зачем? На какие параметры ethtool обратить внимание? Есть ли какие-то рекомендованные параметры для драйвера под мои цифры? Помогите :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 10 марта, 2013 · Жалоба Сейчас после ребута я никак вручную не прибивал прерывания к ядрам, и топ выглядит так Топ выглядит паршиво. Прибейте и будет сразу лучше. По крайней мере 50% успеха. ethtool -k tso off gro off gso off Драйвер обновить и загружать с параметрами RSS (по числу ядер) и Interrupt в районе 10-20к + очереди не делить на tx-rx. ifconfig tx можно поднять до 10000 Про sysctl не буду, а то там еще очень всего много. Сначала разберитесь с прибиванием. Две головы, если речь о 82576, лучше связать в bond для более корректной нагрузки и потенциально бОльшей пропускной (до 2 Гбит вместо 1 Гбит). При таком трафике лучше не трогать встроенные сетевки, чтобы не мешать работе 82576. Двухпортового 82576 будет более чем достаточно для вашего объема. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Victor Safronov Опубликовано 13 марта, 2013 · Жалоба Не знаю, насколько это разумно, но сейчас прибил такой лесенкой: 55: 1 0 0 0 0 0 0 0 PCI-MSI-edge eth1 56: [11069556] 0 0 1161128062 0 0 0 0 PCI-MSI-edge eth1-TxRx-0 57: [18521978] 51830 0 0 0 2399348664 0 0 PCI-MSI-edge eth1-TxRx-1 58: 23 [10293156] 0 10001 0 0 0 1191214248 PCI-MSI-edge eth1-TxRx-2 59: 10163 [1152649703] 0 0 0 0 0 0 PCI-MSI-edge eth1-TxRx-3 60: 11489 0 [9828883] 0 0 0 0 1148097959 PCI-MSI-edge eth1-TxRx-4 61: 10975 0 [10324332] 0 0 1141687473 0 0 PCI-MSI-edge eth1-TxRx-5 62: 9611 0 0 [142411233] 0 0 0 0 PCI-MSI-edge eth1-TxRx-6 63: 10107 1159144435 0 [9571044] 0 0 0 0 PCI-MSI-edge eth1-TxRx-7 64: 1 0 0 0 0 0 0 0 PCI-MSI-edge eth3 65: 22 0 0 0 [8249542] 1042669775 51497 0 PCI-MSI-edge eth3-TxRx-0 66: 22 0 0 2444378745 [15203287] 0 87605 0 PCI-MSI-edge eth3-TxRx-1 67: 13251 12 21684 0 0 [8350308] 0 1034762213 PCI-MSI-edge eth3-TxRx-2 68: 22 1071911469 26593 0 14203 [8157025] 0 0 PCI-MSI-edge eth3-TxRx-3 69: 22 0 16115 1046380147 0 0 [8206871] 584722 PCI-MSI-edge eth3-TxRx-4 70: 22 1002006202 0 0 0 536994 [7820728] 26289 PCI-MSI-edge eth3-TxRx-5 71: 22 0 0 1110091 0 13662 0 [1032518059] PCI-MSI-edge eth3-TxRx-6 72: 22 961211 0 13764 0 999948926 0 [7667969] PCI-MSI-edge eth3-TxRx-7 Старая статистика до прибивания портит наглядность, но должно быть понятно :) Судя по всему, имеет смысл, сократить количество очередей до четырёх. А чем полезно выключение оффлоадов? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 13 марта, 2013 · Жалоба Судя по всему, имеет смысл, сократить количество очередей до четырёх. Не стоит. По всем 8 ядрам очередями каждый интерфейс размазать - и будет счастье. А чем полезно выключение оффлоадов? Тем, что толку 0 от них в роутинге, а с шейперами и т.п. они конфликтуют. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adnull Опубликовано 13 марта, 2013 · Жалоба Дропы есть? Канал в полку бывает? По LA видно что сервер почти курит. Проблемы есть? Нет? Зачем их решать тогда? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Victor Safronov Опубликовано 19 марта, 2013 · Жалоба Дропы есть? Канал в полку бывает? По LA видно что сервер почти курит. Проблемы есть? Нет? Зачем их решать тогда? :) Ну мало ли. Надо быть готовым ко всему :) Кстати, тут подворачивается сервер HP Proliant DL380 G5 с сетевыми на BCM5708. Вот они поддерживает multi-queue или тоже надо будет туда что-нибудь вроде Intel 82576 ставить? Сколько гуглил, так и не нашёл точного ответа. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 19 марта, 2013 · Жалоба Надо ставить Intel, проходили G5. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 20 марта, 2013 · Жалоба BCM5708 Однопоточки (потоки у них зачем-то в железе есть, но MSI-X не поддерживается, как следствие - инты не разделить). Плюс неплохо так грузят интами. Короткоочередные, при приближении нагрузки к 80% очень любят дропы даже при недогруженном проце. С другой стороны - для начального уровня (до ~1-1.5 Гбит трафика на что-то класса E5420) - вполне подойдут при условии использования RPS. Даже без специфичных твиков. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 20 марта, 2013 (изменено) · Жалоба А что на счет BCM5709c? Там очереди работают, но отзывов как-то не встречал.. Есть HPшный G6 с 6тью такими интерфейсами, не хочется просто так их менять. Изменено 20 марта, 2013 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 22 марта, 2013 · Жалоба Взорвал себе мозг обнаружив одну интересную закономерность в работе софтроутера. А именно: Есть сервер на двух Xeon E5540. На борту два порта: BCM57711E. Вставлена платка на 4 порта: 82571EB. Два встроенных бродкомовских интерфейса собраны в lacp bonding bond0 и смотрят в сторону интернета (линки по 1Гб). На каждый порт по 4 очереди/прерывания развешаны на 4 ядра первого процессора. Оставшиеся 4 интела собраны в bond1 и смотрят внутрь. Интерапты интелов повешены на 4 ядра второго процессора. CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 68: 250 0 0 0 2093741818 0 0 0 IR-PCI-MSI-edge eth2 73: 161135 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0 75: 1465180138 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-fp-0 76: 16593 3647641664 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-fp-1 77: 4447 0 1497707430 0 0 0 0 0 IR-PCI-MSI-edge eth0-fp-2 78: 9186 0 0 1510644930 0 0 0 0 IR-PCI-MSI-edge eth0-fp-3 79: 161144 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth1 81: 5112 1513929435 0 0 0 0 0 0 IR-PCI-MSI-edge eth1-fp-0 82: 3599112940 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth1-fp-1 83: 5240 0 0 1439802463 0 0 0 0 IR-PCI-MSI-edge eth1-fp-2 84: 4332 0 1462675245 0 0 0 0 0 IR-PCI-MSI-edge eth1-fp-3 85: 227 0 0 0 0 2118178819 0 0 IR-PCI-MSI-edge eth3 86: 228 0 0 0 0 0 2114268794 0 IR-PCI-MSI-edge eth4 87: 225 0 0 0 0 0 0 2156799972 IR-PCI-MSI-edge eth5 Через сервер бегает трафик. На входе (bond0) около 800мбит. Загрузка процессоров далека от 100%. При этом и на самом сервере, и на клиенте за ним, наблюдается следующая история. Тянем в один поток wget'ом с некоторого ftp, стоящего у вышестоящего провайдера. Тяну в 1 поток 11.2мбайта/с (около 100 честных мегабит) как на самом сервере(роутере), так и на клиенте. Берем файл на ftp2.ru.freebsd.org. Видим картинку куда печальнее - в лучшие времена около 4-7мегабайт/с, при большей нагрузке может быть и того меньше. Но что примечательно - стоит потянуть в несколько потоков lftp pget -n 10, например, и видим замечательно скорость около 100мбит/с, а на самом сервере и все несколько сотен. Если же клиентский IP отроутить мимо этого самого софтроутера - закачка в одну сессию становится веселее. Откуда растут вопросы: 1. Где затык? Ведь с некоего одного ftp мы видим в один поток все честные 100мбит, а с некоего другого в один поток ни в какую. При этом как показывают смежные тесты - фтп сервер способен отдавать существено большую скорость в 1 поток, нежели мы наблюдаем в реальности. 2. В какую сторону можно двигаться и куда копать? А что на счет BCM5709c? Там очереди работают, но отзывов как-то не встречал.. Есть HPшный G6 с 6тью такими интерфейсами, не хочется просто так их менять. Стоит две 2-х головых платки таких как ниже. Вроде едут норм. 03:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20) Subsystem: Broadcom Corporation Device 1917 Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at fa000000 (64-bit, non-prefetchable) [size=32M] Capabilities: [48] Power Management version 3 Capabilities: [50] Vital Product Data Capabilities: [58] MSI: Enable- Count=1/16 Maskable- 64bit+ Capabilities: [a0] MSI-X: Enable+ Count=9 Masked- Capabilities: [ac] Express Endpoint, MSI 00 Capabilities: [100] Device Serial Number 00-10-18-ff-fe-9d-12-26 Capabilities: [110] Advanced Error Reporting Capabilities: [150] Power Budgeting <?> Capabilities: [160] Virtual Channel Kernel driver in use: bnx2 Kernel modules: bnx2 CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 44: 1530325219 0 0 0 0 6 PCI-MSI-edge eth2-0 45: 3512258558 0 0 0 0 3 PCI-MSI-edge eth2-1 46: 0 4248180959 0 0 0 1 PCI-MSI-edge eth2-2 47: 0 0 987437417 0 0 5 PCI-MSI-edge eth2-3 48: 0 0 0 383412068 0 1 PCI-MSI-edge eth2-4 49: 0 0 0 0 841825087 1 PCI-MSI-edge eth2-5 50: 0 0 0 1 0 4040313913 PCI-MSI-edge eth2-6 52: 0 0 0 0 0 1463678266 PCI-MSI-edge eth3-0 53: 0 0 0 0 0 3460050862 PCI-MSI-edge eth3-1 54: 3409670956 0 0 0 1 0 PCI-MSI-edge eth3-2 55: 0 457389160 0 0 0 8 PCI-MSI-edge eth3-3 56: 0 0 446337170 0 0 1 PCI-MSI-edge eth3-4 57: 0 0 0 395466091 0 1 PCI-MSI-edge eth3-5 58: 0 0 0 0 519687263 1 PCI-MSI-edge eth3-6 60: 0 0 0 0 618133199 14 PCI-MSI-edge eth0-0 61: 0 0 0 0 2789380916 23 PCI-MSI-edge eth0-1 62: 0 0 0 0 0 1882917262 PCI-MSI-edge eth0-2 63: 1201784718 0 0 0 2 18 PCI-MSI-edge eth0-3 64: 0 503770750 0 0 0 1 PCI-MSI-edge eth0-4 65: 0 0 283256949 0 0 4 PCI-MSI-edge eth0-5 66: 0 0 0 233077182 0 1 PCI-MSI-edge eth0-6 68: 0 0 0 759127286 1 16 PCI-MSI-edge eth1-0 69: 0 0 0 2933903470 0 8 PCI-MSI-edge eth1-1 70: 0 0 0 0 2873845998 8 PCI-MSI-edge eth1-2 71: 0 0 0 0 0 1043693785 PCI-MSI-edge eth1-3 72: 3520592126 0 0 0 0 10 PCI-MSI-edge eth1-4 73: 0 4151452057 0 0 1 3 PCI-MSI-edge eth1-5 74: 0 0 3994587621 0 0 2 PCI-MSI-edge eth1-6 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 22 марта, 2013 · Жалоба Тяну в 1 поток 11.2мбайта/с (около 100 честных мегабит) как на самом сервере(роутере), так и на клиенте. Берем файл на ftp2.ru.freebsd.org. Видим картинку куда печальнее - в лучшие времена около 4-7мегабайт/с, при большей нагрузке может быть и того меньше. Но что примечательно - стоит потянуть в несколько потоков lftp pget -n 10, например, и видим замечательно скорость около 100мбит/с, а на самом сервере и все несколько сотен. Если же клиентский IP отроутить мимо этого самого софтроутера - закачка в одну сессию становится веселее. Откуда растут вопросы: 1. Где затык? Ведь с некоего одного ftp мы видим в один поток все честные 100мбит, а с некоего другого в один поток ни в какую. При этом как показывают смежные тесты - фтп сервер способен отдавать существено большую скорость в 1 поток, нежели мы наблюдаем в реальности. 2. В какую сторону можно двигаться и куда копать? Если отроутить мимо - насколько веселее закачка становится? Найдите файлообменник, способный отдавать несколько сот мбит, на нем и тестируйте. У нас были подобные подземные стуки. Вплоть до того, что с IP адресов, относящихся к различным AS, скорость однопотока отличалась в разы. Решилось сменой магистрала (магистрал арендовал канал на IX у другого магистрала/домотелекома, у которого каналы были где-то в полку забиты). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 22 марта, 2013 · Жалоба Если отроутить мимо - насколько веселее закачка становится? Найдите файлообменник, способный отдавать несколько сот мбит, на нем и тестируйте. У нас были подобные подземные стуки. Вплоть до того, что с IP адресов, относящихся к различным AS, скорость однопотока отличалась в разы. Решилось сменой магистрала (магистрал арендовал канал на IX у другого магистрала/домотелекома, у которого каналы были где-то в полку забиты). Как-то так. Исходные данные: сервер и еще один ПК торчат в одном коммутаторе в одном влане. ПК - одним портом 1Г, сервер транком 1+1Г. Вешаем айпишник на ПК. Включаем закачку: 23% [====================================> ] 553 263 792 34,2M/s ост 53s Скорость летит 30-34Мбайт/с. Перевешиваем айпи на сервер. И уже: 5% [=======> ] 123.050.248 6,13M/s eta 4m 53s Колеблется - в пиках до 10Мбайт, в среднем около 6. Причем полосы на интерфейсах в достатке: eth0: 452.28 Mb/s In 456.11 Mb/s Out - 62037.0 p/s In 67201.0 p/s Out eth1: 500.63 Mb/s In 406.58 Mb/s Out - 71679.0 p/s In 65577.0 p/s Out То есть запаса почти в половину на каждом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 22 марта, 2013 · Жалоба Перевешиваем айпи на сервер. И уже: Точно закачка идет с перевешанного ИП? На всякий случай убедитесь tcpdump к примеру. У нас подобное (с точностью до наоборот) наблюдалось из-за проблем с аплинком: на бордюре при закачке с ip из AS аплинка - 30-40 МБ/сек, при закачке с ip нашей AS - 3-5 МБ/с. Смущает то, что с сервера аплинка закачка в норме - это намекает, что скорее вего проблемы дальше, чем ваш сервер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 22 марта, 2013 (изменено) · Жалоба Точно закачка идет с перевешанного ИП? На всякий случай убедитесь tcpdump к примеру. У нас подобное (с точностью до наоборот) наблюдалось из-за проблем с аплинком: на бордюре при закачке с ip из AS аплинка - 30-40 МБ/сек, при закачке с ip нашей AS - 3-5 МБ/с. Смущает то, что с сервера аплинка закачка в норме - это намекает, что скорее вего проблемы дальше, чем ваш сервер. Убеждался tcpdump'ом. Указывал адрес wget --bind-address=<ip>. Соль в том, что: а) один и тот же адрес, включенный в один и тот же коммутатор, только на разных железках и в одном случае lacp, а в другом просто один порт - выдают разные скорости в один поток. б) если предположить затык в пути до аплинка - но с него же едет хорошо в обоих случаях в) если предположить затык за ним, то, во-первых, адрес у меня и на одной, и на другой железке то один и тот же, одним и тем же он остается и при запуске закачки в несколько потоков, а скорость чудным образом рождается из бездны. Вот такой вот комок противоречий, потому и не понятно ничего. Изменено 22 марта, 2013 пользователем heap Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
d1m0n Опубликовано 22 марта, 2013 · Жалоба у кого-нибудь сетевуха 82574L тянет 450-500 мбит/с FD с шейпером (TC HFSC) + лёгкие правила iptables + FV BGP? Вообще возможно ли такое? Процессор Xeon 3430 2,4 GHz, памяти 2 Гб. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 22 марта, 2013 · Жалоба у кого-нибудь сетевуха 82574L тянет 450-500 мбит/с FD с шейпером (TC HFSC) + лёгкие правила iptables + FV BGP? Вообще возможно ли такое? Процессор Xeon 3430 2,4 GHz, памяти 2 Гб. 4 сетевухи 82574L тянут порядка 500 мбит/с на порт с bonding, VLAN/QinQ, декапсуляцией PPPoE, сложным шейпером (TC HTB + IFB) + массивные правила iptables/ipset для классификации и сервисов + FV BGP на X5660 @ 2.8. Загрузка по каждому из 6 ядер при этом не превышает 35%. X3430 где-то в 2.5-3 раза слабее с учётом числа ядер, т.е. впритык, но должно потащить, если без PPPoE, и шейпер не очень сложный. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 23 марта, 2013 · Жалоба Точно закачка идет с перевешанного ИП? На всякий случай убедитесь tcpdump к примеру. У нас подобное (с точностью до наоборот) наблюдалось из-за проблем с аплинком: на бордюре при закачке с ip из AS аплинка - 30-40 МБ/сек, при закачке с ip нашей AS - 3-5 МБ/с. Смущает то, что с сервера аплинка закачка в норме - это намекает, что скорее вего проблемы дальше, чем ваш сервер. У меня такое ощущение, что не работает или как-то не так работает NAPI в bnx2x. На коленке сделал скриптик, который раз в 5 секунд считает PPS и IRQPS для интерфейсов. Получается что-то такое: eth0 -- PPS: 76897 -- IRQps: 70219 eth1 -- PPS: 72635 -- IRQps: 66999 eth2 -- PPS: 39957 -- IRQps: 14058 eth3 -- PPS: 32346 -- IRQps: 16307 eth4 -- PPS: 33862 -- IRQps: 15686 eth5 -- PPS: 29576 -- IRQps: 16251 Total: -- PPS: 285273 -- IRQps: 199520 driver: bnx2x version: 1.74.22 driver: bnx2x version: 1.74.22 driver: e1000e version: 2.2.14-NAPI driver: e1000e version: 2.2.14-NAPI driver: e1000e version: 2.2.14-NAPI driver: e1000e version: 2.2.14-NAPI Интела в два раза примерно отличается PPS от IRQPS, а вот с бродкомом что-то не то. :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 26 марта, 2013 · Жалоба С NAPI отбой. Работает. Посмотрел perf top. С небольшим отрывом лидирует: __ticket_spin_lock. Что за зверь такой? Кто-нибудь уже сталкивался? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 27 марта, 2013 (изменено) · Жалоба Господа! Тут в ветке много выкладок типа - подтюнинговал на роутере такие-то sysctl переменные. Разве следующие переменные несут смысл именно для роутера и транзитного трафика? net.core.wmem_max net.core.wmem_default net.ipv4.tcp_wmem net.core.rmem_max net.core.rmem_default net.ipv4.tcp_rmem net.ipv4.tcp_max_syn_backlog net.ipv4.tcp_sack net.ipv4.tcp_no_metrics_save net.core.somaxconn net.ipv4.ipfrag_high_thresh net.ipv4.ipfrag_low_thresh net.ipv4.ipfrag_time net.ipv4.ipfrag_secret_interval net.ipv4.ipfrag_max_dist Изменено 27 марта, 2013 пользователем heap Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 28 марта, 2013 · Жалоба У меня такое ощущение, что не работает или как-то не так работает NAPI в bnx2x. Работать-то он работает, но на плотных потоках всё равно появляются interrupt'ы, и много, а с coalescing'ом там всё не просто плохо, а очень плохо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 28 марта, 2013 · Жалоба У меня такое ощущение, что не работает или как-то не так работает NAPI в bnx2x. Работать-то он работает, но на плотных потоках всё равно появляются interrupt'ы, и много, а с coalescing'ом там всё не просто плохо, а очень плохо. Это надо так понимать, что сетевые на данном чипе - дело печальное? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
