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

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. прошивка и восстановление DMM-1500P-44T2

    Обошелся этим 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. прошивка и восстановление DMM-1500P-44T2

    Удалось прошить - выполнить 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. прошивка и восстановление DMM-1500P-44T2

    Попробовал восстановить прошивку, воспользовавшись 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. прошивка и восстановление DMM-1500P-44T2

    Дополню вопрос коллеги 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.
  7. flowid_shift это решение другой проблемы, топик-стартеру это не поможет.
  8. http://dadv.livejournal.com/139170.html#lagg http://dadv.livejournal.com/161010.html
  9. Ни на что не намекаю. Просто уточнил, что это skipto ничего кардинально изменить и не мог.
  10. Этот skipto не отменяет поиска по таблицам в правилах 1300 и 41000.
  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 > ... Делайте выводы.
  12. Ещё один труднонаходимый источник проблем это dummynet, который не параллелится. Почитайте тут: http://forum.nag.ru/forum/index.php?showtopic=82298&view=findpost&p=810794
  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
  14. IPMI используется? Если да, тогда вам сюда: http://dadv.livejournal.com/173258.html
  15. Могу добавить только одно - пробуйте
  16. У вас будет всё плохо, пока вы не удалите pf из ядра полностью. Дело в том, что в восьмерке pf использует глобальную блокировку для всего трафика, при этом обрабатывает трафик в один поток. Поэтому в ядре возникает lock contention, когда другие подсистемы вместо полезной работы начинают драться за право захватить блокировку. pf работает в контексте обработчика прерывания сетевой карты, поэтому, как и ipfw, не виден в top. Не откажетесь от pf полностью - лучше вам не станет.
  17. Вам нужно не процессоры тасовать, а добиваться равномерной загрузки ядер системы, то есть решать архитектурную проблему. У вас большинство из них вполовину простаивает.
  18. Если запускать команду от рута, то корректно ровно так же, зато более производительно :-)
  19. Начнём с того, что показаниям 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_ipacct ещё и в том, что netflow сам решает, когда ему очищать статистику, а для ng_ipacct нужен cron job для этого и если снимать статистику из ядра часто (раз в 5 минут например, а агрегировать её уже потом в userland), то таблицы в ядре будут небольшими и поиск по ним (для увеличения нужного счетчика) быстрым.
  21. 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. Дока и куча примеров в комплекте.
  22. Наверное, остальные странички потерялись? На этой не вижу предложения закрывать.
  23. Полная чушь. Никакого прохода ни по какому списку интерфейсов в этом случае не выполняется (да и не за чем). Буквально выполняется сравнение первых двух символов имени интерфейса пакета с 'n' и 'g'.
  24. Откуда данные? Я сейчас почитал код ядра. ipfw при проверке 'ng*' зовёт ядерную версию fnmatch(pattern, string, flags), которая написана крайне оптимально и в этом случае просто сравнит первые два символа имени интерфейса пакета с 'n' и 'g' и потом сделает return 0 в случае совпадения. Никаких регекспов, никакого роста времени исполнения при увеличении количества интерфейсов. В 8.2-STABLE.
  25. Почему именно 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 сессях.