Добрый день!

Есть ИРБИС 2012. Свой клиент, который общается с сервером.

Иногда клиент падает по причине не корректного ответа от сервера (не верные данные в заголовке или просто обрезанный ответ).

Сначала грешил на своего клиента, но добавив в него повтор команды, которая дала сбой - понял что дело в сервере. (повтор - это отправка точно такого же пакета, как до сбоя)

Такой костыль работает ровно до того момента пока сбой не случится на команде записи (особенно "Синхронное сохранение группы записей с общей блокировкой (6)"). Повтор такой команды чаще всего завершается с ошибкой -608 "при записи обнаружено несоответстивие версий", что логично - команда могла записать данные (как минимум частично).
Городить в своем коде кучу проверок - не очень хотелось, потому начал выяснять в чем причина...

Выяснил.

Рабочий процесс "server_64.exe", который выполняет всю работу падает из-за попытки выделить больше 2Гб.

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

Если я правильно понял, то параметр MAX_PROCESS_REQUESTS определяет сколько запросов выполнит рабочий процесс, после чего он будет закрыт и запустится новый. По умолчанию он стоит 100. Но мой клиент падает примерно на 340-350 запросе (это когда я гонял тесты) и судя по наблюдениям за процессами ИРБИСа - все запросы обрабатывались одним и тем же процессом (до тех пор пока он не упадет).

Пробовал уменьшать значение параметра MAX_PROCESS_REQUESTS. Сначала до 50, потом до 10 - разницы никакой.

Пробовал делать "переконект" каждые (100/50/10 запросов) с паузой в 5/10 с между разрегистрацией и регистрацией клиента - рабочий процесс не рестартует и соответственно - падает.

Собственно вопросы:
1. Я не правильно понимаю смысл параметра MAX_PROCESS_REQUESTS?
2. Как можно решить эту проблему?

Сделал еще несколько тестов...

Ситуация такая - рабочий процесс таки перезапускается, вот только условие понять не могу. Если в кол-ве запросов, то выходит около 360-370.

Это все при одиночной записи (команда "D")

При пакетной - память утекает быстрее и процесс просто не успевает перезапустится...

И еще момент:
При одиночной записи процесс успевает открыть (и не закрыть) более 600 файлов для одной базы (*.MST, *.XRF)
При пакетной - около 7000

slay написал(а):
-------------------------------------------------------
> Ситуация такая - рабочий процесс таки
> перезапускается, вот только условие понять не
> могу. Если в кол-ве запросов, то выходит около
> 360-370.

Наблюдая в клиентском администраторе за списком процессов сервера выяснил, что процесс перезапускается после 1000 запросов и очень похоже что это никак не настраивается. Печаль...


Сделал еще один тест с параметром KEEP_PROCESS_ALIVE установленным в 0
Как и ожидалось - пакетная запись отработала без ошибок, но при этом все остальные тесты показали худшую производительность (что логично)

Пока готовил результаты тестов, начали терзать сомнения в том, что эта 1000 запросов прибита гвоздями в коде и не настраивается. Параметр есть, значит должно работать. А раз не работает, то...
Поискав строку "MAX_PROCESS_REQUESTS" в irbis_server.exe я ее не нашел. А если "MAX_PROCESS_REQUEST"?

Бинго! Есть такое!
Пишем MAX_PROCESS_REQUEST=100
Перезапускаем службу...
Запускаем тест...
Работает!

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

