-
Публикации
41 -
Зарегистрирован
-
Посещение
Все публикации пользователя dadv
-
FreeBSD_10 не работает драйвер без ipv6
тему ответил в No_name пользователя dadv в Программное обеспечение, биллинг и *unix системы
Официально не поддерживается пересборка ядра без пересборки ядерных модулей как раз вот из-за таких штук: опции сборки ядра могут сделать бинарно несовместимым его со старыми модулями. Поможет пересборка модуля с WITHOUT_INET6. -
Виснет MPD
тему ответил в conrad пользователя dadv в Программное обеспечение, биллинг и *unix системы
Проблема зависания mpd5 официально считается решенной. Для получения всех фиксов нужно обновиться до 10.3-STABLE или 11.1-RELEASE или 11.1-STABLE и обновить порт до mpd5-5.8_1 или новее. Если кому интересны технические детали, они есть тут: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186114 -
прошивка и восстановление DMM-1500P-44T2
тему ответил в chopsuey12 пользователя dadv в PBI
Обошелся этим 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 по официальной инструкции. Вопрос снят. -
прошивка и восстановление DMM-1500P-44T2
тему ответил в chopsuey12 пользователя dadv в PBI
Удалось прошить - выполнить 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. -
прошивка и восстановление DMM-1500P-44T2
тему ответил в chopsuey12 пользователя dadv в PBI
Попробовал восстановить прошивку, воспользовавшись 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 -
прошивка и восстановление DMM-1500P-44T2
тему ответил в chopsuey12 пользователя dadv в PBI
Дополню вопрос коллеги 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. -
Freebsd lagg
тему ответил в nearia пользователя dadv в Программное обеспечение, биллинг и *unix системы
flowid_shift это решение другой проблемы, топик-стартеру это не поможет. -
Freebsd lagg
тему ответил в nearia пользователя dadv в Программное обеспечение, биллинг и *unix системы
http://dadv.livejournal.com/139170.html#lagg http://dadv.livejournal.com/161010.html -
freebsd NAT
тему ответил в doubtpoint пользователя dadv в Активное оборудование Ethernet, IP, MPLS, SDN/NFV...
Ни на что не намекаю. Просто уточнил, что это skipto ничего кардинально изменить и не мог. -
freebsd NAT
тему ответил в doubtpoint пользователя dadv в Активное оборудование Ethernet, IP, MPLS, SDN/NFV...
Этот skipto не отменяет поиска по таблицам в правилах 1300 и 41000. -
freebsd NAT
тему ответил в doubtpoint пользователя dadv в Активное оборудование Ethernet, IP, MPLS, SDN/NFV...
Функции rn_match и ipfw_chk, которые у вас в топе при профилировании это и есть поиск по таблицам ipfw, как и _rw_rlock. rn_match делает непосредственное сравнивание, а цепочка вызовов выглядит примеро так: ip_output > pfil_run_hooks > ipfw_check_hook > ipfw_chk > ipfw_lookup_table > rn_match > ... Делайте выводы. -
freebsd NAT
тему ответил в doubtpoint пользователя dadv в Активное оборудование Ethernet, IP, MPLS, SDN/NFV...
Ещё один труднонаходимый источник проблем это dummynet, который не параллелится. Почитайте тут: http://forum.nag.ru/forum/index.php?showtopic=82298&view=findpost&p=810794 -
freebsd NAT
тему ответил в doubtpoint пользователя dadv в Активное оборудование Ethernet, IP, MPLS, SDN/NFV...
У нас нет 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 -
Freebsd 9. LACP. Периодически недоступны интерфейсы lagg
тему ответил в ApmeM пользователя dadv в Программное обеспечение, биллинг и *unix системы
IPMI используется? Если да, тогда вам сюда: http://dadv.livejournal.com/173258.html -
FreeBSD + 10 Gbit ixgbe + dummynet
тему ответил в John_obn пользователя dadv в Программное обеспечение, биллинг и *unix системы
Могу добавить только одно - пробуйте -
FreeBSD + 10 Gbit ixgbe + dummynet
тему ответил в John_obn пользователя dadv в Программное обеспечение, биллинг и *unix системы
У вас будет всё плохо, пока вы не удалите pf из ядра полностью. Дело в том, что в восьмерке pf использует глобальную блокировку для всего трафика, при этом обрабатывает трафик в один поток. Поэтому в ядре возникает lock contention, когда другие подсистемы вместо полезной работы начинают драться за право захватить блокировку. pf работает в контексте обработчика прерывания сетевой карты, поэтому, как и ipfw, не виден в top. Не откажетесь от pf полностью - лучше вам не станет. -
FreeBSD + 10 Gbit ixgbe + dummynet
тему ответил в John_obn пользователя dadv в Программное обеспечение, биллинг и *unix системы
Вам нужно не процессоры тасовать, а добиваться равномерной загрузки ядер системы, то есть решать архитектурную проблему. У вас большинство из них вполовину простаивает. -
FreeBSD + 10 Gbit ixgbe + dummynet
тему ответил в John_obn пользователя dadv в Программное обеспечение, биллинг и *unix системы
Если запускать команду от рута, то корректно ровно так же, зато более производительно :-) -
FreeBSD + 10 Gbit ixgbe + dummynet
тему ответил в John_obn пользователя dadv в Программное обеспечение, биллинг и *unix системы
Начнём с того, что показаниям 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. -
soft-router 36ГБит/с 4,3Мпакетов UPD: 9mpps
тему ответил в dmvy пользователя dadv в Активное оборудование Ethernet, IP, MPLS, SDN/NFV...
Я не использовал ng_netflow. Разница с ng_ipacct ещё и в том, что netflow сам решает, когда ему очищать статистику, а для ng_ipacct нужен cron job для этого и если снимать статистику из ядра часто (раз в 5 минут например, а агрегировать её уже потом в userland), то таблицы в ядре будут небольшими и поиск по ним (для увеличения нужного счетчика) быстрым. -
soft-router 36ГБит/с 4,3Мпакетов UPD: 9mpps
тему ответил в dmvy пользователя dadv в Активное оборудование Ethernet, IP, MPLS, SDN/NFV...
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. Дока и куча примеров в комплекте. -
Маразм крепчает
тему ответил в yxzz пользователя dadv в Обсуждение контента портала Nag.Ru
Наверное, остальные странички потерялись? На этой не вижу предложения закрывать. -
NAS на FreeBSD 9.0. Тестирование под нагрузкой.
тему ответил в kaN5300 пользователя dadv в Программное обеспечение, биллинг и *unix системы
Полная чушь. Никакого прохода ни по какому списку интерфейсов в этом случае не выполняется (да и не за чем). Буквально выполняется сравнение первых двух символов имени интерфейса пакета с 'n' и 'g'. -
Dummynet Tuning
тему ответил в Hawk128 пользователя dadv в Программное обеспечение, биллинг и *unix системы
Откуда данные? Я сейчас почитал код ядра. ipfw при проверке 'ng*' зовёт ядерную версию fnmatch(pattern, string, flags), которая написана крайне оптимально и в этом случае просто сравнит первые два символа имени интерфейса пакета с 'n' и 'g' и потом сделает return 0 в случае совпадения. Никаких регекспов, никакого роста времени исполнения при увеличении количества интерфейсов. В 8.2-STABLE. -
NAS на FreeBSD 9.0. Тестирование под нагрузкой.
тему ответил в kaN5300 пользователя dadv в Программное обеспечение, биллинг и *unix системы
Почему именно 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 сессях.