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

ibmed

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

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

  • Посещение

Все публикации пользователя ibmed


  1. Настройки абсолютно идентичны. Меняется только логин/пароль в pppoe.
  2. Замеряли разными устройствами (мобильники, ноут). В основном через speedtest. Пробовали iperf: результаты очень похожи. Про загруженность каналов - если речь про вайфай - тоже, разумеется, была гипотеза. Но я не понимаю, почему роутер, подключенный в гиговый порт, выдает 160. А сразу же переключенный в 100Мбит, выдает лишь 75-80. Мое скромное понимание процесса подсказывает мне, что если уж он умеет отдавать 160, значит проблема все же не в загруженности каналов.
  3. Столкнулись с интересной историей: В нашей сети замер скорости через 2.4 на роутере, подключенном к 100Мбит порту коммутатора выдает в среднем 75-80Мбит/с. При этом подключение кабелем стабильно показывает 95-99Мбит/с. И мы, честно говоря, были уверены, что это совершенно нормальные результаты. До тех пор пока не начали слышать, что мол у другого оператора тот же самый роутер выдает 90+ Мбит/с через 2.4. Собрали тестовый стенд. Прогнали серию замеров, меняя модели роутеров (Netis WF2780, TP-Link 841, Mikrotik RB962), тип подключения к интернет (pppoe/nat/напрямую), модель коммутатора, способ замера. Результаты стабильно сводятся к нашим стандартным 75-80Мбит/с через 2.4 и почти 100Мбит/с через шнурок. Из интересного: - Если подключить роутер к гигабитному порту, то 2.4 начинает отдавать ~160Мбит/с. То есть получается, что 2.4 может выдать и больше 80, но не выдает скорость, доступную на кабеле. - Если роутер подключить к гигабитному порту, но зашейпить его на 100Мбит/с, то 2.4 выдает полноценные 100Мбит/с. Однако у других операторов - якобы - 90+ наблюдается и при подключении в 100Мбит порт. Чего мы не знаем и упускаем из виду?
  4. Умник О как :) На самом деле я, конечно, ожидал хороших результатов, имея опыт с успешно работавшим линукс-бордером на относительно слабом железе и предыдущем ядре. А тут такая штука. Теперь надо попробовать адекватную синтетику сделать и поиграться с шейпером под htb. А вообще мы приняли политическое решение переезжать на аппартный бордер :)
  5. Умник Не успел. На тот момент, когда проблема вылезала, этого сделано не было. Я так понял, его можно задавать после установки irqbalance-а. Но когда я до этого дочитался, трафика уже не было толком и было принято политическое решение возвращаться на фрю. Вообще удивительно, конечно. Ибо предыдущий линукс-бордер жил достаточно хорошо (с выкомпиленным файрволом и е1000е-NAPI) и прокачивал явно больше, чем то, где загнулась более свежая машина, которая выигрывает как по железу, так и по новому ядру.
  6. посмотрел на машинку, такого файлика в /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 (это сейчас с пустой машины) теперь только в синтетике можно будет посмотреть
  7. conntrack я из ядра убирал в том числе машинку сейчас уже снял, не могу заглянуть в боевом режиме :(
  8. Wingman Как же ж так? :) Неужели действительно должно помочь? Я в свое время специально эксперименты ставил по прокачиванию трафика через машинку. И линукс, и фря показали лучшие показатели именно с выкомпиленным файрволом. Т.е. пустой файрвол давал одну цифру, а выключенный в ядре в принципе давал еще лучше цифру. Поэтому меня сие, конечно, удивляет :) Этому есть какое-то разуменое объяснение?
  9. Ага, пробовал и с этим драйвером. Ни шейперов, ни ната. Файрвол выкомпилен из ядра вообще. Только маршрутизация. Успел даже поплясать вокруг параметров драйвера таких как интеррапттротл и иже с ним. Все одно. Как pps под 500k - вылезают эти грешные ksoftirqd. И никто главное не пишет, как это лечить :) В итоге вернулся на фрю. Теперь надо подумать, чем можно адекватную синтетику по pps сделать, чтобы проверить.
  10. 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 (и какая версия драйвера?). Перерыл интернет, не могу найти ничего про это. Как посмотреть, есть ли оно?
  11. Abram В саму Кваггу маршруты приезжают быстро. Оно их в кернел не добавляет по какой-то причине.. Точнее даже не так. Сейчас через консоли смотрю маршруты: ospfd маршруты быстро получает zebra маршрутов от оспфд не видит
  12. Наступил на неожиданные грабли: Linux (ubuntu 9.10) amd64. Bond0 mode4. На bond0 поднимается ospfd (из состава quagga 0.99.13). Итог: маршруты оспфд получает нормально (это я вижу через vty), но в таблицу маршрутизации не складывает в течение примерно 10 минут. Если тот же самый оспф поднять на совершенно отдельном от бонда интерфейсе - все работает как и должно. Дебажный лог, отпарсенный по буквосочетаниям "err" и "warn" ничего не выдает.. Кто-то сталкивался?..
  13. А я приношу публичную клятву отписаться об успехах в репродукции бордера на линуксе :)
  14. Wingman Спасибо за наводки. Топики уже читаю. Не затруднит ли Вас поделиться конфигом ядра и прочими тюнингами от вашей success-story? :)
  15. Wingman О как.. Получается, линукс и здесь фрю делает.. "Обидно, Вань" (с) :)
  16. Wingman А не покажете суммарное количество pps по интерфейсам в ЧНН?
  17. Простите, и я вклинюсь: На что железное можно поглядеть, держащее до 3Гбит/с (сейчас 1.3Гбит с почти 1Mpps) с BGP на двух-четырех линках (каждый с full-view)? Кроме БГП ничего не нужно.
  18. Сегодня переехали на новое железо и фрю. Однако.. CPU: Intel® Xeon® CPU E5420 @ 2.50GHz (2506.23-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLU SH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x40ce3bd<SSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,<b19>,XSAVE> AMD Features=0x20100800<SYSCALL,NX,LM> AMD Features2=0x1<LAHF> Cores per package: 4 usable memory = 8576208896 (8178 MB) avail memory = 8250183680 (7867 MB) ACPI APIC Table: <INTEL S5000PSL> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs 7.2-RELEASE-p7 amd64 Ядро - практически GENERIC, только убрано ненужное. 2 четырехголовых Интела (em) с последним драйвером от Яндекса (<Intel® PRO/1000 Network Connection 6.9.6.Yandex[$Revision: 1.36.2.17 $]>). По одному порту на два канала. 3 порта в lacp lagg в сторону локалки. bgp# cat /boot/loader.conf vm.kmem_size=3G hw.em.rxd=4096 hw.em.txd=4096 cat /etc/sysctl.conf: net.inet.ip.fastforwarding=1 sysctl -w dev.em.2.rx_int_delay=750 sysctl -w dev.em.2.tx_int_delay=750 sysctl -w dev.em.2.rx_abs_int_delay=1000 sysctl -w dev.em.2.tx_abs_int_delay=1000 sysctl -w dev.em.3.rx_int_delay=750 sysctl -w dev.em.3.tx_int_delay=750 sysctl -w dev.em.3.rx_abs_int_delay=1000 sysctl -w dev.em.3.tx_abs_int_delay=1000 sysctl -w dev.em.7.tx_int_delay=750 sysctl -w dev.em.7.rx_int_delay=750 sysctl -w dev.em.7.rx_abs_int_delay=1000 sysctl -w dev.em.7.tx_abs_int_delay=1000 sysctl -w dev.em.8.tx_int_delay=750 sysctl -w dev.em.8.rx_int_delay=750 sysctl -w dev.em.8.rx_abs_int_delay=1000 sysctl -w dev.em.8.tx_abs_int_delay=1000 sysctl -w dev.em.9.tx_int_delay=750 sysctl -w dev.em.9.rx_int_delay=750 sysctl -w dev.em.9.rx_abs_int_delay=1000 sysctl -w dev.em.9.tx_abs_int_delay=1000 (Пробовал играться с этими показателями. Поначалу выставил все значения в 250 - нагрузка процов уже при 500kpps была порядка 50%. Поменял все значения на 500 - нагрузка мгновенно упала вдвое, без каких-либо дропов. Увеличение до 750 совсем чуть-чуть снизило нагрузку. Дальнейшее увеличение результатов не принесло и было оставлено в том виде, в котором приведено). bgp# netstat -w1 input (Total) output packets errs bytes packets errs bytes colls 850599 0 550159804 834747 0 521952924 0 850871 0 546076120 832834 0 518072008 0 861307 0 550636679 842033 0 522021955 0 860054 0 551806145 839254 0 522651924 0 858529 0 548114024 838182 0 519862948 0 864952 0 554527751 846750 0 525230852 0 855247 0 546161607 840761 0 519676813 0 (перемалывал и больше - под 1Mpp/s, почти совсем без дропов (200-500 пакетов на 950Кппс)) Но. Нагрузка по процам такая же как была на 4-ядерном железе под линуксом еще вчера. И это странно. last pid: 13429; load averages: 5.03, 4.97, 5.36 up 0+11:50:21 23:08:12 141 processes: 12 running, 115 sleeping, 14 waiting CPU 0: 0.0% user, 0.0% nice, 65.2% system, 0.0% interrupt, 34.8% idle CPU 1: 0.4% user, 0.0% nice, 65.0% system, 0.0% interrupt, 34.6% idle CPU 2: 0.0% user, 0.0% nice, 55.3% system, 0.0% interrupt, 44.7% idle CPU 3: 0.0% user, 0.0% nice, 57.1% system, 0.0% interrupt, 42.9% idle CPU 4: 0.0% user, 0.0% nice, 53.2% system, 0.0% interrupt, 46.8% idle CPU 5: 0.0% user, 0.0% nice, 50.6% system, 0.0% interrupt, 49.4% idle CPU 6: 0.0% user, 0.0% nice, 49.1% system, 0.0% interrupt, 50.9% idle CPU 7: 0.0% user, 0.0% nice, 46.8% system, 0.0% interrupt, 53.2% idle Mem: 259M Active, 58M Inact, 302M Wired, 92K Cache, 21M Buf, 7273M Free Swap: 8192M Total, 8192M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 44 root 1 43 - 0K 16K CPU6 6 309:57 67.09% em3_rx_kthread_1 43 root 1 43 - 0K 16K CPU5 5 310:32 64.60% em3_rx_kthread_0 11 root 1 171 ki31 0K 16K CPU7 7 476:43 55.18% idle: cpu7 12 root 1 171 ki31 0K 16K RUN 6 472:29 51.86% idle: cpu6 13 root 1 171 ki31 0K 16K RUN 5 457:13 49.07% idle: cpu5 14 root 1 171 ki31 0K 16K CPU4 4 438:51 47.75% idle: cpu4 15 root 1 171 ki31 0K 16K CPU3 3 421:27 44.29% idle: cpu3 16 root 1 171 ki31 0K 16K CPU2 2 398:34 40.38% idle: cpu2 17 root 1 171 ki31 0K 16K CPU1 1 372:24 37.99% idle: cpu1 64 root 1 43 - 0K 16K WAIT 3 192:05 36.87% em8_rx_kthread_1 18 root 1 171 ki31 0K 16K RUN 0 356:56 36.67% idle: cpu0 63 root 1 43 - 0K 16K WAIT 3 192:23 34.08% em8_rx_kthread_0 60 root 1 43 - 0K 16K WAIT 4 192:10 33.50% em7_rx_kthread_1 42 root 1 -68 - 0K 16K CPU7 7 73:10 33.15% em3_txcleaner 59 root 1 43 - 0K 16K WAIT 4 192:23 32.18% em7_rx_kthread_0 39 root 1 43 - 0K 16K WAIT 1 197:14 31.79% em2_rx_kthread_0 40 root 1 43 - 0K 16K WAIT 2 196:49 29.98% em2_rx_kthread_1 68 root 1 43 - 0K 16K WAIT 2 128:59 22.46% em9_rx_kthread_1 67 root 1 43 - 0K 16K WAIT 0 129:15 22.17% em9_rx_kthread_0 38 root 1 -68 - 0K 16K WAIT 6 51:37 18.36% em2_txcleaner 58 root 1 -68 - 0K 16K WAIT 0 27:35 11.96% em7_txcleaner 62 root 1 -68 - 0K 16K WAIT 0 27:40 11.08% em8_txcleaner 66 root 1 -68 - 0K 16K WAIT 3 27:07 10.50% em9_txcleaner 4753 root 1 44 0 179M 172M select 1 3:46 0.00% bgpd Я ожидал увидеть как минимум 25% снижение нагрузки по графикам. В ближайшее время, возможно, попробую собрать конфигурацию на том же железе, что сейчас с фрей, но под линуксом. Если кто-то может поделиться советами по тюнингу линукса в контекст высокопроизводительного роутера - буду признателен.
  19. [GP]Villi Не совсем так. На данный момент наиболее правильной схемой в сценарии с двумя БГП мне кажется что-то вроде: БГП1 =\_/= Шейпер1 БГП2 =/ \= Шейпер2 Оба БГП при этом будут отдавать по ОСПФ свой фулл-вью, а Шейперы на сетевых, смотрящих в сторону НАСов будут собраны в CARP, чтобы у насов оставался один единственный дефолт, и фулл-вью дальше шейперов не выходил. Таким образом лучше обеспечивается отказоустойчивость (БГП упал, анонсы в оспф перестали, маршруты прозрачно построились через живой бгп). Почему не бриджом? Ну во-первых, наверное, я просто не знал, насколько хорошо бридж справляется с нагрузкой против роутера (хорошо?). Во-вторых, в приведенной схеме при использовании Шейпов как бриджей придется-таки рассказывать НАСам про фулл-вью, либо изобретать что-то другое (С iBGP, честно, никогда не игрался и пока не умею - возможно, оно там получается красивей, чем мне кажется? Поищу на почитать.). P.S> В данный момент я больше склоняюсь-таки к железячному сценарию развития. :)
  20. Да, с удовольствием - может кому-то будет полезно.БГП сейчас живет на дебиане, что происходит еще со времен, когда мы натили пользователей. Хотя фря мне куда милее, но на момент установки машинки, линукс НА ГОЛОВУ лучше натил, чем фря (сейчас не знаю - переехали на белые адреса). Машинка делает только bgp+ospf. Iptables выкомпилены из ядра. Суммарная емкость каналов: 1.5G Пользователей в чнн - примерно 3500-3800 Linux debian 2.6.30 #8 SMP Mon Jul 27 08:12:32 MSD 2009 i686 GNU/Linux Железо: model name : Intel® Core2 Quad CPU Q6600 @ 2.40GHz MemTotal: 3636324 kB 4х портовый Intel (e1000e: Intel® PRO/1000 Network Driver - 1.0.2.5-NAPI) Нагрузка: Time Int rKB/s wKB/s rPk/s wPk/s rAvs wAvs %Util Sat 23:24:48 bond0 5.48 519.7 275581 238518 0.02 2.23 0.00 3676.5 23:24:49 bond0 150136 136498 267778 235705 574.1 593.0 0.00 2085.1 23:24:50 bond0 145706 132029 263263 232181 566.7 582.3 0.00 0.00 23:24:51 bond0 145066 124750 261689 225558 567.7 566.3 0.00 4558.2 23:24:52 bond0 145468 129694 261564 227004 569.5 585.0 0.00 0.00 23:24:53 bond0 144394 131243 263996 230733 560.1 582.5 0.00 2571.8 23:24:54 bond0 144105 131382 263899 233221 559.2 576.9 0.00 0.00 23:24:55 bond0 148000 132686 267199 233429 567.2 582.1 0.00 0.00 при этом debian:~/nicstat-1.22# netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg bond0 1500 0 1752538785 0 23199120 0 1516900495 0 0 0 BMmRU (т.е. имеются RX-DRP) TOP: Tasks: 101 total, 1 running, 100 sleeping, 0 stopped, 0 zombie Cpu0 : 0.3%us, 0.3%sy, 0.0%ni, 45.7%id, 0.0%wa, 4.1%hi, 49.5%si, 0.0%st Cpu1 : 0.7%us, 0.0%sy, 0.0%ni, 41.6%id, 0.0%wa, 4.8%hi, 52.9%si, 0.0%st Cpu2 : 0.0%us, 0.0%sy, 0.0%ni, 47.0%id, 0.0%wa, 4.2%hi, 48.8%si, 0.0%st Cpu3 : 0.7%us, 0.0%sy, 0.0%ni, 53.7%id, 0.4%wa, 4.2%hi, 41.1%si, 0.0%st Mem: 3636324k total, 600032k used, 3036292k free, 91764k buffers Swap: 0k total, 0k used, 0k free, 184016k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 8 root 15 -5 0 0 0 S 4 0.0 3:33.85 ksoftirqd/2 6 root 15 -5 0 0 0 S 3 0.0 8:35.73 ksoftirqd/1 Что довольно странно: на данный момент машинка примерно на 50% в idle, однако уже второй день вижу потери пакетов порядка 1-3% по пингу на локальный интерфейс. Сие довольно странно, т.к. нагрузка бывало доходила и до 70%+ и оно жило. Возможно железо, возможно, что-то еще - пока не разобрался. В ближайшее время расширяем канал и добавляем скорости к анлимам, так что нагрузка еще возрастет. Под все это дело решил переехать на фрю. Кстати по нашим тестам в формате выкомпиленного файрвола и линк-агрегейшн фря давала большую скорость, чем линукс. Что-то еще забыл? :)
  21. Гм.А как исходящий трафик будет разделяться? Если не делать редистрибьют, то мы остаемся только с маршрутом по умолчанию на роутерах, смотрящих на БГП..
  22. Да не запинайте ногами ближнего своего :) ЧТО ЕСТЬ: Сейчас BGP-роутер один (debian+quagga) и, соответственно, более-менее нормально распределяет трафик между каналами и в нормальном режиме и когда один из каналов падает. Однако в пике загрузка по процессору уже подбирается к 70-75%. Следовательно, расширяя канал, я почти наверняка упрусь в потолок производительности. Внутри сети OSPF. Из БГП внутренней карточкой смотрит в сегмент, в который смотрят 10 NAS-ов (FreeBSD+mpd). Правда, планирую пересобрать это в формате БГП - 2 Шейпера - 10 НАСов. ЧЕГО ХОЧЕТСЯ: Понять, в какую сторону правильно плясать от этой печки: а) можно отапгрейдить железо и тем отодвинуть потолок на некоторое (возможно, достаточно длительное) время; б) уже сейчас разделить каналы на разные БГП-роутеры; Так вот, начав думать над конфигурацией о двух БГП, я пришел к неутешительному выводу, что пока не очень понимаю, как красиво реализовать эту схему. Что я не очень понимаю: 1) Очевидно, придется редистрибьютить фулл-вью бгп в оспф. Иначе как они узнают, через кого отдается оптимальный маршрут и через кого ходить, если канал падает. Но это сильно забьет таблицу маршрутов на НАСах, что не айс. Альтернатива: редистрибьютить маршруты только до двух шейперов, шейперы собрать в CARP, а для НАСов уже будет один единственный default. 2) Должны ли БГП-роутеры общаться между собой? И если да, то где об этом почитать? Прогуглив ничего особенно не нашел на предмет конфигураций с несколькими БГП. 3) Стоит ли вообще городить этот огород с отдельными машинками? Если кто-то уже успешно и красиво это реализовал, или знает как - поделитесь схемой, конфигом или ссылкой на почитать.. Пожааалуйста :)
  23. Не победили? У нас такая же ситуация. FreeBSD. dummynet. Входящий - все красиво. Исходящий - ниже, чем должен быть. Некрасиво лечится увеличением настроек bw на трубу процентов на 40..
  24. Нашел ветку про это. Нашел Вашу ссылку на файлик на рапиде. Но скачать уже не дает. Можно выложить куда-то еще?