kaN5300

Начинает тупить сразу с момента загрузки или спустя какое-то время?

Куплю PA /22 Telegram: @Molokanov molokanov@iifrf.ru

Я всё никак не пог понять почему не получается посчитать число трансляций: ipfw: Error getting nat 1 instance info: No such file or directory Оказалось, директива log в config инстанса подразумевает собой саму возможность опроса командой sudo ipfw nat show log. Теперь можно в кактус выдать по каждому инстунсу tcp/udp/other/total.

This. Сам по себе РКН вряд ли читает, а вот какие-нибудь их аутсорсеры 100%.

Адназначна! Вторая попытка в течение нескольких секунд добивается результата!: 2014-01-31 16:42:36 LastDumpDate is not updated, nothing to do 2014-01-31 16:45:27 Service description 'http://vigruzki.rkn.gov.ru/services/OperatorRequest/?wsdl' can't be loaded: 500 write failed: Соединение разорвано другой стороной 2014-01-31 16:45:35 Got new archive 2014-01-31 17:37:05 Service description 'http://vigruzki.rkn.gov.ru/services/OperatorRequest/?wsdl' can't be loaded: 500 Status read failed: Соединение разорвано другой стороной 2014-01-31 17:37:12 got new LastDumpDate version 1391166310000, try send request 2014-01-31 17:40:04 Service description 'http://vigruzki.rkn.gov.ru/services/OperatorRequest/?wsdl' can't be loaded: 500 Status read failed: Соединение разорвано другой стороной 2014-01-31 17:40:12 Got new archive И вы еще сомневаетесь, что ЭТО будет глючить, помирать и лагать??? Подтверждаю проблему. Я искал причину в SOAP-Lite, но потом понял что даже через links с сервера не пускает по тайм-ауту (ошибка 500). Удаётся пролезть раза с десятого.

Заметен ли какой-либо профит от использования I350? Хотим начать их ставит вместо 82576 (сервера доступа на FreeBSD 9.X)/

Kirush, проблема больше не проявляется?

Невозможно будет каждый процессор забить на 100%. К тому же lavg это такой абстрактный параметр, с единой интерпретацией которого даже гуру не могут определиться: http://www.teamquest.com/pdfs/whitepaper/ldavg1.pdf Экспериментальным путём я выяснил что при увеличении значения load average 15m больше 3.0 на многопроцессорном (многоядерном) сервер доступа начинаются явные проблемы. По этому стараюсь выводить такие сервера из DNS до восстановления этих значений в норму. Еще заметил что порой может рандомно на каком-то из насов lavg резко взлететь до 40 например и в таком состоянии сервер будет находиться минут 20. Такое бывает очень редко. Раз в месяц примерно. Возможно связано с нетипичным трафиком с зараженного компа.

Отказаться от планировщика выключив гипер-трединг и прибив процессы к ядрам как вариант. Но с другой стороны у нас насы с сервисами all-in-one тащат по 40-50 kpps в ЧНН с дефолтным шедулером из 9.0 и четырьмя ядрами.

Подозреваю что rate-limit меньше требователен к ресурсам в отличие от shape. Мы применяли shape во времена тарифов по 128k. Потом перешли на limit. На самом последнем насе у нас по всем счётчикам vmstat только в одном месте есть отклонение счетчика фейлов (128 Bucket: 22135). Остальные все нули. Попробуй по библии dadv'а сделать: net.graph.maxdata=65536 net.graph.maxalloc=65536

1) На проблемном сервере после резкого увеличения lavg выполнить "vmstat -z|grep items" 2) Шейпирование реализовано через shape или rate-limit? 3) hyper-threading я бы отключил

Братюнь, попробуй вот так: /usr/local/bin/openssl pkcs12 -in p12.pfx -out provider.pem -nodes -clcerts

freebsd. что я делаю не так ?# xml sel -T -t -m "reg:register/content" -v "concat(ip,';',url)" -n dump.xml XPath error : Undefined namespace prefix xmlXPathCompiledEval: evaluation failed runtime error: element for-each Failed to evaluate the 'select' expression. Навскидку:утилита xmlstarlet, а не xml (хотя у вас она может быть и переименована). FreeBSD. Другое окружение, библиотеки, версии. Там много чего намешано вокруг XML-обработки... у меня Linux, разных версий. окружение командной строки, консоли. Например, неверно интерпретирует скобки-кавычки или там еще что-то. У меня bash или sh. некорректный предлагаемый для обработки dump.xml (ну мало ли). xmlstarlet val dump.xml может помочь прояснить ситуацию. вот так работает: xml sel -T -t -m '//content' -v "concat(ip,';',url)" -n dump.xml спасибо. Спасибо большое за подсказку.

