Добрый вечер. Переустанавливаю систему на версию 2012.1. БД размером 1200000 - не создавались словари полностью. Добавила в irbisa.ini параметр MULTISORT=0. Словарь на эту БД создался. Но зато перестали работать корректно АРМ "Читатель" - выдавал ошибку регистрации и АРМ"Каталогизатор" - войти можно, но весь интерфейс АРМ поехавший - вместо названий вкладок - цифры, словари не грузятся и т. д., другие АРМ не проверяла. Удалила из irbisa.ini - система опять заработала.

Однако... Вы все смешали в кучу - параметр MULTISORT и "приключения" с АРМами Читатель и Каталогизатор АБСОЛЮТНО несвязанные вещи...

Ошибка в АРМе Администратор, связанная с многопроцессорной СОРТИРОВКОЙ (MULTISORT=1) для больших БД, исправлена. Обновление появится в D2.
Кому надо срочно - возьмите здесь...

Alio написал(а):
-------------------------------------------------------
> Ошибка в АРМе Администратор, связанная с
> многопроцессорной СОРТИРОВКОЙ (MULTISORT=1) для
> больших БД, исправлена. Обновление появится в D2.
> Кому надо срочно - возьмите здесь...

А в чем заключалась ошибка? Если в том, что ОЧЕНЬ долго сортирует, то у меня после обновления не изменилось.

Ситуация: есть сервер (виртуальный, но не суть) 16 ядер, 8Гб ОЗУ. запускаю "Создать словарь полностью" - стуртует 16 процессов IrbisMultiLoad, которые выполняют отбор, а затем сортировку своей части записей. Все это отрабатывает примерно за 7-9 минут (записей в базе около 90000). А потом основной процесс тупит с надписью "Выполняется сортировка" примерно минут 20. Такое впечатление, что он по новой сортирует все эти 16 кусков в один файл. Только вот зачем?? Они же отсортированы и надо только слить в один, а это делается простым скриптом на python'е за 12 сек на этом же сервере...


На 6-ти ядерном сервере - работает чуть лучше. В том смысле что финальная сортировка происходит быстрее.

Можно как-то это подправить?

Читайте релиз. Если ядер больше 2, использовать многопроцессорную сортировку НЕЦЕЛЕСООБРАЗНО, т.е. в этом случае надо устанавливать
MULTISORT=0

Alio написал(а):
-------------------------------------------------------
> Читайте релиз. Если ядер больше 2, использовать
> многопроцессорную сортировку НЕЦЕЛЕСООБРАЗНО, т.е.
> в этом случае надо устанавливать
> MULTISORT=0

Нецелесообразно??? Сортировать уже отсортированные файлы НЕЦЕЛЕСООБРАЗНО!

MULTISORT=0 - это "костыль"

И, кстати, по умолчанию параметр MULTILOAD надо выставлять на единицу меньше чем кол-во ядер/процессоров ибо основной процесс, пока ждет грузит одно ядро на 100% (что он там делает-то??)

Однако...

Чтобы не быть голословным, провел несколько тестов.
Тестировалась две БД, на нескольких серверах.
В колонке "сортировка" в скобках указано время за которое выполнялась сортировка
процессами IrbisMultiLoad.exe (засекал секундомером с телефона)
В колонке "Итого" в скобках время отбора+время сортировки в скобках+время
загрузки + 15 сек (примерно сколько надо чтобы слить все файлы в один)

Был также написан скрипт, на python'е, который определяет кол-во процесоров в
системе, кол-во записей в БД, затем запускает нужное кол-во процесов
IrbisMultiLoad с указанием какую часть обрабатывать, после их завершения делает
слияние всех файлов в один и запускает пакетное задание на загрузку словаря.
Результат работы в строке с "MULTYSORT=2"

%1 - % времени относительно однопоточной работы
%2 - % времени относительно "реконендованой" настройки многопоточной работы

БД 88805 записей

Сервер 1: 6 ядер, 8Гб ОЗУ, не виртуальный [win2003 R2 sp2](загруженный работой)
Вариант                   Отбор  Сортировка   Загрузка  Итого          %1            %2
MULTYLOAD=6, MULTYSORT=0  09:18  01:59        00:18     11:35          24.5%         100%
MULTYLOAD=6, MULTYSORT=1  09:23  03:02(00:26) 00:18     12:43(10:22)   26.9%(21.9%)  109.8%
MULTYLOAD=0, MULTYSORT=0  45:01  01:55        00:20     47:16          100%          408%
MULTYLOAD=6, MULTYSORT=2  09:39  00:15        00:19     10:13          21.6%         88.2%

