но это все

евенты я ловлю но кроме +OK Deleted': '0' ничего больше нет

те дебажить как то особо не получается, разве что есть какойто другой вариант

те дебажить как то особо не получается, разве что есть какойто другой вариант

strace например

или перехватывать что там fs в sqlite пихает

а можно както фильтрануть по интересующим событиям ?

это из пушки по воробьям мне кажется ...

да перехватить то можно, и я больше чем уверен что увижу евенты на создание жоба, теже самые которые я получаю :)

а вот что внутри крутится и почему 10% этих команд не выполняются ...

ну не знаю, быстро и приятно не получится

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

либо методом тыка либо стрейс

но имхо - лучше для начала в shm базу перенести

да перевел уже, толку ноль

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

Всего 6 килобаксов в месяц и они посмотрят что там не так

"вы на программиста потратите больше"

больно столько. ентерпрайзники типа Сонуса и те меньше дерут...

Вопросы весту

Он там личку долбит "гони бабло"

ну если бы была адекватная команда с адекватными ценами на суппорт - можно было бы, но таких незнаем, а Энтони как то больно дорого берет, для opensource_а.

Угу

Может и мы подписались бы

добрый день, коллеги. не подскажите по поводу dtmf? у меня 2 случая: в первом dtmf распознался, во втором нет(при этом в DEBUG пишется) разница в duration: (там где 1280 -ОК, там где 1600 - Игнорирует). в internal.xml dtmf-duration = 2000 1ый: switch_channel.c:515 RECV DTMF *:1280 Send start packet for [*] ts=62080 dur=160/160/1280 seq=21571 lw=62080 Send middle packet for [*] ts=62080 dur=320/320/1280 seq=21572 lw=62240 Send middle packet for [*] ts=62080 dur=480/480/1280 seq=21573 lw=62400 Send middle packet for [*] ts=62080 dur=640/640/1280 seq=21574 lw=62560 Send middle packet for [*] ts=62080 dur=800/800/1280 seq=21575 lw=62720 Send middle packet for [*] ts=62080 dur=960/960/1280 seq=21576 lw=62880 Send middle packet for [*] ts=62080 dur=1120/1120/1280 seq=21577 lw=63040 Send end packet for [*] ts=62080 dur=1280/1280/1280 seq=21578 lw=63040 Send end packet for [*] ts=62080 dur=1280/1280/1280 seq=21579 lw=63040 Send end packet for [*] ts=62080 dur=1280/1280/1280 seq=21580 lw=63040 Queue digit delay of 40ms 2ой: Send start packet for [*] ts=361440 dur=160/160/1600 seq=37409 lw=361440 Send middle packet for [*] ts=361440 dur=320/320/1600 seq=37410 lw=361600 Send middle packet for [*] ts=361440 dur=480/480/1600 seq=37411 lw=361760 Send middle packet for [*] ts=361440 dur=640/640/1600 seq=37412 lw=361920 Send middle packet for [*] ts=361440 dur=800/800/1600 seq=37413 lw=362080 Send middle packet for [*] ts=361440 dur=960/960/1600 seq=37414 lw=362240 Send middle packet for [*] ts=361440 dur=1120/1120/1600 seq=37415 lw=362400 Send middle packet for [*] ts=361440 dur=1280/1280/1600 seq=37416 lw=362560 Send middle packet for [*] ts=361440 dur=1440/1440/1600 seq=37417 lw=362720 Send end packet for [*] ts=361440 dur=1600/1600/1600 seq=37418 lw=362720 Send end packet for [*] ts=361440 dur=1600/1600/1600 seq=37419 lw=362720 Send end packet for [*] ts=361440 dur=1600/1600/1600 seq=37420 lw=362720 Queue digit delay of 40ms

куда копать не подскажите?

не в курсе, FS с sqlite работает в 1 поток? там есть какието блокировки?

sqlite сам по себе один поток так что 2 запроса и более одновременно заблокируются

тааакс.... моя догадка становится реальнее...

@dyermakov спасибо!

Кстати, знающие люди говорят, что SQLite на ramdrive работает быстрее ODBC

быстрее... только ненадежней при большой нагрузке

При использовании PostgreSQL в ядре - никаких изменений, теже 10% потерь 'sched_del' :(

запросы смотрели?

нет

log_min_duration_statement = 0

log_statement = 'all'

ищите id проблемной таски, смотрите что с ней делал sched_del

честноговоря я особо смысла не вижу. евенты на выполнение команды все есть, ответы по ним тоже, все отрабатывает, только вот с разными ответами :)

ещё вопрос, вот мы тут такие стараемся, а в чём конкретно проблема? Таски не удаляются и повисают?

log_min_duration_statement = 0 это хде ? PG ?

ессно

венты на выполнение команды все есть, ответы по ним тоже, все отрабатывает - тогда зачем мы все здесь собрались?

озвучте проблему пожалуйста

Спасибо запомощь! проблема в том что таски на sched_del иногда (10%) просто не выполняются. Хотя все приходят в FS, евенты на них генерятся.

что значит не выполняются? Я по вашим словам вижу что

евенты на выполнение команды все есть, ответы по ним тоже, все отрабатывает