Привет, Виталий! У нас ребуты пропали после перехода на архитектуру AMD64 и выкидывания из ядра IPV6. <kan5300@nas1>uptime 3:48PM up 112 days, 15:29, 2 users, load averages: 2.63, 2.20, 2.05

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

Кстати, спасибо за указание этого типа потока. Я по крайней мере понял как называется штука, с которой мы имеем дело: Transport streams can contain one or more than one program service. A transport stream that offers just one program service is called a single program transport stream. If a transport stream offers more than one program service, it is a multiple program transport stream. Program streams only offer a single program service. Сейчас еще связываемся с Москвичами (SPM Group) по поводу платформы EMP 3.0-4. Все в один голос говорят что софт сырой и китайцы его непрерывно дорабатывают. Потребители заказывают в основном 3.0-2 (двухпортовую версию с одним основным и одним резервным портом). Так что сроки поставки везде колеблятся от месяца до двух.

Как раз их нам рекомендовали и с ними сейчас ведем переговоры. Но говрят что платформа EMP 3.0 совсем новая и первая поставка в Россию произошла совсем недавно. После оплаты счета поставка может сильно затянуться =(

до 128 сервисов / 1024 PID на 1RU шасси до 2-х IP карт на шасси (каждая по 2 GbE I/O интерфейса), выход 600 Мбит/сек на карту port redundancy, service redundancy и пр. Возможно Sumavision EMR или Gospell GM-2730B обойдутся дешевле, но как у них с надежностью - не знаю. Я бы выбрал PS1000. Дополнительно его можно доостнастить платами MPEG-2 реенкодинга (до 64 сервисов на шасси) для выравнивания битрейтов и изменения формата кадра. Сейчас как раз ведутся переговоры с продавцом на счет платформы EMP 3.0-4 SumaVision. Стоимость решения не превышает 300к. Коллеги из конторы, предоставляющей нам VOIP утверждают что с EMP проблем не будет. Они сами давно используют SM и якобы без проблем.

Софтовое или некоммерческое решение исключаем, 300к-400к сумма для нас хоть и трудно, но подъемная. Главная задача - не ошибиться в выборе оборудования и не прогадать. Админ конторы, дающей нам iptv говорит, что "тысячник" эту задачу переварит не напрягаясь. Я вобще никогда с подобным оборудованием не работал, по этому, опять таки, создал этот тред.

Мы их затерроризировали уже. Сначала они говорили что это никак невозможно. Потом что-то родилось, но идеала достичь не удалось (рассинхрон и т.д.). Сейчас ситуация вырисовывается в покупку Хармоника вот такого: http://www.harmonicinc.com/view_collateral.cfm?ID=4095 Специалисты продавца уверяют что нашу задачу он решит. Но стоимость решения такого ходит вокруг суммы в 350к и это какбы немало.

Прошу прощения за определенный дилетантизм в сфере IPTV, по этому и пишу на форум. Партнер нам дает мультикаст пол гигабита. Мы его роутим любым протоколом многоадресной маршрутизации в уровень доступа, ставим клиенту VLC Player и всё работает без проблем. Как только меняем на абонентскую приставку Amino начинаются проблемы. Партнер дает нам сразу 5 каналов внутри одной мультикаст-группы и одного порта. Разделяются они за счет аудио и видео PID-ов. Мы пытались научить Amino разбираться, связывались с саппортом, но идеала добиться не удалось. Иногда каналы переключались, но не было звука и какие-то еще проблемы. Поставщик услуги заявил о невозможности предоставления пакета в формате один адрес группы = один канал. Начали поиски устройства, которое бы занялось ремультиплексированием. Нужно чтобы оно по одному SFP принимала то что дают, а со сторого SFP уже стримила в нормальном виде в L3 свитч с PIM. Можете что-то посоветовать?

Перезагрузили: Uploaded with ImageShack.us Всё равно тенденция не здоровая. Будем смотреть за состоянием mpd теперь.

Обнаружил кое-какое расхождение в конфиге с другими NAS-серверами на 9.0, подправил и обновил через portupgrade кваггу и все required порты. Заодно подтянул новые исходники через cvsup и пересобрал мир с ядром. Осталось ребутнуть. Во время этих мероприятий Memory free резко подскочило, а Cache соответственно уменьшился Uploaded with ImageShack.us Теперь стало заметно что утекает память относительно своего исходного размера. 24 назад было 1610, сейчас на 300 мегов меньше. Есть подозрение, что mpd зависнет когда абсолютно вся память таким образом исчезнет. Но дожидаться мы этого не будем, произведем ребут.

Это понятно, но хотелось бы обнаружить причину всех бед, т.к. аналогичный сервак (по софту и нагрузке) работает стабильно. Вчера ночью перезагрузили mpd (первый скачек на графике) и потом еще крон видимо что-то делал, прибавился еще cached. Ждём когда free опустится до нуля и будем смотреть, повторится ли замеченный ранее симптом. Uploaded with ImageShack.us

Type InUse MemUse HighUse Requests Size(s) sigio 1 1K - 1 64 filedesc 48 49K - 336446 16,32,64,128,512,1024,2048,4096 kenv 90 11K - 101 16,32,64,128 kqueue 0 0K - 3422 256,2048 proc-args 26 2K - 159407 16,32,64,128,256 hhook 2 1K - 2 128 acpitask 1 2K - 1 2048 ithread 134 21K - 134 32,128,256 CAM dev queue 5 1K - 5 128 CAM queue 17 1K - 86 16,32 KTRACE 100 13K - 100 128 acpisem 18 3K - 18 128 linker 223 122K - 282 16,32,64,128,256,512,1024,2048,4096 lockf 26 3K - 478 64,128 loginclass 1 1K - 1043 64 CAM SIM 5 2K - 5 256 temp 1609 66K - 21859887 16,32,64,128,256,512,1024,2048,4096 devbuf 722 6957K - 738 16,32,64,128,256,512,1024,2048,4096 module 275 35K - 275 128 mtx_pool 2 16K - 2 ata_pci 2 1K - 2 64 CAM periph 4 1K - 20 16,32,64,128,256 subproc 286 290K - 335305 512,4096 proc 2 16K - 2 session 23 3K - 1079 128 pgrp 24 3K - 1124 128 cred 38 6K - 2955072 64,256 uidinfo 5 3K - 124845 128,2048 plimit 13 4K - 182753 256 CAM XPT 39 22K - 139 32,64,128,1024,2048 sysctltmp 0 0K - 1739034 16,32,64,128,256,4096 sysctloid 6321 317K - 6447 16,32,64,128 sysctl 0 0K - 399196 16,32,64 tidhash 1 16K - 1 callout 5 2560K - 5 umtx 1716 215K - 1716 128 p1003.1b 1 1K - 1 16 bus-sc 101 100K - 3590 16,32,128,256,512,1024,2048,4096 bus 869 87K - 39975 16,32,64,128,256,1024,2048 devstat 8 17K - 8 32,4096 eventhandler 76 6K - 76 64,128 kbdmux 6 18K - 6 16,512,1024,2048 kobj 176 704K - 271 4096 Per-cpu 1 1K - 1 32 LED 8 1K - 8 16,128 rman 266 31K - 666 16,32,128 sbuf 1 1K - 56033 16,32,64,128,256,512,1024,2048,4096 stack 0 0K - 2 256 taskqueue 47 4K - 47 16,32,128 Unitno 15 1K - 1780545 32,64 iov 0 0K - 15558 16,64,128,256,512 select 760 95K - 760 128 ioctlops 0 0K - 39179996 16,32,64,128,256,512,1024 msg 4 30K - 4 2048,4096 sem 4 106K - 4 2048,4096 shm 1 20K - 1 tty 20 20K - 27 1024,2048 pts 1 1K - 6 256 mbuf_tag 105 4K - 3686550832 32,64 shmfd 1 8K - 1 DEVFS1 83 42K - 104 512 pcb 34 158K - 1727443 16,32,64,128,1024,2048,4096 soname 4 1K - 56304997 16,32,128 acl 0 0K - 1561 4096 vfscache 1 1024K - 1 cl_savebuf 0 0K - 27 64 vfs_hash 1 512K - 1 DEVFS3 99 25K - 133 256 vnodes 2 1K - 2 256 vnodemarker 0 0K - 48773 512 mount 61 3K - 131 16,32,64,128,256 BPF 788 99K - 8853 128 ether_multi 1576 62K - 16546 16,64 ifaddr 2393 817K - 26007 32,512,4096 ifnet 789 1584K - 8860 128,256,512,1024,2048,4096 clone 5 20K - 5 4096 arpcom 5 1K - 5 16 lltable 1229 505K - 10443 256,512 DEVFS 15 1K - 16 16,128 routetbl 934 165K - 230081 32,64,128,256,512 netflow_hash 1 3072K - 1 netflow_general 1 1K - 1 256 netgraph_msg 0 0K - 24217550 64,128,256,512,1024 netgraph_node 7130 1783K - 144452 256 netgraph_hook 20112 2514K - 330418 128 netgraph 5611 11213K - 91792 64,128,256,512,1024,4096 netgraph_iface 782 98K - 8847 128 netgraph_ksock 784 98K - 13928 128 netgraph_sock 4 1K - 43306 128 netgraph_path 0 0K - 12390542 16,32 igmp 788 197K - 8853 256 in_multi 785 197K - 8269 256 IpFw/IpAcct 18 3K - 32 16,32,64,128 ipfw_tbl 5250 1313K - 10748 256 sctp_iter 0 0K - 3 256 sctp_ifn 3 1K - 3 128 sctp_ifa 4 1K - 4 128 sctp_vrf 1 1K - 1 64 sctp_a_it 0 0K - 3 16 hostcache 1 28K - 1 syncache 1 96K - 1 libalias 482503 60441K - 244360384 128 sctpnat 6 80K - 6 rpc 2 1K - 2 256 audit_evclass 179 6K - 218 32 jblocks 8 2K - 8 128,256 savedino 0 0K - 291 256 sbdep 0 0K - 2266 64 jsegdep 0 0K - 21436 64 jseg 0 0K - 5304 128 jfreefrag 0 0K - 159 128 jnewblk 0 0K - 15739 128 jremref 0 0K - 2765 128 jaddref 0 0K - 2773 128 freedep 0 0K - 35 64 freework 1 2K - 606 128,2048 newdirblk 0 0K - 6 64 dirrem 0 0K - 2753 128 mkdir 0 0K - 12 128 diradd 0 0K - 2761 128 freefile 0 0K - 472 64 freeblks 0 0K - 471 128 freefrag 0 0K - 159 128 indirdep 0 0K - 2097 128 newblk 1 128K - 15740 256 bmsafemap 2 9K - 2327 256 inodedep 2 513K - 5176 512 pagedep 2 129K - 422 256 ufs_dirhash 858 183K - 864 16,32,64,128,256,512 ufs_mount 12 50K - 12 512,4096 vm_pgdata 1 128K - 1 UMAHash 3 13K - 10 512,1024,2048,4096 memdesc 1 4K - 1 4096 atkbddev 2 1K - 2 64 pfs_nodes 21 6K - 21 256 GEOM 59 11K - 782 16,32,64,128,256,512,1024 acpidev 52 4K - 52 64 pci_link 16 2K - 16 64,128 apmdev 1 1K - 1 128 acpi_perf 6 3K - 6 512 acpiintr 1 1K - 1 64 isadev 5 1K - 5 128 qpidrv 1 1K - 1 16 io_apic 1 2K - 1 2048 entropy 1024 64K - 1024 64 MCA 7 1K - 7 64,128 msi 20 3K - 20 128 nexusdev 4 1K - 4 16 cdev 7 2K - 7 256 acpica 4954 536K - 76964 16,32,64,128,256,512,1024,2048,4096 UART 6 4K - 6 16,512,1024 netgraph_mppc 0 0K - 1 1024 netgraph_ppp 782 9384K - 8847 netgraph_bpf 8772 1097K - 123364 128 Перешел по ссылке, глянул сисктл, hw.bus.devctl_disable: 0