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

dadv

Пользователи
 Просмотреть профиль  Активность

  • Публикации

    41

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

  • Посещение

 Тип публикации 

Сообщения, опубликованные пользователем dadv

  1. Опубликовано · Жалоба на ответ

    Официально не поддерживается пересборка ядра без пересборки ядерных модулей как раз вот из-за таких штук: опции сборки ядра могут сделать бинарно несовместимым его со старыми модулями.

     

    Поможет пересборка модуля с WITHOUT_INET6.

  2. Опубликовано · Жалоба на ответ

    Проблема зависания mpd5 официально считается решенной. Для получения всех фиксов нужно обновиться до 10.3-STABLE или 11.1-RELEASE или 11.1-STABLE и обновить порт до mpd5-5.8_1 или новее. Если кому интересны технические детали, они есть тут: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186114

  3. Опубликовано · Жалоба на ответ

    Обошелся этим uboot recovery для 5000P: зашел через telnet на живую плату 1500P, скопировал /bin/upgrade в /ramdisk, по ftp скачал этот бинарник upgrade с живой платы, по ftp опять же загрузил этот upgrade на проблемную плату после выполнения uboot recovery прошивкой от 5000P и убийства процесса pbi плюс загрузил туда же target1.cod от прошивки 15PR002C и с консоли запустил /ramdisk/upgrade. Оно успешно прошило target1.cod, перезагрузило плату и потом уже штатным образом прошил оставшиеся target2.cod и target3.cod по официальной инструкции.

     

    Вопрос снят.

  4. Опубликовано · Изменено пользователем dadv · Жалоба на ответ

    Удалось прошить - выполнить uboot recovery через http://data.nag.ru/PBI/Recovery/5000P%20upgarde.rar, после чего плата загрузилась и подняла прежний IP-адрес, можно зайти на неё по telnet и по ftp. Но эта прошивка для 5000P всё-таки не подходит для 1500P - в ней нет web-интерфейса и команда upgrade в ней не может корректно прошить файлы target[123].cod от 1500P.

     

    Всё ещё нужен правильный uboot recovery для 1500P.

  5. Опубликовано · Жалоба на ответ

    Попробовал восстановить прошивку, воспользовавшись uboot_recovery.zip с файлами и инструкцией для 1400P. Теперь загрузчик больше не ругается на Bad Magic Number и начинает грузить прошивку и успешно стартует ядро Linux. Но так как прошивка всё-таки для немного другой железки, то она тоже не грузится до конца, ругаясь "load parameter error" и вываливаясь в shell, где не принимает ни одной команды и даже ругань выдаёт битую, типа такого: "so s!ch eile!or eirestor" вмеcто "No such file or directory".

     

    Очень нужен uboot_recovery для DMM-1500P

  6. Опубликовано · Изменено пользователем dadv · Жалоба на ответ

    Дополню вопрос коллеги chopsuey12. На самом деле проблема в запоротой прошивке, так как U-Boot теперь ругается так в свой консольный порт на этой железке:

     

    U-Boot 1.1.3 (Nov 29 2006 - 08:31:49)

     

    U-Boot code: 007D0000 -> 007E76B0 BSS: -> 007F1B08

    IRQ Stack: 007aef7c

    FIQ Stack: 007adf7c

    RAM Configuration:

    Bank #0: 00000000 16 MB

    Flash: 8 MB

    In: serial

    Out: serial

    Err: serial

    Hit any key to stop autoboot: 0

    ## Booting image at 01030000 ...

    Bad Magic Number

    # iminfo

     

    ## Checking Image at 00000000 ...

    Bad Magic Number

    DCH-4000P # imls

    DCH-4000P #

    DCH-4000P # help tftp

    tftpboot [loadAddress] [bootfilename]

     

    Сам U-Boot не поврежден и может пинговать наш tftp-сервер. Весь вопрос теперь в том, где взять корректный loadAddress для команды tftpboot и аргументы для команд erase и cp.b, чтобы восстановить прошивку через U-Boot.

  8. Опубликовано · Изменено пользователем dadv · Жалоба на ответ

    Имеется несколько Nas серверов разных конфигураций с системой Freebsd 10.1 и Freebsd 9.2 на всех собрано по 2 lagg интерфейса, первый лаг смотрит в cisco 3750, и везде наблюдается одна и та же проблема с балансировкой трафика между интерфейсами.

     

    http://dadv.livejournal.com/139170.html#lagg

    http://dadv.livejournal.com/161010.html

  11. Опубликовано · Жалоба на ответ

    Функции rn_match и ipfw_chk, которые у вас в топе при профилировании это и есть поиск по таблицам ipfw, как и _rw_rlock. rn_match делает непосредственное сравнивание, а цепочка вызовов выглядит примеро так:

     

    ip_output > pfil_run_hooks > ipfw_check_hook > ipfw_chk > ipfw_lookup_table > rn_match > ...

     

    Делайте выводы.

  13. Опубликовано · Жалоба на ответ

    У нас нет NAT под такой нагрузкой, но несколько замечаний общего плана всё-таки дам.

     

    1. В ipfw операция поиска по таблице ДОРОГАЯ. Старайтесь по возможности делать таблицы поменьше и по таким правилам не прогонять пакеты, которые заведомо не предназначены для этих правил.

    2. Количество инстансов ipfw nat лучше всего сделать равным количеству физических ядер системы, как и количество тредов драйвера сетевой карты - для уменьшения lock contention, что и приводит к нелинейному росту загрузки процессора за счет ненужного оверхеда.

    3. Обновите систему до STABLE, в интелевских драйверах были нужные обновления.

    4. Прочитайте главу в Handbook про DTRace: http://www.freebsd.org/doc/handbook/dtrace.html

    Не пренебрегайте этим замечательным инструментом, он в неактивированном состоянии практически не сказывается на производительности системы. Прогоните профилирование хотя бы в течение пары минут в час наибольшей нагрузки, как написано в Handbook - узнаете, куда копать надо именно вам.

    5. Почитайте Черникова: http://lists.freebsd.org/pipermail/freebsd-hackers/2012-July/039640.html

  16. Опубликовано · Жалоба на ответ

    Отключение гипертрединга не помогло. Подскажите, пожалуйста, что еще можно подкрутить?

     

    У вас будет всё плохо, пока вы не удалите pf из ядра полностью.

    Дело в том, что в восьмерке pf использует глобальную блокировку для всего трафика,

    при этом обрабатывает трафик в один поток. Поэтому в ядре возникает lock contention,

    когда другие подсистемы вместо полезной работы начинают драться за право захватить блокировку.

     

    pf работает в контексте обработчика прерывания сетевой карты, поэтому, как и ipfw, не виден в top.

    Не откажетесь от pf полностью - лучше вам не станет.

  17. Опубликовано · Жалоба на ответ

    Отключение гипертрединга не помогло. Подскажите, пожалуйста, что еще можно подкрутить?

    Буду разгружать этот роутер, и выбирать процессор. Сначала хотел i7-3970X , но в мануале к материнской плате supermicro X9SRi-F пишут, что только E5-2600/E5-1600. Из E5-2600 серии процессоров с частотой больше 3 ГГц не нашлось (либо дорого), видимо придется искать E5-1600 серию, только что то их на там же n i x.ru нет.

     

    Вам нужно не процессоры тасовать, а добиваться равномерной загрузки ядер системы, то есть решать архитектурную проблему. У вас большинство из них вполовину простаивает.

  19. Опубликовано · Изменено пользователем dadv · Жалоба на ответ

    Начнём с того, что показаниям top в отношениии dummynet верить нельзя. Вообще от слова совсем. Он почему-то показывает погоду на Марсе, а не потребление процессора dummynet'ом.

     

    Корректный способ мониторить потребление процессора ядерным тредом dummynet это смотреть на его монотонно возрастающий ядерный счетчик accumulated CPU time. Следующая команда выдаёт его значение в сотых долях секунды. Его можно рисовать на графике хоть mrtg, хоть чем.

     

    export LC_ALL=C

    ps -Hxo time,lwp | awk -vT=$(procstat -t 0 | awk '/dummynet/ {print $2}')\

    ' $2 == T { split($1, a, /[:.]/); print a[1]*6000+a[2]*100+a[3]; }

     

    Лично я отдаю это значение как есть по SNMP и рисую его тоже "как есть" на графике, при привязке к одному ядру CPU на графике получается процентная загрузка этого ядра тредом dummynet.

  20. Опубликовано · Жалоба на ответ

    Вы замечали выигрыш в производительность по сравнению с ng_netflow ?

     

    Я не использовал ng_netflow. Разница с ng_ipacct ещё и в том, что netflow сам решает, когда ему очищать статистику, а для ng_ipacct нужен cron job для этого и если снимать статистику из ядра часто (раз в 5 минут например, а агрегировать её уже потом в userland), то таблицы в ядре будут небольшими и поиск по ним (для увеличения нужного счетчика) быстрым.

  21. Опубликовано · Жалоба на ответ

    Подскажите кто-то во FreeBSD что-то для аккаунтинга. Сейчас ng_netflow, но мне не требуется детальная статистика. Мне достаточно каунтить количество байт ин/аут по каждому IP и возможность это все экспортировать на удаленный сервер.

    Ибо оверхед большой.

     

    ng_ipacct в портах даёт аналог cisco ip accounting:

     

    ipacctctl ... checkpoint # создать снапшот насчитанной статистики в памяти ядра с началом обсчета заново

    ipacctctl ... show > log # вывести снапшот из памяти ядра в файл

    ipacctctl ... clear # удалить снапшот

     

    Полученный log - текстовый структурированный файл, можно обрабатывать чем угодно вплоть до прямой загрузки в MySQL через mysqlimport.

    Два формата выводимых данных: ip_from ip_to packets bytes либо ip_from s_port ip_to d_port proto packets bytes.

     

    Дока и куча примеров в комплекте.

  23. Опубликовано · Жалоба на ответ

    Правда, говорят что "via ng*" может быть даже хуже по производительности, чем отсутствия указания - как-то там "не так" ipfw проходит по списку интерфейсов.

     

    Полная чушь. Никакого прохода ни по какому списку интерфейсов в этом случае не выполняется (да и не за чем). Буквально выполняется сравнение первых двух символов имени интерфейса пакета с 'n' и 'g'.

  24. Опубликовано · Жалоба на ответ

    само наличие * в правиле будет тормозить. Задавать правила по другому. или просто out или еще как. но без *.

     

    Откуда данные? Я сейчас почитал код ядра. ipfw при проверке 'ng*' зовёт ядерную версию fnmatch(pattern, string, flags), которая написана крайне оптимально и в этом случае просто сравнит первые два символа имени интерфейса пакета с 'n' и 'g' и потом сделает return 0 в случае совпадения. Никаких регекспов, никакого роста времени исполнения при увеличении количества интерфейсов. В 8.2-STABLE.

  25. Опубликовано · Жалоба на ответ

    И всё же - можно где-то узнать "происхождение" этих параметров?

    net.graph.maxdgram=8388608

    net.graph.recvspace=8388608

    kern.ipc.maxsockbuf=83886080

    Почему именно 8 388 608 (8 Мб??) и 83 886 080 (80 Мб??)

    И есть ли какое-то соотношение между значением net.graph.maxdgram и kern.ipc.maxsockbuf? Связаны ли эти параметры с размером памяти?

     

    Это параметры из моей статьи. Они прекрасно работают у меня на 4G памяти и amd64 (использовать i386 для таких задач - нарываться на неприятности, даже если памяти меньше 4G). kern.ipc.maxsockbuf влияет, в частности, на работу команды ngctl list, которой очень удобно снимать количество подключенных сессий (она отрабатывает на порядок быстрее чем ifconfig). Но ngctl list при большом количестве сессий вместо результата выдавало у меня ошибку даже после нескольких удвоений дефолта, вплоть до 8M. Тогда, обозлившись, я удесятерил - и ngctl list заработал. Это было при более чем 1500 сессях.