Суть теста:
1. Есть база в которой 123330 записей
2. Читаем все записи (команда "G", с форматом &uf('+0') пачками по 100 записей
3. Обрабатываем (тут не суть важно что и как - главное что во всех вариантах это один и тот, же код)
4. Если запись изменилась, то сохраняем (во всех тестах сохраняется 16949 записей)
4.1 сохранение по одной записи - команда "D"
4.2 пакетное сохранение - команда "6" (накапливаем в буфер и отправляем на сервер одним запросом)
5. В конце, если сохраняли без актуализации, то актуализируем

Перед запуском теста база востанавливалась из архива, служба ИРБИСа перезапускалась

Тесты выполнялись однократно. С ИРБИСом в это время работали пользователи (поиск и чтение)


Варианты тестов:

1. Только чтение и обработка (без реальной записи в базу)
1.0 для KEEP_PROCESS_ALIVE=1 и MAX_PROCESS_REQUEST=60 чтение командой "C" (без указания формата)
1.1 для KEEP_PROCESS_ALIVE=0
1.2 для KEEP_PROCESS_ALIVE=1
2.  Сохранение по одной записи (с актуализацией)
2.1 для KEEP_PROCESS_ALIVE=0
2.2 для KEEP_PROCESS_ALIVE=1
3.  Сохранение по одной записи (без актуализации)
3.1 для KEEP_PROCESS_ALIVE=0
3.2 для KEEP_PROCESS_ALIVE=1
4.  Пакетная запись, 60 записей в пакете (с актуализацией)
4.1 для KEEP_PROCESS_ALIVE=0
4.2 для KEEP_PROCESS_ALIVE=1
4.3 для KEEP_PROCESS_ALIVE=1 и MAX_PROCESS_REQUEST=100
4.3 для KEEP_PROCESS_ALIVE=1 и MAX_PROCESS_REQUEST=60  Пришлось уменьшить, а то снова упал
5.  Пакетная запись, 60 записей в пакете (без актуализации) 
5.1 для KEEP_PROCESS_ALIVE=0
5.2 для KEEP_PROCESS_ALIVE=1
5.3 для KEEP_PROCESS_ALIVE=1 и MAX_PROCESS_REQUEST=100

Результаты:

- Обработка/Актуализация/Общее - время в сек.
- Прирост - на сколько процентов изменилась скорость работы 
  Для тестов 1.* - относительно 1.1
  Для остальных - относительно 2.2
- Замедление - на сколько замедляется запись относительно только чтения  
- Записей/сек (в скобках - во сколько раз замедляется работа при записи)
- Память - объем памяти занимаемый процессом обработки перед завершением (по диспечеру задач)

Тест   Обработка   Актуализация   Общее    Прирост Замед.  Записей/сек.   Память
1.0    1058.40     -              1058.40  0               116            <15
1.1    140.31      -              140.31   87%             879            <15
1.2    104.12      -              104.12   91%             1184           <15

2.1    3324.49     -              3324.49  -19%    2369%   37(-23.8)      <15
2.2    2789.06     -              2789.06  0       2679%   44(-26.9)      ~650

3.1    2367.74     114.34         2482.08  11%     1769%   52(-16.9)      <15
3.2    2078.46     124.68         2203.14  21%     2116%   59(-20.1)      ~390

4.1    2417.63     -              2417.63  13%     1723%   51(-17.2)      <80
4.2    ошибка выполнения                                                  >1900
4.3    ошибка выполнения                                                  >1900
4.4    2830.32     -              2830.32  -1%     2718%   43(-27.5)      ~400..700

5.1    1743.25     114.97         1858.22  33%     1324%   70(-12.5)      <30
5.2    ошибка выполнения                                                  >1900
5.3    2038.88     116.85         2155.73  23%     2070%   60(-19.7)      ~800..1100

Выводы:
Вывод сделать очень сложно ибо тесты не совсем корректны. (Есть мысли как это сделать по умному,но нет времени)
Чтение - самый быстрый (как и ожидалось) это чтение пакетами (тест 1.2)
Запись. Тут не так все однозначно, но по имеющимся данным победитель - это вариант с пакетной записью без актуализации.

Очень странный результат для теста 4.4. Я ожидал, что он будет быстрее чем 4.1 и уж точно быстрее 2.2

Надеюсь это кому-то пригодится

Кстати - с утечками памяти надо что-то делать

И еще: какие еще способы есть для ускорения работы (записи в базу)? Может я не учел чего...

slay написал(а):
-------------------------------------------------------
> Поискав строку "MAX_PROCESS_REQUESTS" в
> irbis_server.exe я ее не нашел. А если
> "MAX_PROCESS_REQUEST"?
>
> Бинго! Есть такое!

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

2005-2012 irbis_server.exe содержит строку MAX_PROCESS_REQUEST
2013-2015 irbis_server.exe содержит строку MAX_PROCESS_REQUESTS

Во всех версиях irbis_server.ini содержит строку MAX_PROCESS_REQUESTS=100

При этом документация утверждает:

irbis64.doc (для версий 2005-2007) MAX_PROCESS_REQUESTS значение по умолчанию 100
irbis64_2008.doc (для версий 2008-2012) MAX_PROCESS_REQUESTS значение по умолчанию 100
irbis64_2013.doc (для версий 2013-2015) MAX_PROCESS_REQUESTS значение по умолчанию 10

Отсюда с неизбежностью делаем вывод: Пользователи ИРБИС64! Чаще пользуйтесь программами вроде 010 Editor, и будет вам счастье!

slay написал(а):
-------------------------------------------------------

> И еще: какие еще способы есть для ускорения работы
> (записи в базу)? Может я не учел чего...

Посмотрите в сторону глобальной корректировки. Может получиться, что глобальная выполнится быстрее, чем загрузка записей на клиента (хотя бы из-за гораздо меньшего объёма трафика).

amironov73 написал(а):
-------------------------------------------------------
> slay написал(а):
> --------------------------------------------------
> -----
>
> > И еще: какие еще способы есть для ускорения
> работы
> > (записи в базу)? Может я не учел чего...
>
> Посмотрите в сторону глобальной корректировки.
> Может получиться, что глобальная выполнится
> быстрее, чем загрузка записей на клиента (хотя бы
> из-за гораздо меньшего объёма трафика).

Этим пользуюсь, когда есть возможность. Но в данном конкретном случае, логика обработки такая что мне намного проще обработать это своей программой и залить назад, чем ломать голову как это сделать глобальной корректировкой.

А есть задачи где она совсем не подходит. Например вливание из вне, опять же с предварительной корректировкой.

Да и проблема трафика тут не сильно остро стоит, как показали результаты тестов 2.2 и 4.4. Правда есть подозрение что чем больше памяти утекло тем медленнее последующая обработка (или на уровне самого ИРБИСа или ОС тупить начинает)

Скорее всего о пакетной записи можно забыть ибо эффективность не сильно большая. Единственное надо реально уменьшить число обрабатываемых запросов где-то в районе 400-700. А то при 1000 у меня изредка и раньше падало.

slay написал(а):
-------------------------------------------------------
> Этим пользуюсь, когда есть возможность. Но в
> данном конкретном случае, логика обработки такая
> что мне намного проще обработать это своей
> программой и залить назад, чем ломать голову как
> это сделать глобальной корректировкой.

В глобальной корректировке можно вызывать внешнюю программу (&uf('+2') или &uf('+8')), в некоторых случаях этого вполне достаточно, если не хочется городить ужас на языке ИРБИС.

> А есть задачи где она совсем не подходит. Например
> вливание из вне, опять же с предварительной
> корректировкой.

Почему? NEWMFN + ADD + ... вполне рабочий сценарий, если речь не идёт о тысячах записей.

Если же речь идёт о заливке мегабайтных баз данных, то можно сочинить IBF-задание и вызвать АРМ «Администратор».

Или такой лайфхак: файл с записями можно залить на сервер через протокол ИРБИС, затем через глобальную вызвать серверный АРМ «Администратор», который вольёт записи напрямую в MST. Может получиться быстрее.



Редактировано 1 раз. Последний раз 04.04.2016 07:29 пользователем amironov73.

Есть еще способ ускорить работу при массовой корректировке:
1. Запрещаем доступ к базе (административно или делая это ночью)
2. Читаем всю базу
3. Обрабатываем
4. Сохраняем в txt файл все записи (обработанные и не обработанные)
5. По окончании опустошаем БД
6. Делаем импорт полученного txt файла
7. Создаем словарь полностью
8. Разрешаем доступ к базе

Когда под корректировку попадает больше 30% записей это реально быстрее (и надежнее) чем обновление части записей.

Только при таком сценарии мы теряем версии записей и все логически удаленные. Иногда это не желательно...

amironov73 написал(а):
-------------------------------------------------------
> slay написал(а):
> --------------------------------------------------
> -----
> > Этим пользуюсь, когда есть возможность. Но в
> > данном конкретном случае, логика обработки
> такая
> > что мне намного проще обработать это своей
> > программой и залить назад, чем ломать голову
> как
> > это сделать глобальной корректировкой.
>
> В глобальной корректировке можно вызывать внешнюю
> программу (&uf('+2') или &uf('+8')), в некоторых
> случаях этого вполне достаточно, если не хочется
> городить ужас на языке ИРБИС.
Сомневаюсь что это будет быстрее (да и по удобству сомнительно) - я на python'е пишу
>
> > А есть задачи где она совсем не подходит.
> Например
> > вливание из вне, опять же с предварительной
> > корректировкой.
>
> Почему? NEWMFN + ADD + ... вполне
> рабочий сценарий, если речь не идёт о тысячах
> записей.
Т.е. генерить сценарий на вставку? Надо будет попробовать ради интереса :)

