О деактивации форума Eltex

Уважаемые коллеги! В связи с потерей актуальности данного ресурса, нами было принято решение о частичной деактивации форума Eltex. Мы отключили функции регистрации и создания новых тем, а также возможность оставлять сообщения. Форум продолжит работу в "режиме чтения", так как за долгие годы работы здесь накопилось много полезной информации и ответов на часто встречающиеся вопросы.

Мы активно развиваем другие каналы коммуникаций, которые позволяют более оперативно и адресно консультировать наших клиентов. Если у вас возникли вопросы по работе оборудования, вы можете обратиться в техническую поддержку Eltex, воспользовавшись формой обращения на сайте компании или оставить заявку в системе Service Desk. По иным вопросам проконсультируют наши менеджеры коммерческого отдела: eltex@eltex-co.ru.

НЦС и Firebird 2.5.2

АТС МС240 на базе ЦПв3 и ЦКП
Kostyan_
Сообщения: 7
Зарегистрирован: 10 дек 2012 12:40
Reputation: 0
Откуда: Улан-Удэ

НЦС и Firebird 2.5.2

Сообщение Kostyan_ » 10 дек 2012 13:42

НЦС не запускается с версией FB 2.5
По трейсам сервера видно следующее:
Statement 36:
-------------------------------------------------------------------------------
SELECT CAST('NOW' AS TIMESTAMP) from RDB$DATABASE

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (RDB$DATABASE NATURAL)

2012-12-10T11:08:49.9630 (1436:01E8C65C) ERROR AT jrd8_start_transaction
D:\111\MC240-NET.FDB (ATT_32, SYSDBA:NONE, WIN1251, TCPv4:127.0.0.1)
D:\111\NCS\NCS.exe:4604
335544330 : invalid parameter in transaction parameter block
335544889 : Option isc_tpb_rec_version requires READ COMMITTED isolation in TPB

Можно откомпилить НЦС, добавив в TpFIBTransaction.TRParams параметр read_commited или указав TpFIBTransaction.TPBMode:=tpbReadCommitted ?
И наверное было бы желательно обновить версию FIBPlus, если Вас не затруднит.

И еще просьба по FBLoader:
При распарсивании каждого файла программа выполняет запрос SELECT COUNT(*) FROM converslog
Записи из Converslog периодически переносятся в Conversarch, но тем не менее, этот запрос выполняется около 30-40 секунд, что существенно тормозит суммарное время загрузки с около 150 станций. Я не пойму для чего нужен этот запрос? Можно его убрать?

Алексей Сергеев
Сообщения: 321
Зарегистрирован: 13 янв 2005 20:45
Reputation: 0
Откуда: Компания Элтекс
Контактная информация:

Сообщение Алексей Сергеев » 19 дек 2012 17:50

Программы предназначенные на использование сервера FB1.5 никак не будут работать с версиями FB 2.0 и 2.5.
Необходимо устанавливать последнюю версию линейки FB1.5

Kostyan_
Сообщения: 7
Зарегистрирован: 10 дек 2012 12:40
Reputation: 0
Откуда: Улан-Удэ

Сообщение Kostyan_ » 25 дек 2012 15:10

FBLoader с Firebird 2.5.2 работает нормально. В NCS необходимо только добавить вышеуказанный параметр подключения.
Собственно, из-за чего начались пляски: подключили к мониторингу одну сельскую АТС, там накопился файл с билингом около 20 МБ. Загрузка/распарсивание этого файла затянулась на сутки. Окончания я не дождался и решил попробовать перейти на FB 2.5.2, т.к. обещали улучшение параллелизма и производительности. Плюс наличие трейсов.

По трейсам удалось выяснить, что по каждой (вроде как) записи FBLoader осуществляет SELECT-запрос к таблице LONG_CALLS в которой индекс только по первичному ключу, а за всё время таблица неплохо разрослась...

Ну и на 2.5.2 действительно лучше распараллеливается. В 1.5 грузится только одно ядро, не смотря на параметр CpuAffinityMask в firebird.conf

Поднимать отдельно сервер FB для NCS и для базы с биллингом как-то не рационально. Поэтому хотелось бы получить потдержку NCS-ом версии 2.5.2, к тому же, многого для этого не требуется.

Алексей Сергеев
Сообщения: 321
Зарегистрирован: 13 янв 2005 20:45
Reputation: 0
Откуда: Компания Элтекс
Контактная информация:

Сообщение Алексей Сергеев » 25 дек 2012 16:13

Select count(*) from converslog - собственно проверка не пора ли перекинуть в архив. Немного неожиданно что парсится 150 файлов подряд, потому и не учли что это не оптимально в таком случае.
Запланируем переделку.

По таблице LONG_CALL. Теоретически она не должна накапливать записи, так как это информация о кусках длинных разговоров, которые после окончания склейки полностью удаляются из таблицы.
Источником накопления может быть:
- потери концовок, т.е. конец разговора так и не был обработан, потому остались его неполные части.
- неправильный порядок разбора и/или двойной парсинг файлов. При парсинге порядок имеет значение: файлы должны подаваться на вход в том же порядке как они писались станцией. Т.е. чтобы разговор, попавший в разные файлы, накапливал свои куски в правильном порядке.