Сервер 2: 16 ядер, 8Гб ОЗУ, виртуальный [win 2008 R2 sp1](работает только ирбис,не считая соседних ВМ)
MULTYLOAD=16, MULTYSORT=0 10:45  04:59        01:08     16:52          18.1%         100%
MULTYLOAD=16, MULTYSORT=1 10:48  21:54(00:33) 01:08     33:50(12:29)   36.2%(13.4%)  200.6%
MULTYLOAD=0,  MULTYSORT=0 87:24  04:52        01:07     93:23          100%          553.7%
MULTYLOAD=16, MULTYSORT=2 11:04  00:42        01:14     13:00          13.9%         77.1%

БД 174351 запись

Сервер 1: 6 ядер, 8Гб ОЗУ, не виртуальный [win2003 R2 sp2](загруженный работой)
MULTYLOAD=6, MULTYSORT=0                                27:50                        100%
MULTYLOAD=6, MULTYSORT=1                                30:51                        110.8%
MULTYLOAD=6, MULTYSORT=2                                19:31                        70.1%

Сервер 2: 16 ядер, 8Гб ОЗУ, виртуальный [win 2008 R2 sp1](работает только ирбис,не считая соседних ВМ)
MULTYLOAD=6, MULTYSORT=0                                41:25                        100%
MULTYLOAD=6, MULTYSORT=1                                не тестировал,будет явно хуже
MULTYLOAD=6, MULTYSORT=2                                28:51                        69.7%

Как можно увидеть, многопоточная работа дает существенный прирост производительности, вот только сортировка подкачала...
Выиграш при использовании оптимального алгоритма сортировки составляет от 11.8% до 29.9% в зависимости от объема базы.
На одинаковом объеме, но разном кол-ве процесов получаем от 11.8% до 22.9%.

Реализация такого алгоритма - очень простая, вполне можно сделать за один день. И выиграш не такой и маленький :)

Самый ресурсоемкий просесс - это отбор записей. И тут тоже есть что оптимизировать. Правда результат предсказать
сложно, да и насколько это будет затратно, в плане разработки тоже. Одно точно могу сказать - хуже не будет и как минимум несколько % можно вииграть

Еще возник вопрос по этой версии - при работе с периодическими изданиями на некоторых профилях пользователей нет оперативных режимов. На одном и том же компьютере - под одним профилем есть они, под другим - нет.С чем это может быть связано?

> С чем это может быть связано?
Совсем другая тема, однако.
Если разрешение экранов разные у разных пользователей, то, банально, оперативные режимы просто ушли "за экран". Нужно увеличить разрешение и "притянуть" их в размер экрана.

Спасибо, так и оказалось, удаление секции [DESKTOP] в файле cirbisc.ini ни к чему не приводило.

Здравствуйте. У нас возникла такая проблема. После установки Ирбис64 2012.1 и копирования наших баз не работает АРМ Каталогизатор, а точнее пишет "Демоверсия завершила работу". Переходим на Тестовую БД записи видны, переходим опять на наши БД выдает ошибку. БД содержат записи минимум по 5-6 тыс. На форуме читал: "Демоверсия имеет ограничение ТОЛЬКО на объем БД - сейчас это величина 1111". Может быть где-то прописано это ограничение, если да, где его можно поменять? Остальные АРМы открываются и работают без проблем.



Редактировано 1 раз. Последний раз 08.12.2012 13:02 пользователем Muratt.

Виноват - по ошибке в последние дистрибутивы 2012.1 попала ДЕМОверсия АРМа Каталогизатор. Обращайтесь на alio@gpntb.ru

Спасибо большое. Все работает.

Здравствуйте. Может уже была где-нибудь данная тема, но к сожалению не нашел. После обновления Ирбис 64 2012.1 D1, не можем вывести стат.форму в Каталогизаторе Form5, выдает ошибку "Нет заданного РЛ подполей". Скажите пожалуйста в чем проблема?



Редактировано 1 раз. Последний раз 21.12.2012 06:58 пользователем Muratt.

Проблема решена. Файл 1000.wss отсутствовал в папке Deposit.