Перейти к содержимому
Калькуляторы

RushOnline

Пользователи
  • Публикации

    13
  • Зарегистрирован

  • Посещение

О RushOnline

  • Звание
    Абитуриент
  1. # Запускаем на нашем DNS tcpdump: ns # tcpdump -nvvi eth0 -s0 port 53 and host myworkstation # С рабочей станции, которую мы указали в фильтре, формируем запрос (man host, nslookup): myworkstation $ ping xxx.ru # Получаем вывод tcpdump на DNS: 18:38:38.989132 IP (tos 0x0, ttl 62, id 4024, offset 0, flags [DF], proto UDP (17), length 52) 213.148.160.88.57268 > 213.148.161.1.53: [udp sum ok] 40650+ A? xxx.ru. (24) 18:38:39.008111 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 68) 213.148.161.1.53 > 213.148.160.88.57268: [bad udp cksum 7ac8!] 40650 q: A? xxx.ru. 1/0/0 xxx.ru. A 188.127.235.68 (40) Думаю про дальнейший grep и прочую ты знаешь и без меня :)
  2. Абсолютно плюсуюсь. Насчёт перечитывания системой изменившегося физического объёма (подцепили вторую корзину на 10TiB, итого стало 20TiB) - мне так и не удалось, пришлось перезагрузать. Пытался сделать и hdparm -w, hdparm -w (опасно!), partprobe, и долго мучал Dell'овскую утилиту MegaCLI64. После перезагрузки - без проблем, система увидела новый объём. Да, и ещё - мой parted не смог ни resize ни move (собирал самый новый - пофиг), поэтому пришлось тупо запомнить начало расширяемой паритиции, потом удалить её, а потом создать заново с тем же началом и другим концом. После монтирования (именно так) выполнил xfs_growfs - вуаля, всё ок. За что люблю xfs - никогда проблем с ним не было ни на больших нагруженных серверах, ни на десктопах, и даже на нетбуке.
  3. Новые данные: P4 D (2x3.4GHz) 600 абонентов, шейпинг отключен, загрузка до 30%. Похоже шейперы не при чём ?!
  4. Шейперы отключать чревато, ибо мы то покупаем трафик, а не полосу :( Но я всё же попробую - просто не всё сразу, и отпишусь. К тому же после отрубания шейперов будет непросто их вернуть - текущее состояние держит самописный демон, и в нём такой функции нед. Ну да ладна, скину 800 человек с линии :) :( Насчёт oprofile - ядро скомпилировано без него, менять ведро страшновато, ибо хз какие там были наложены патчи, а исходники все утеряны.
  5. vadislaus, vitalyb, Ivan Rostovikov - спасибо за _конкретную_ информацию, стало более понятно, что потенциал ещё есть, надо жать дальше. Отвечаю всем вышеперечисленным + 2c2i: Да, правила отрубал. Точнее как отрубал - не совсем. В той длинной 700-правильной цепочке ставил первым правилом -j RETURN. И ничего не менялось. Поэтому подозрения на iptables сразу рассеялись, но теперь я всё равно буду его иметь ввиду, ещё раз спасибо за конкретную инфу. И ещё - пришла бредовая идея: может быть одна корневая htb дисциплина на imq/ifb будет быстрее, чем сотни на клиентских ppp-интерфейсах ? Судя по коду ведра это даст некоторую прибавку, да, особенно если все структуры улягутся в кеш процессора. К сожалению их оттуда будут вышвыривать некоторые необходимые userspace софтины, но тут то уже будет можно призвать на помощь разделение процессорного труда ? :)
  6. Я ждал этого впроса :) Да. Есть. Количество правил ~ количеству ppppoe-интерфейсов (антиспуф) + пара правил для маркировки локального трафика + пара правил в таблице nat для прокидывания клиентов с серыми адресами (завирусованные, деньги кончились и т.д.) к личному кабинету. В таблице маршрутизации ничего лишнего, таблица тоже ~ кол-во pppoe-интерфейсов + несколько служебных. Итого, тормозня начинается примерно от 700 зашейпленных pppoe-интерфейсов, 700 правил антиспуфа и 700 маршрутов. Из за тех двух правил в таблице nat используется ip/nf_conntrack, hashsize которому задан 200000. Кстати после установки ethtool -G eth0 rx <max_rx> tx <max_tx> и echo 200000 > /sys/modules/ip_conntrack/parameters/hashsize клиентам полегчало, пакеты почти перестали дропаться.
  7. Если вы это мне - абсолютно не наш вариант. Мы раздаём фиксированные, но разные полосы и ничего между ними не делим. Не хватает аплинка - подключаем второй. Смысл использования imq/ifb появляется только тогда, когда исходящий трафик идёт на разных логических линках (не бондится). Если аплинк один - исходящий интерфейс и есть тот самый ifb/imq, и без всяких извращений типа патча в и так дырявое ведро.
  8. Конечно ядерный, если бы он был в юзерспейс, думаю дело до 50Кп/с бы не дошло. И процессор кушал бы не software irq, а pppoe. Сегодня начали работу над новой прошивкой, закидывайте меня помидорами, но это ubuntu server. Пока 9.10, но с расчётом - когда прошивка будет готова к злому тестированию, уже наверняка выйдет 10.04, а это LTS на 5 лет. Позже и дебиан свежий стабилизируется (думаю к осени). У нас есть свой комп - сборщик пакетов (типа ланчпада, но попроще), так что за оптимизацию и перекомпиляцию самых ответственных вещей можно не беспокоиться, будет и то и другое + патчи под чисто наши нужды. Впрочем это уже другой вопрос, и надо открывать тему (если нету такой) - "Выбор дистрибутива для PPPoE NAS с шейпером" :) Если есть желающие почитать, как будет создаваться NAS - отпишитесь тут, и я постараюсь все основные шаги опубликовать в блоге. Все мы когда то с чего то начинали, и лет пять назад я бы с удовольствием почитал что-нибудь такое, да ещё и на русском. А просто так писать, в надежде что когдаааа нибудь комуууу нибудь понадобится (ещё и найдётся в поисковике) - времени нет, да и ленииииво :)
  9. Странно, но я наоборот, много раз видел на nag.ru что MSI надо включать. Что даст смена MSI на ACPI или что-там ? Ага, вот это уже дело, ибо как говорит Придётся перекомпилировать ведро, теперь осталось выяснить, как скомпилить то самое ведро с теми самыми патчами той самой gentoo, дабы не поломать ps, top etc. Может осталось у кого, ибо с нуля это два дня компиляций (конфиг ведра слава богу есть) ? Ибо прародитель этой прошивки давно канул в лету, а на свежем дистрибе пока сделать ниасилили, хотя давно пора перебираться на x64 (кроме этих 20-ти NAS у нас больше x32 и нету, даже на десктопах...). Напоследок отвечаю ниасилившим моё первое сообщение (как я вас понимаю, ребята, сам не люблю такие портянки читать без человеческих комментариев, но писать комментарии уже не было сил), осилившие же могут скипнуть остаток мессаги: 1. Шейперы вешаются на абонентский ppp интерфейс, так как шейпить мы можем только исходящий трафик. А входящий для абонента трафик это и есть исходящий с ppp-интерфейса NAS. 2. Корневая дисциплина - HTB, её класс по-умолчанию - максимальная пропускная способность интерфейса, у нас она 100Mbit. 3. В эти 100Мбит входят два класса - шейпер, заданный по умолчанию в корневой дисциплине и шейпер на локальные ресурсы. 4. И главный пункт - в класс, определяющий скорость на локальные ресурсы, пакеты отправляют всего два u32 фильтра - ХЕШИ ИСПОЛЬЗОВАТЬ НЕ ТОЛЬКО БЕССМЫСЛЕННО, НО И ВРЕДНО ДЛЯ ПРОИЗВОДИТЕЛЬНОСТИ :) Хешированные фильтры у нас применяются, но, как я уже упоминал, на интерфейсе аплинка, ибо тут мы уже шейпим исходящий трафик абонента, и уже не можем это сделать на его ppp-интерфейсе (на входящий трафик можно только policer ставить). Там - да, там применяются, но, как опять же я уже писал в первом сообщении их отключение заметного прироста производительности не даёт.
  10. Список к сожалению небогат. Сам pppd как известно с радиусом не работает вообще, поэтому с ним в поставке идёт два плагина: 1. raduis - RADIUS authentication plugin, соответственно учит pppd авторизации через радиус. 2. radattr - The radattr plugin for pppd causes all radius attributes returned by the RADIUS server at authentication time to be stored in the file, соответственно умеет тупо писать ответ радиуса в текстовый файл. Соответственно найдёте/напишете ещё плагинов - будет доп.функционал. Нет - тогда это вроде всё, что умеет pppd с radius.
  11. Да, конечно я это знаю. Наверно я не правильно понял предыдущего оратора. Не знаю... Что это даст ? На первый взгляд то же самое, вид сбоку, ибо переключений контекста столько же. Спасибо за хинт про аффинити, часто тут встречал сообщения про привязку прерываний к одному CPU, но ни разу что то не видел _как_ это сделать. Причём как ни странно там уже единички: at64 ~ # cat /proc/irq/220/smp_affinity 1 Впрочем ни проблемы ни решения тут всё равно не видать, ибо процессоры то кушаются в software irq, а значит тормозня похоже в коде шейпера и не связана с оборудованием, хотя факты вроде как утверждают обратное. П.С.: Почитал код шедулера пакетов - нечему там тормозить. По крайней мере на современном процессоре. Где же тот код, что его ест ?!
  12. что-то у меня ощущение что это ответ на ваш вопрос К сожалению нет, ибо из первого блока, который я привёл в первом сообщении хорошо видно, что прерывания обрабатываются обоими процессорами примерно поровну. То есть задел по мощности ещё есть. Впрочем заглянул я сюда не зря - только что выяснил интересный факт, при одной и той же нагрузке сраненький Pentium D 3.4GHz с включеным гипертредингом усирается чуть больше, чем навороченный двухголовый двухядерный Xeon L5420 2.50GHz. Единственное в них отличие - в D стоит Intel 82573V, а в Xeon - Broadcom BCM5708. Что кагбэ намекает. Но полностью уверенности пока нет.
  13. Упорно и долго ползал по всему интернету, включая nag.ru, но ответа не нашёл. Итак: 1. PPPoE NAS - Gentoo 2.6.19 (кое-где 23, но сути к сожалению не меняет) на совершенно различных аппаратных конфигурациях, в основном Dell R200 на Intel® Pentium® Dual CPU E2180 @ 2.00GHz, 1Gb RAM. 2. Сетевые карты соответственно где какие - модификации Broadcom, Intel 1000, но все гигабитные. В разной степени подвержены тюнингу с помощью ethtool, но опять же на проблему тюнинг даже самой крутой интеловской карточки никак не влияет. 3. На NAS клиенты шейпятся по направлениям (городской трафик быстрее раз в 10 нежели по основному тарифному плану). 4. Шейпинг исходящего трафика сделан на интерфейсе аплинка, впрочем его отключение так же картину не меняет. Собственно картина такова: при количестве ppp интерфейсов примерно так от 500 (зависит от процессора) у клиентов (у всех, вне зависимости от шейпера - хоть 100Мбит) начинаются потери пакетов. 500 клиентов соответствуют примерно 50Kpps (при 300Mbit), думаю для таких аппаратов это совсем не предел, а по факту - загрузка CPU 50% (тобишь один CPU занимается чисто сетью), всё в softirq, userspace ~ 0%. tts-2 ~ # cat /proc/interrupts CPU0 CPU1 0: 84547943 451 IO-APIC-edge timer 1: 2 0 IO-APIC-edge i8042 8: 4 1 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 12: 0 4 IO-APIC-edge i8042 18: 71 11 IO-APIC-fasteoi libata 19: 10441 21 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb4 20: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 219: 2008095683 2050353622 PCI-MSI-edge eth0 NMI: 84548339 84548306 LOC: 451 84547856 ERR: 0 MIS: 0 Типичный шейпер на одном из клиентов: tts-2 ~ # tc qdisc ls dev ppp609 qdisc htb 1: root r2q 10 default 1 direct_packets_stat 13 qdisc sfq b85b: parent 1:1 limit 127p quantum 1492b perturb 10sec qdisc sfq b85c: parent 1:2 limit 127p quantum 1492b perturb 10sec tts-2 ~ # tc class ls dev ppp609 class htb 1: root rate 100000Kbit ceil 100000Kbit burst 51787b cburst 51787b class htb 1:1 parent 1: leaf b85b: prio 0 rate 880000bit ceil 880000bit burst 2Kb cburst 2Kb class htb 1:2 parent 1: leaf b85c: prio 0 rate 880000bit ceil 880000bit burst 2Kb cburst 2Kb tts-2 ~ # tc filter ls dev ppp609 filter parent 1: protocol ip pref 5 u32 filter parent 1: protocol ip pref 5 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 5 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:2 match d594a200/fffffe00 at 12 filter parent 1: protocol ip pref 5 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:2 match d594a000/ffffff80 at 12 Если что не упомянул - извините, уточню, голова уже пухнет - это только одна из нескольких висящих проблем.