Для адекватной помощи не могли бы Вы посмотреть за какой период накопились данные в таблице LONG_CALL и их общее количество? и как оно коррелирует с количеством всех обработанных записей биллинга?
Если там есть довольно старые записи можно будет их удалить SQL запросом. Полагаю у вас на АТС нет разговоров длящихся месяцами?

По поводу FB2.5 - необходимы исследования с нашей стороны, без них ничего сказать не можем. Возможно появилась некоторая совместимость в новых версиях FB, но с этим надо разбираться.
Попробуем выделить на это время, но заранее ничего не обещаем.

Kostyan_
Сообщения: 7
Зарегистрирован: 10 дек 2012 12:40
Reputation: 0
Откуда: Улан-Удэ

Сообщение Kostyan_ » 26 дек 2012 06:55

Алексей Сергеев писал(а):По таблице LONG_CALL. Теоретически она не должна накапливать записи, так как это информация о кусках длинных разговоров, которые после окончания склейки полностью удаляются из таблицы.
Источником накопления может быть:
- потери концовок, т.е. конец разговора так и не был обработан, потому остались его неполные части.
- неправильный порядок разбора и/или двойной парсинг файлов. При парсинге порядок имеет значение: файлы должны подаваться на вход в том же порядке как они писались станцией. Т.е. чтобы разговор, попавший в разные файлы, накапливал свои куски в правильном порядке.

Для адекватной помощи не могли бы Вы посмотреть за какой период накопились данные в таблице LONG_CALL и их общее количество? и как оно коррелирует с количеством всех обработанных записей биллинга?
Если там есть довольно старые записи можно будет их удалить SQL запросом. Полагаю у вас на АТС нет разговоров длящихся месяцами?

- Потери концовок по идее быть не должно, данные снимаются через BillReader, у станционных инженеров версия админа без биллинга.
- Последовательность тоже не нарушается. Сняли биллинг со станции - загрузили в базу.
Данные в таблице были с начала перехода на FBLoader с поддержкой склейки длинных разговоров. Таблица была подчищена и добавлен индекс. Оставил записи за последние полгода. Сейчас там 258 тысяч записей, в основном соединения pcm-gate'ов, но встречаются и обычные звонки.
В Converslog данные тоже хранятся за полгода, более старые переносятся в Conversarch. Сейчас там ~16.4 миллиона записей.

Алексей Сергеев
Сообщения: 321
Зарегистрирован: 13 янв 2005 20:45
Reputation: 0
Откуда: Компания Элтекс
Контактная информация:

Сообщение Алексей Сергеев » 26 дек 2012 11:27

Да. Про pcm-gate я как-то не подумал. Там действительно звонки длятся бесконечно, и как правило финала нет, так как по рестарту АТС звонок не успевает финализироваться. Надеюсь pcm-gate не тарифицируются?
Попробуем подобрать оптимальные параметры для удаления несущественных данных из базы LONG_CALL.
Помниться я делал режим в bin2dbf в котором скидывались только незавершенные разговоры из базы. Добавить туда же функцию по очистке.
Т.е. выдать список незаконченных разговоров, скажем старее пары суток от последнего импорта, чтобы убедиться что разговор больше не продолжается, подсчитать их накопленную длительность, и удалить из базы, так как финала разговорам уже не будет.
Вас заинтересует такая функция?

Kostyan_
Сообщения: 7
Зарегистрирован: 10 дек 2012 12:40
Reputation: 0
Откуда: Улан-Удэ

Сообщение Kostyan_ » 26 дек 2012 12:08

Алексей Сергеев писал(а):Надеюсь pcm-gate не тарифицируются?

С гейтов соединения на тарификацию не подаются.
Алексей Сергеев писал(а):Вас заинтересует такая функция?

Да, было бы логично склеивать и соединения без финальной части, а то сейчас получается такие звонки как бы вообще "теряются", не попадая в Converslog даже с неполной длительностью.

Kostyan_
Сообщения: 7
Зарегистрирован: 10 дек 2012 12:40
Reputation: 0
Откуда: Улан-Удэ

Сообщение Kostyan_ » 27 дек 2012 13:47

Алексей Сергеев писал(а):По поводу FB2.5 - необходимы исследования с нашей стороны, без них ничего сказать не можем. Возможно появилась некоторая совместимость в новых версиях FB, но с этим надо разбираться.
Попробуем выделить на это время, но заранее ничего не обещаем.

Под совместимостью Вы имеете в виду сам NCS или базу данных формата 1.5 с сервером 2.5? База данных конвертируется в формат FB 2.5 через backup/restore. NCS, на сколько я понял, подключается к базе через библиотеку компонентов FIBPlus, она FB2.5.2 поддреживает.


Вернуться в «АТС: городские, узловые, сельские»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 17 гостей