vladd Опубликовано 12 марта, 2012 · Жалоба Имеется PC-роутер, с ядром 2.6.39 и 4-портовой сетевухой Intel 82576. Есть входящий линк от провайдера на интерфейс bond0, скорость на котором 1 гбит/c, и исходящий eth2 на локалку - пока без бондинга. Бондинг на провайдерском линке сделан заранее под расширение в будущем, суть не в этом. Также имеется суммарно около 30-40 правил в iptables (таблицы nat, raw и rawpost). Все качается и роутится замечательно. Так вот, стоит только юзерам загрузить канал свыше 800 мбит/c - так начинаются тормоза при роутинге. Но при этом есть странности: 1. Ни одно ядро не загружается больше 50% (прерывания каждого порта сетевухи жестко назначены на свое ядро). 2. Если качать из инета на сам сервер (wget-ом) - то скорость в один поток превышает 7-10 мбайт/c - что говорит о хорошем запасе у провайдера. 3. Если качать с сервера (там стоит тестовый апач) в локалку, то скорость в один поток - тоже около 10 мбайт/c, т.е. запас на внутреннем линке есть (!). Но, если качать тот же файл что и в п.2 из инета через роутер с любого хоста в локалке, скорость не превышает 500-1000 кбайт/c, иногда и ниже. Учитывая п.2 и 3, ничего не понимаю. Как может локально качаться нормально на обоих интерфейсах, а транзитом тоже самое - тормозить. Уже всю голову сломал. Тюнил что только можно. Помогите, хоть какой-нибудь совет.. Шейперов нет, tc qdisc пусто. Проц Core i5-2500 @ 3.30GHz. Еще раз - загрузка ядер меньше 50% каждого, не в проце по идее дело. Что же может быть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Lynx10 Опубликовано 12 марта, 2012 (изменено) · Жалоба с нат всё в порядке ? если быть точнее то с conntrack Изменено 12 марта, 2012 пользователем Lynx10 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MMM Опубликовано 13 марта, 2012 · Жалоба perf top смотрите, скорее всего conntrack Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vladd Опубликовано 13 марта, 2012 · Жалоба conntrack точно не причем, т.к. одинаково плохо качается и с ната, и с реальников. Более того, недавно заменил conntrack на 1:1 нат через правила RAWSNAT/RAWDNAT - качается все также плохо в часы пик, как и с обычным натом. Каждому абоненту при авторизации динамически создается 2 правила (по типу licg), а чтобы не было перегрузки iptables, используются древовидные цепочки в iptables. Этих цепочек порядка 2000, зато получается что пакет по пути проходит не более чем через 20-40 правил. Вот что показывает perf top днем: 3128.00 13.8% ipt_do_table /lib/modules/2.6.39.4/kernel/net/ipv4/netfilter/ip_tables.ko 1514.00 6.7% igb_poll /lib/modules/2.6.39.4/kernel/drivers/net/igb/igb.ko 1010.00 4.5% _raw_spin_lock /lib/modules/2.6.39.4/build/vmlinux 758.00 3.3% ip_route_input_common /lib/modules/2.6.39.4/build/vmlinux 593.00 2.6% nf_iterate /lib/modules/2.6.39.4/build/vmlinux 541.00 2.4% kfree /lib/modules/2.6.39.4/build/vmlinux Получается затык в iptables. Посмотрю еще вечером. Неужели 30 правил могут вызывать такой перегруз? И почему тогда ни одно ядро процессора не затыкается, а роутится плохо? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 13 марта, 2012 · Жалоба ну можно же на пять минуток iptables -F и повторить тест =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 13 марта, 2012 · Жалоба Получается затык в iptables. Посмотрю еще вечером. Неужели 30 правил могут вызывать такой перегруз? И почему тогда ни одно ядро процессора не затыкается, а роутится плохо? А загнать все в ipset и 1-3 правила никак не получится? Все-таки обход 30 правил при 10М и при 800М это немного разные вещи. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vladd Опубликовано 13 марта, 2012 (изменено) · Жалоба А загнать все в ipset и 1-3 правила никак не получится? Все-таки обход 30 правил при 10М и при 800М это немного разные вещи. Был бы рад, но вижу как это сделать. Для каждого юзера требуется сопоставить "уникальный серый ip" <-> "уникальный реальник". И кажется врядли в iptables тут дело - тормоза в часы пик на любых ip - и на серых (которые прогоняются через iptbles), и на реальных (которые в первых 1-2 правилах отсекаются и не идут через все дерево). Когда экспериментировал с iptables и средним размером цепочки - проверял, при слишком большом количестве обрабатываемых правил (более 100) резко растет загрузка ядер. Тут же загрузки нет. Т.е. вред от iptables под большим сомнением. Изменено 13 марта, 2012 пользователем vladd Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
random7 Опубликовано 13 марта, 2012 · Жалоба И почему тогда ни одно ядро процессора не затыкается, а роутится плохо? Из-за блокировок, может быть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vladd Опубликовано 13 марта, 2012 · Жалоба Из-за блокировок, может быть? Блокировки не к этому случайно относятся?: 2232.00 13.7% ipt_do_table /lib/modules/2.6.39.4/kernel/net/ipv4/netfilter/ip_tables.ko 1030.00 6.3% igb_poll /lib/modules/2.6.39.4/kernel/drivers/net/igb/igb.ko 951.00 5.8% _raw_spin_lock_bh /lib/modules/2.6.39.4/build/vmlinux 676.00 4.2% _raw_spin_lock /lib/modules/2.6.39.4/build/vmlinux Нагрузка возрастает, и появляется _raw_spin_lock, при том что ipt_do_table остается без изменений. Есть ли идеи, как с этим можно бороться? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Megas Опубликовано 13 марта, 2012 · Жалоба офтоп. какой прогой получили 2232.00 13.7% ipt_do_table /lib/modules/2.6.39.4/kernel/net/ipv4/netfilter/ip_tables.ko 1030.00 6.3% igb_poll /lib/modules/2.6.39.4/kernel/drivers/net/igb/igb.ko 951.00 5.8% _raw_spin_lock_bh /lib/modules/2.6.39.4/build/vmlinux 676.00 4.2% _raw_spin_lock /lib/modules/2.6.39.4/build/vmlinux Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
voron Опубликовано 13 марта, 2012 · Жалоба perf, например из /usr/src/linux/tools Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Megas Опубликовано 13 марта, 2012 · Жалоба нашел здесь: http://www.mmnt.net/db/0/0/ftp.spline.de/pub/dhozac/centos/5/vserver/i386 perf-2.6.32-131.12.1.el5.vs2.3.0.36.29.6.18.i686.rpm но при запуске свистит: # perf top Error: sys_perf_event_open() syscall returned with -1 (Function not implemented). /bin/dmesg may provide additional information. Fatal: No CONFIG_PERF_EVENTS=y kernel support configured? # Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 13 марта, 2012 · Жалоба vladd Попробуйте обновить ядро на более свежее. Megas Английским по белому же пишет: ядро не сконфигурено для профайлинга. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vladd Опубликовано 13 марта, 2012 · Жалоба vladd Попробуйте обновить ядро на более свежее. Т.е. уже на 3.2 переходить? Под нагрузкой да, только до 800 мбит дошло, и на первое место вылез _raw_spin_lock_bh - 14-16%, опередив iptables. Попробую обновить ядро, там что-то серьезное фиксили разве? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telecom Опубликовано 13 марта, 2012 · Жалоба Думаю, и на 3.2.10 у Вас будет _raw_spin_lock на первом месте... Надо искать, откуда эти блокировки идут! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 14 марта, 2012 (изменено) · Жалоба Неплохо бы полный набор правил iptables видеть еще. Чтобы снизить число блокировок в igb (если это конечно igb в данном случае) - увеличьте для начала очереди rx/tx на карточках через ethtool до максимально возможных значений, и ifconfig'ом софтовую tx очередь (txqueuelen) выставите также в размер аппаратной. Изменено 14 марта, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lllsergeyv Опубликовано 14 марта, 2012 (изменено) · Жалоба vladd Попробуйте обновить ядро на более свежее. Какое ядро посоветуете? стоит с 2.6 уже слазить? Изменено 14 марта, 2012 пользователем lllsergeyv Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 14 марта, 2012 · Жалоба Попробую обновить ядро, там что-то серьезное фиксили разве? Локи вычищали в частности. На ядра 2.6.36-37...2.6.39 вроде как тут жаловались, странности с шейперами и т.п. Второй вариант - попытаться откатиться на 2.6.35. С ним вроде как я особых странностей не наблюдал. Какое ядро посоветуете? стоит с 2.6 уже слазить? Объявление 3-й ветки не связано с гигантскими изменениями по сравнению с 2.6. Различия между 2.6.39 и 3.0 не больше, чем к примеру между 2.6.34 и 2.6.35. 3.2 позиционируется как long-term, соответственно стоит остановиться на нем пока. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lllsergeyv Опубликовано 14 марта, 2012 · Жалоба Какое ядро посоветуете? стоит с 2.6 уже слазить? Объявление 3-й ветки не связано с гигантскими изменениями по сравнению с 2.6. Различия между 2.6.39 и 3.0 не больше, чем к примеру между 2.6.34 и 2.6.35. 3.2 позиционируется как long-term, соответственно стоит остановиться на нем пока. у меня еще 2.6.32 debian Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 14 марта, 2012 · Жалоба Первая заповедь инженера - "работает - не трогай". О смене ядра стоит задумываться только в том случае, когда текущее чем-то не устраивает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lllsergeyv Опубликовано 14 марта, 2012 (изменено) · Жалоба Первая заповедь инженера - "работает - не трогай". О смене ядра стоит задумываться только в том случае, когда текущее чем-то не устраивает. По производительности пока устраивает. смущает только то, что при малом трафике(меньше 200мбит) возростает загрузка проца(сетевушки ixgbe). ping latency по всем направлениям через роутер в это время тоже немного увеличивается. Изменено 14 марта, 2012 пользователем lllsergeyv Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 14 марта, 2012 · Жалоба смущает только то, что при малом трафике(меньше 200мбит) возростает загрузка проца(сетевушки ixgbe) Может энергосбережение работает, частота ядер снижается? ;) Тогда будет сходный эффект (рост нагрузки при снижении траффика ступенькой, небольшой рост пингов). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telecom Опубликовано 15 марта, 2012 · Жалоба смущает только то, что при малом трафике(меньше 200мбит) возростает загрузка проца(сетевушки ixgbe) Может энергосбережение работает, частота ядер снижается? ;) Тогда будет сходный эффект (рост нагрузки при снижении траффика ступенькой, небольшой рост пингов). Это только я всегда думал, что на маршрутизаторах надо отключать энергосберегающие плюшки типа cpu_idle cpu_freq ибо от них больше вреда, чем пользы? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 15 марта, 2012 · Жалоба А какой вред-то, по большому счету? Рост пинга на 0.5 мс при малой нагрузке? Или некрасивые графики? :) А вот если стойка юзает в качестве резервного источника энергии батареи - то энергосбережение тут вполне пригодится. Ибо каждый ватт на счету при отключении основного источника. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 19 марта, 2012 · Жалоба Стоп. Я заметил i686 в названии пакета. У Вас действительно - x86-ядро, не x86-64? Сколько памяти на машине? PAE включено? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...