Пришел sched_del, сгенерился евент, все как бы класно но sched_hangup не удалился.

ага, значит не удаляются таски...

ответы по ним должны быть все 1, а приходят 0 (10%) что видимо говорит о том что таска выполнена неуспешно

ну так идём в лог PG ищем запрос от sched_del на удаление, и смотрим почему таска ещё в таблице

ответы по ним должны быть все 1, а приходят 0 (10%) что видимо говорит о том что таска выполнена неуспешно

ответ говорит о том что sched_del ничего не сделал

ну я вроде как бы сначала пишу об этом

пруф?

sched_del - в БД не ложаться :( только sched_hangup

"Столкнулся с проблемой, около 10% от всех запущенных команд 'sched_del' на траффике не отрабатывают. " пожалуй да, столило бы указать что ВСЕ ПРИХОДЯТ но НЕ ИСПОЛНЯЮТСЯ.

А я утвержадю что отрабатывают

mod_commands.c

if (switch_is_digit_string(cmd)) { int64_t tmp; tmp = (uint32_t) atoi(cmd); if (tmp > 0) { cnt = switch_scheduler_del_task_id((uint32_t) tmp); } } else { cnt = switch_scheduler_del_task_group(cmd); } stream->write_function(stream, "+OK Deleted: %u\n", cnt);

всё отработало как надо

и тут два варианта

1) sched_hangup на который вызывался sched_del уже нет

2) sched_del вызывается с некореектным <group_name|task_id>

первый вариант вам поможет исключить PG с log_min_duration_statement = 0 log_statement = 'all'

в расследованиее второго варианта вам поможет PG с log_min_duration_statement = 0 log_statement = 'all'

Второй вариант исключен, проверял. Первый вариант вполне возможен, с учётом того что частенько оригинируются звонки с sched_hangup 3. Я конечно же проверю ваши подсказки, но возникает подозрение что FS за 3 секунды не успевает удалить sched_hangup.

но как такое может быть хз

но возникает подозрение что FS за 3 секунды не успевает удалить sched_hangup. - в расследованиее второго варианта вам поможет PG с log_min_duration_statement = 0 log_statement = 'all'

там будет время выполнения запроса

Ну Оке, проврим

ERROR: S client not available

приходите с пивом когда закончите)

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

приходите с пивом когда закончите)

Ну если не далеко идти, придем ;)

ну если бы была адекватная команда с адекватными ценами на суппорт - можно было бы, но таких незнаем, а Энтони как то больно дорого берет, для opensource_а.

А сколько должно быть для опенсорса ?

Pavel ну как минимум меньше чем для кроваго интерпрайза

и почему ? .)

простая математика

не понимаю математики .)

А сколько, по Вашему, в энтерпрайзе ?

настроить fs стало дешевле чем cucm ?

@vexoid может тогда не стоит терять время ? ;)

да

может быть и не стоит, но я помучаюсь .) не понимаю взаимосвязи между опенсорс и не опенсорс и стоимостью поддержки

простая математика

Эммм ?

сколько интерпрайз тратит ресурсов на свой продукт, и сколько опенсорс коммюнити - посчитайте

сколько стоят знания инженера Cisco и сколько стоят знания инженера специализированного софта\железа... Cisco как затычка, материалов, курсов, софта, железа - ж**й жуй, нужно что то более специализированное - дороже, платите)

сколько интерпрайз тратит ресурсов на свой продукт, и сколько опенсорс коммюнити - посчитайте

Кто-то производящий услугу эффективней прочих выигрывает в доходе.

это уже бизнес модели

суть в том что опенсорс дешевле, в плане затраченных ресурсов на него

коммьюнити тестит, пилит, поддерживает ... за спортивный интерес (ну или почти)

и предоставляет почти всегда в формате жри что дают

для бедных сойдет

Основной плюс опенсорса это то, что исходники есть. Можно со стороны нанять тех, кто в них разберётся и решит ваш вопрос. А в случае проприетарного софта тут придётся соглашаться на условия вендора.

суть в том что опенсорс дешевле, в плане затраченных ресурсов на него

Всё равно, не ясно, почему цена поддержки фс - дорого

ну да вендор-лок тот еще кот в мешке :)

Основной плюс опенсорса это то, что исходники есть. Можно со стороны нанять тех, кто в них разберётся и решит ваш вопрос. А в случае проприетарного софта тут придётся соглашаться на условия вендора.

а ещё в том что можно выпилить костыль не дожидаясь вендора

2009 год, bgp стык между openbgpd и juniper mx... оба ведут себя как говно (не по rfc, один отправляет флаг хотя не должен, другой рвёт сессию получив, не ожидая хотя не должен) в openbgpd исправилось за 30 минут, в mx через 8 месяцев (сервисный контракт в наличии)

ребята, ну 6k$\месяц это просто жесть! тот же суппорт Сонуса и то дешевле в разы! а уровени продуктов абсолютно разные!

openbgpd нихера не стоит (таз на котором он крутился стоил 2k $), mx тот в той набивке стоил 1kk $ если не изменяет память .)

@vexoid а как же риски? коммюнити вам может компенсировать?

а как же риски... juniper нихера не компенсирует .)

еще скажите что поддержку берут ради поддержки продукта!!!