>
> Если же речь идёт о заливке мегабайтных баз
> данных, то можно сочинить IBF-задание и вызвать
> АРМ «Администратор».
Если только добавить то да - это может помочь. А обновить запись оно может?
>
> Или такой лайфхак: файл с записями можно залить на
> сервер через протокол ИРБИС, затем через
> глобальную вызвать серверный АРМ «Администратор»,
> который вольёт записи напрямую в MST. Может
> получиться быстрее.
Тут аналогично - обновить запись оно может?

slay написал(а):
-------------------------------------------------------
> Если только добавить то да - это может помочь. А
> обновить запись оно может?
> Тут аналогично - обновить запись оно может?

К сожалению, нет. Такой функциональности в явном виде не предусмотрено.

Вообще, самый, наверное, эффективный способ – отредактировать интересующие записи напрямую (с помощью библиотеки irbis64.dll, программный интерфейс к которой авторы предоставляют, если их попросить). Круче этого, наверное, придумать ничего не получится.

Но есть и «бюджетные» способы борьбы c утекающей памятью и вылетающим server_64.exe: Вы можете предусмотреть перезапуск сервера (ИРБИС-сервера в целом), например, через каждые 300 запросов. Контекст работы клиентов при этом не теряется. Клиенты вообще ничего не замечают. Команда перезапуска: '+8'. Единственное ограничение: эта команда может быть послана лишь от имени АРМ «Администратор».

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



