Wingman Опубликовано 25 марта, 2010 · Жалоба Wingman Спасибо за наводки. Топики уже читаю. Не затруднит ли Вас поделиться конфигом ядра и прочими тюнингами от вашей success-story? :) В личку скину ну вот...с таким интересом следил за темой :) Да там ничего особенного, в принципе ж) Конфиг ядра мало изменён от дефолта. Повключал всё нужное, поотключал что-то ненужное типа звуковух. Подкрутил несколько вещей, найденых в темах тут, на наге, как уже писал - типа socket security. Ну ещё, хотя врядли это имеет значение, старался всё влючать статикой, т.к. монолитное ядро мне более импонирует. В iptables основной тюнинг - это NOTRACK и дроп торрентовского uTP. sysctl, отличия от дефолта: net.ipv4.ip_forward = 1 net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 3600 net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter = 0 net.netfilter.nf_conntrack_max = 1048576 net.nf_conntrack_max = 1048576 net.ipv4.neigh.default.gc_thresh1 = 4096 net.ipv4.neigh.default.gc_thresh2 = 4096 net.ipv4.neigh.default.gc_thresh3 = 4096 net.ipv4.tcp_sack = 0 net.ipv4.tcp_window_scaling = 0 Остальной "тюнинг" уже технический. Все каналы от аплинков + труба во внутреннюю сеть собраны в один бонд для максимальной балансировки. Режим бондинга на линухе: options bond0 mode=4 miimon=1000 xmit_hash_policy=1 На коммутаторе - лацп, src_dst_ip Раньше был core quad 2.6ггц, четырёхголовая сетевуха e1000e. Сейчас Xeon 2x4 2.0 ггц, две четырёхголовых сетевухи igb (4 простаивают => 4 ядра тоже). При этом кваду плохело при почти в 2 раза меньшей нагрузке. Уж не знаю, связано ли это с процем, или сетевухами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ibmed Опубликовано 25 марта, 2010 · Жалоба А я приношу публичную клятву отписаться об успехах в репродукции бордера на линуксе :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martin74 Опубликовано 25 марта, 2010 · Жалоба Все каналы от аплинков + труба во внутреннюю сеть собраны в один бонд для максимальной балансировки. Это как? Имеем внешние каналы скажем eth2,eth3,eth4. На трех разных провайдеров. И eth0,eth1 смотрят в локалку. bond0 - объединяет eth0 eth1. А как сюда остальные то сетевые прикрутить??? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 25 марта, 2010 (изменено) · Жалоба Все каналы от аплинков + труба во внутреннюю сеть собраны в один бонд для максимальной балансировки. Это как? Имеем внешние каналы скажем eth2,eth3,eth4. На трех разных провайдеров. И eth0,eth1 смотрят в локалку. bond0 - объединяет eth0 eth1. А как сюда остальные то сетевые прикрутить??? Uplink1 --> --Коммутатор-- <-- Uplink2 | |||| <---------- тут летает ваааще всё;) | Border | | | | <------- тут - влан из бордера | локалка Изменено 25 марта, 2010 пользователем Wingman Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 25 марта, 2010 · Жалоба Почему бы не попробовать собрать все линки (и в локалку, и от аплинков) на коммутатор, и гонять трафик на бордер в едином бонде? Так по идее нагрузка должна более равномерно распределяться. Ну и оставшиеся сетевушки задействуйте, пусть простаивающие ядра вкалывают Я года как 4 с линукс-роутеров на фрю всё перевёл. На линуксе не бьются на треды igb? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 25 марта, 2010 (изменено) · Жалоба Почему бы не попробовать собрать все линки (и в локалку, и от аплинков) на коммутатор, и гонять трафик на бордер в едином бонде? Так по идее нагрузка должна более равномерно распределяться. Ну и оставшиеся сетевушки задействуйте, пусть простаивающие ядра вкалываютЯ года как 4 с линукс-роутеров на фрю всё перевёл. На линуксе не бьются на треды igb? Мне бить смысла нет; 8 ядер = 8 сетевух. При этом загрузка 4 сетевух при чуть менее 4гб фул дуплекс в бонде -- охренительно далека от 100%. Другими словами, пропускная способность задействованных портов заканчивается задолго до "скуксивания" машинки в целом. Изменено 25 марта, 2010 пользователем Wingman Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 25 марта, 2010 · Жалоба Почему бы не попробовать собрать все линки (и в локалку, и от аплинков) на коммутатор, и гонять трафик на бордер в едином бонде? Так по идее нагрузка должна более равномерно распределяться. Ну и оставшиеся сетевушки задействуйте, пусть простаивающие ядра вкалываютЯ года как 4 с линукс-роутеров на фрю всё перевёл. На линуксе не бьются на треды igb? Мне бить смысла нет; 8 ядер = 8 сетевух. При этом загрузка 4 сетевух при чуть менее 4гб фул дуплекс в бонде -- охренительно далека от 100%. Другими словами, пропускная способность задействованных портов заканчивается задолго до "скуксивания" машинки в целом. Тогда мне не понятен смысл бондинга в сторону аплинков. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 25 марта, 2010 (изменено) · Жалоба Почему бы не попробовать собрать все линки (и в локалку, и от аплинков) на коммутатор, и гонять трафик на бордер в едином бонде? Так по идее нагрузка должна более равномерно распределяться. Ну и оставшиеся сетевушки задействуйте, пусть простаивающие ядра вкалываютЯ года как 4 с линукс-роутеров на фрю всё перевёл. На линуксе не бьются на треды igb? Мне бить смысла нет; 8 ядер = 8 сетевух. При этом загрузка 4 сетевух при чуть менее 4гб фул дуплекс в бонде -- охренительно далека от 100%. Другими словами, пропускная способность задействованных портов заканчивается задолго до "скуксивания" машинки в целом. Тогда мне не понятен смысл бондинга в сторону аплинков. Во-первых, от одного берём больше гига Во-вторых, со старым бордером одна сетевуха при подходе к гигу уже не справлялась, в новом воткнули в бонд В-третьих, в любом случае - нафиг мне надо, чтобы одна сетевуха была нагружена заметно сильнее остальных? Лишнее узкое место Изменено 25 марта, 2010 пользователем Wingman Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ibmed Опубликовано 6 апреля, 2010 · Жалоба Wingman Какая-то тотальная ерунда. Поднимали сегодня на линуксе бордер. 2 Xeon-а по 4 ядра. 2 4-хголовых igb. 0a:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) Subsystem: Intel Corporation Gigabit ET Quad Port Server Adapter Сперва все хорошо, а потом нагрузка проца сваливается до 25% по графику. Трафик проседает. PPS проседает. top: 4 root 20 0 0 0 0 R 76 0.0 21:21.86 ksoftirqd/0 979 root 20 0 0 0 0 R 18 0.0 4:41.63 kondemand/0 19 root 20 0 0 0 0 S 6 0.0 1:01.15 events/0 16053 root 20 0 19132 1344 980 R 0 0.0 0:00.02 top 1 root 20 0 19324 1728 1176 S 0 0.0 0:00.86 init 2 root 20 0 0 0 0 S 0 0.0 0:00.00 kthreadd 3 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/0 5 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/1 6 root 20 0 0 0 0 S 0 0.0 0:00.02 ksoftirqd/1 7 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/2 8 root 20 0 0 0 0 S 0 0.0 0:00.04 ksoftirqd/2 9 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/3 10 root 20 0 0 0 0 S 0 0.0 0:01.04 ksoftirqd/3 11 root RT 0 0 0 0 S 0 0.0 0:00.01 migration/4 12 root 20 0 0 0 0 S 0 0.0 0:00.06 ksoftirqd/4 13 root RT 0 0 0 0 S 0 0.0 0:00.02 migration/5 14 root 20 0 0 0 0 S 0 0.0 0:00.18 ksoftirqd/5 15 root RT 0 0 0 0 S 0 0.0 0:00.01 migration/6 16 root 20 0 0 0 0 S 0 0.0 0:00.03 ksoftirqd/6 17 root RT 0 0 0 0 S 0 0.0 0:00.02 migration/7 18 root 20 0 0 0 0 S 0 0.0 0:00.05 ksoftirqd/7 Подскажите, используется ли у Вас NAPI для igb (и какая версия драйвера?). Перерыл интернет, не могу найти ничего про это. Как посмотреть, есть ли оно? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 7 апреля, 2010 · Жалоба Подскажите, используется ли у Вас NAPI для igb (и какая версия драйвера?). Перерыл интернет, не могу найти ничего про это.Как посмотреть, есть ли оно? Да. Странно. Где ж я его видел? # ethtool -i eth0 driver: igb version: 1.3.16-k2 firmware-version: 1.2-1 bus-info: 0000:01:00.0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 8 апреля, 2010 (изменено) · Жалоба gw ~ # ethtool -i eth1 driver: igb version: 2.1.1 firmware-version: 2.1-0 bus-info: 0000:01:00.1 Случайно всяких лишних шейперов и натов не навешано на бордер? Покажи iptables -L -n -t raw При каком трафике и pps такой затык? Вылазит только ksoftirqd/0 (а не ksoftirqd/1, 2, 3, etc) (одно ядро, одна сетевуха), значит, либо его чем-то сторонним нагрузил, либо bonding не работает, либо - ну дальше сам додумай ;) Сетевухи и ядра должны быть равномерно нагружены: 4 root 20 0 0 0 0 S 0 0.0 17:19.42 ksoftirqd/0 6 root 20 0 0 0 0 S 0 0.0 0:52.85 ksoftirqd/1 8 root 20 0 0 0 0 S 0 0.0 0:00.34 ksoftirqd/2 10 root 20 0 0 0 0 S 0 0.0 0:57.57 ksoftirqd/3 12 root 20 0 0 0 0 S 0 0.0 18:45.29 ksoftirqd/4 14 root 20 0 0 0 0 S 0 0.0 2:22.53 ksoftirqd/5 16 root 20 0 0 0 0 S 0 0.0 19:19.75 ksoftirqd/6 18 root 20 0 0 0 0 S 0 0.0 20:28.50 ksoftirqd/7 Изменено 8 апреля, 2010 пользователем Wingman Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ibmed Опубликовано 8 апреля, 2010 · Жалоба Ага, пробовал и с этим драйвером. Ни шейперов, ни ната. Файрвол выкомпилен из ядра вообще. Только маршрутизация. Успел даже поплясать вокруг параметров драйвера таких как интеррапттротл и иже с ним. Все одно. Как pps под 500k - вылезают эти грешные ksoftirqd. И никто главное не пишет, как это лечить :) В итоге вернулся на фрю. Теперь надо подумать, чем можно адекватную синтетику по pps сделать, чтобы проверить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 8 апреля, 2010 · Жалоба Ни шейперов, ни ната. Файрвол выкомпилен из ядра вообще. Только маршрутизация.Ххе ;)Вот вкомпиль обратно файервол, и iptables -t raw -A PREROUTING -j NOTRACK Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ibmed Опубликовано 8 апреля, 2010 · Жалоба Wingman Как же ж так? :) Неужели действительно должно помочь? Я в свое время специально эксперименты ставил по прокачиванию трафика через машинку. И линукс, и фря показали лучшие показатели именно с выкомпиленным файрволом. Т.е. пустой файрвол давал одну цифру, а выключенный в ядре в принципе давал еще лучше цифру. Поэтому меня сие, конечно, удивляет :) Этому есть какое-то разуменое объяснение? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 8 апреля, 2010 (изменено) · Жалоба Wingman Как же ж так? :) Неужели действительно должно помочь? Я в свое время специально эксперименты ставил по прокачиванию трафика через машинку. И линукс, и фря показали лучшие показатели именно с выкомпиленным файрволом. Т.е. пустой файрвол давал одну цифру, а выключенный в ядре в принципе давал еще лучше цифру. Поэтому меня сие, конечно, удивляет :) Этому есть какое-то разуменое объяснение? cat /proc/net/ip_conntrack | wc -l сколько записей? Если conntrack не убить вообще в ядре или не убирать его нетфильтром, то ядро "следит" за всеми Ip-сессиями. Используется это, как правило, для ната. И даёт нехилую такую нагрузку ;) А файервол на бордере может пригодиться для закрытия ssh, например, или для защиты от ddos. Мне актуально Изменено 8 апреля, 2010 пользователем Wingman Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ibmed Опубликовано 8 апреля, 2010 · Жалоба conntrack я из ядра убирал в том числе машинку сейчас уже снял, не могу заглянуть в боевом режиме :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 8 апреля, 2010 · Жалоба conntrack я из ядра убирал в том числемашинку сейчас уже снял, не могу заглянуть в боевом режиме :( Тогда нужно понять, что такое странное может грузить _одно_ ядро из восьми, при восьми задействованных сетевухах. СтОит посмотреть, равномерно ли бегает трафик в бонде, вдруг трафик бегает всего по одной сетевухе. Если совсем ничего левого (нетфлоу м.б.?) не поднято, можно попробовать опрофайлером посмотреть, что грузит Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 8 апреля, 2010 · Жалоба cat /proc/net/ip_conntrack | wc -lсколько записей? Где-то тут рассказывалось о убойственности такой конструкции.conntrack -L | wc -l Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ibmed Опубликовано 8 апреля, 2010 (изменено) · Жалоба посмотрел на машинку, такого файлика в /proc нет вообще равно как и утилиты conntrack опрофайлер ставил и пересобирал ядро с его поддержкой, но уже когда трафик спал ksoftird уже не выскакивал, и я ничего интересного не увидел (кстати, как им правильно смотреть?) я делал по примеру: opcontrol --start --vmlinux=/home/user/vanilla/linux-2.6.32.11/vmlinux opreport --symbols --image-path=/lib/modules/2.6.32.11/kernel/ видел примерно: samples % image name app name symbol name 474582228 60.0120 vmlinux vmlinux poll_idle 31202940 3.9457 vmlinux vmlinux read_hpet 24404813 3.0860 vmlinux vmlinux acpi_idle_do_entry 22893445 2.8949 e1000e.ko e1000e.ko e1000_poll (это я уже от отчаянья другие сетевые пробовал) 14932479 1.8882 vmlinux vmlinux get_partial_node (это сейчас с пустой машины) теперь только в синтетике можно будет посмотреть Изменено 8 апреля, 2010 пользователем ibmed Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 8 апреля, 2010 · Жалоба ibmed, /proc/irq/<N>/smp_affinity задавали? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ibmed Опубликовано 8 апреля, 2010 · Жалоба Умник Не успел. На тот момент, когда проблема вылезала, этого сделано не было. Я так понял, его можно задавать после установки irqbalance-а. Но когда я до этого дочитался, трафика уже не было толком и было принято политическое решение возвращаться на фрю. Вообще удивительно, конечно. Ибо предыдущий линукс-бордер жил достаточно хорошо (с выкомпиленным файрволом и е1000е-NAPI) и прокачивал явно больше, чем то, где загнулась более свежая машина, которая выигрывает как по железу, так и по новому ядру. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 8 апреля, 2010 (изменено) · Жалоба ibmed, irqbalance лучше удалить, а не устанавливать. :) Вообще с affinity и нужно было начинать. Изменено 8 апреля, 2010 пользователем Умник Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ibmed Опубликовано 8 апреля, 2010 (изменено) · Жалоба Умник О как :) На самом деле я, конечно, ожидал хороших результатов, имея опыт с успешно работавшим линукс-бордером на относительно слабом железе и предыдущем ядре. А тут такая штука. Теперь надо попробовать адекватную синтетику сделать и поиграться с шейпером под htb. А вообще мы приняли политическое решение переезжать на аппартный бордер :) Изменено 8 апреля, 2010 пользователем ibmed Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...