Редактировано 1 раз. Последний раз 04.04.2016 10:17 пользователем amironov73.

amironov73 написал(а):
-------------------------------------------------------
> slay написал(а):
> --------------------------------------------------
> -----
> > Если только добавить то да - это может помочь.
> А
> > обновить запись оно может?
> > Тут аналогично - обновить запись оно может?
>
> К сожалению, нет. Такой функциональности в явном
> виде не предусмотрено.
Жаль...
>
> Вообще, самый, наверное, эффективный способ –
> отредактировать интересующие записи напрямую (с
> помощью библиотеки irbis64.dll, программный
> интерфейс к которой авторы предоставляют, если их
> попросить).
Это к кому обращаться надо?
И еще: она кроме delphi с чем-то другим состыковывается?

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

> Но есть и «бюджетные» способы борьбы c утекающей
> памятью и вылетающим server_64.exe: Вы можете
> предусмотреть перезапуск сервера (ИРБИС-сервера в
> целом), например, через каждые 300 запросов.
> Контекст работы клиентов при этом не теряется.
> Клиенты вообще ничего не замечают. Команда
> перезапуска: '+8'. Единственное ограничение: эта
> команда может быть послана лишь от имени АРМ
> «Администратор».
Это я уже решил "правильной" установкой параметра MAX_PROCESS_REQUEST.

Но скорости особой все равно не получил.

slay написал(а):
-------------------------------------------------------
> Это к кому обращаться надо?

К вот этим замечательным людям: http://irbis.gpntb.ru/read.php?35,49671.

Частично описание доступно здесь: http://wiki.elnit.org/index.php/IRBIS64.dll.

> И еще: она кроме delphi с чем-то другим
> состыковывается?

С помощью ctypes и ласкового слова вполне стыкуется с Python. Наверное.

> Но скорости особой все равно не получил.

ИРБИС64 2012 довольно старый. На более современных версиях ИРБИС64-сервера доступны прелести многопоточности/многопроцессорности. Так что очень быстро всё начинает упираться в производительность дисковой подсистемы.

amironov73 написал(а):
-------------------------------------------------------
> slay написал(а):
> --------------------------------------------------
> > Это к кому обращаться надо?
>
> К вот этим замечательным людям:
> [irbis.gpntb.ru].
Спасибо! Сейчас попробую...

>
> Частично описание доступно здесь:
> [wiki.elnit.org].
>
> > И еще: она кроме delphi с чем-то другим
> > состыковывается?
>
> С помощью ctypes и ласкового слова вполне
> стыкуется с Python. Наверное.
Главное чтобы не завязывалось на runtime delphi, хотя и это обойти можно...

amironov73 написал(а):
-------------------------------------------------------
> slay написал(а):
> --------------------------------------------------
> ИРБИС64 2012 довольно старый. На более современных
> версиях ИРБИС64-сервера доступны прелести
> многопоточности/многопроцессорности. Так что очень
> быстро всё начинает упираться в производительность
> дисковой подсистемы.
Кстати, посмотрел темы форума "Версия 201*.1" - про многопоточность только в 2012 и упоминается...

slay написал(а):
-------------------------------------------------------
> Кстати, посмотрел темы форума "Версия 201*.1" -
> про многопоточность только в 2012 и упоминается...

Вот, например: http://irbis.gpntb.ru/read.php?35,92401

Режим DuplicateSockets ускоряет работу сервера за счет того, что не тратится время на обмен данными между сервером и процессами обработки.
Ответ сразу передается клиенту. Этот режим доработан и отлажен в 14 версии.

По моему опыту, режим реально доведён до ума, сервер стал бегать заметно быстрее.