У нас Ирбис 64, версия 2006.2 В работе 10 каталогизаторов постоянно происходят зависания :( Бывает, что на несколько минут (кошка бежит), а бывает, что и через несколько часов ничего не отвисает, хотя в диспетчере задач написано, что приложение работает, а на самом деле - песочные часы :( Другими приложениями при этом можно спокойно пользоваться, т.е. сам комп не виснет.. Про параметры сети сейчас сказать не могу, спрошу точно все у админа, который утверждает, что с сетью все ок - и скорость и прочее.. Зависания происходят, в основном, при заполнении таких полей, как ключевые слова и другие, которые используют при заполнении эти огромные самопополняющиеся словари.. Записей около 7000 в базе.
У кого такие же проблемы есть или были, отзовитесь!!! Подскажите, как решать эту проблему.
Заранее благодарны :)
P.S. Еще я поняла, что наш сервер является контроллером домена, а где-то я читала, что это не есть хорошо для работы системы :( не могли бы подсказать, почему?

Каково значение параметра MaxBriefPortion в INI-файле Каталогизатора?

Контроллер домен не есть гуд, поскольку на компьютер ложится серьезная нагрузка во время работы сотрудников. Это может сильно тормозить работу Ирбис. К тому же в качестве контроллеров домена редко ставят мощные компы. Они чаще маленькие немощные и старые :).
Еще рекомендую для вашей базы данных провести реорганизацию файла документов и файла словаря, используя соответствующие режимы АРМа Администратор.

Попросите администратора посмотреть, есть ли место на диске, где "СВОП" работает.
Кроме этого - проверьте антивирус, на время пусть приостановят и посмотрите, лучше ли стало? Бывает, что при незначительных ошибках в маршрутах антивирус "гробит" пакеты.

Alio написал(а):
-------------------------------------------------------
> Каково значение параметра MaxBriefPortion в
> INI-файле Каталогизатора?

Спасибо всем, что откликнулись :)
Но, если можно, поподробнее ;)

MaxBriefPortion = 3, что это означает? Что нужно поставить?

Поставьте 20 хотя бы. И посмотрите на результат.

Нет, нет...
Увеличение MaxBriefPortion ведет к замедлению обмена между клиентом и сервером...

А 3 - это разве не совсем мало? Мне казалось, что 20 - это оптимальное число. В таком случае не могли бы вы, Александр Иосифович, по подробнее описать, на что влияет этот параметр в техническом плане, а то мне кажется, что я его не до конца понимаю?

> Еще рекомендую для вашей базы данных провести
> реорганизацию файла документов и файла словаря

Про контроллер домена все поняла, попробую еще раз помучать системщиков, объяснить им, что это не есть гуд ;)

Реорганизацию делаем раз в месяц, а с какой периодичностью нужно это делать?

Раз в месяц вполне достаточно.

Карауш написал(а):
-------------------------------------------------------
> Попросите администратора посмотреть, есть ли место
> на диске, где "СВОП" работает.
> Кроме этого - проверьте антивирус, на время пусть
> приостановят и посмотрите, лучше ли стало? Бывает,
> что при незначительных ошибках в маршрутах
> антивирус "гробит" пакеты.

Спрошу :) А что такое СВОП?
Антивирус стои Касперский, убирала Ирбис на всякий случай из мест сканирования. Все равно виснет :(

Цитата:

ovkuz
А что такое СВОП?

[ru.wikipedia.org]

Сделали сервер просто файловым сервером, а не доменом, все проблемы разрешились :)

Недавно переустанавливали систему, так как закупили АРМ книгообеспеченность, обновились до версии 8.1. После этого регулярно (каждое утро, примерно через час работы) происходит всеобщее зависание. Перезапускаю сервер_ирбис, все отвисает и работает целый день нормально. Нагрузка сейчас минимальная, найти причины так и не удалось :( Может быть, подскажете, где полазить, чего посмотреть?

То же самое - irbis_server.ini, конфигурацию сервера и сети на moro@omsu.ru.

99% случаев приводящих к зависанию сервера решается настройкой irbis_server.ini

Михайленко Илья написал(а):
-------------------------------------------------------
> То же самое - irbis_server.ini, конфигурацию
> сервера и сети на moro@omsu.ru.

Простите, что входит в эту конфигурацию, какие данные нужны, я спрошу у наших админов.

Нужен сам файл irbis_server.ini - это обязательно.

Конфигурация сервера - кол-во и какие процессоры, сколько памяти, какая дисковая подсистема, какие сетевые платы/интерфейсы установлены. Так же нужна версия, платформа и сервис-пак операционной системы и, по возможности результат вывода команды ipconfig /all. Так же желательно указать используется ли сервер как сервер терминалов для клиентов ИРБИС.
Это очень желательно, но НЕ обязательно. Эта информация, надеюсь, поможет воссоздать условия возникновения проблемы и решить ее.

Спасибо Илья за разъяснения :) Наш системщик в отпуске, но я попробую сама все это посмотреть и прислать на Ваш адрес :) Будем очень благодарны, если подскажете, как правильно настроить работу системы :)

Илья, высылаю на Ваш адрес все, что удалось узнать у админов и файл.
Зависания продолжаются :( Раз в день, независимо от того, работает в этот момент кто-либо или нет. Очень надеемся на Вашу помощь :)

Михайленко Илья написал(а):
-------------------------------------------------------
> Конфигурация сервера - кол-во и какие процессоры,
> сколько памяти, какая дисковая подсистема, какие
> сетевые платы/интерфейсы установлены. Так же нужна
> версия, платформа и сервис-пак операционной
> системы и, по возможности результат вывода команды
> ipconfig /all.

Много раз спрашивают какие системные требования у Ирбиса. Еще раз спрошу в связи с возможным обновлением сервера: Какие желательные характеристики для сервера? Имеющиеся объемы больших баз данных:
1-ая БД: 120 000 записей
2-ая БД: 320 000 записей
3-яя БД: 800 000 записей

Рабочих мест - 25.

Поделюсь своим опытом.
С ИРБИСом 64 наша библиотека работает с 2007, за весь период ИРБИС начинал на долго "бегать" два раза и оба раза связаны исключительно с реструктуризацией сети, а именно с проблемами DNS в сети. Мудрые админы скажут, где тут связь, если обращение к ИРБИС серваку идет по IP, мы сами по началу бились, но оба раза при восстановлении нормальной работы DNS в сети, вопрос с бегущим ИРБИСом решался тут же сам сабой. Причем плохо работающий DNS на работу самой сети влиял не очень, а вот на ИРБИС это действовало болезненно.
X( Теперь, когда начинают звонить в отдел автоматизации разъяренные библиотекари, верная примета - загляни в работу DNS. :)
Сеть с контроллером домена под 2003 на 150 рабочих мест, около 100 с ИРБИСом.
Всем УДАЧИ!

АНАЛОГИЧНАЯ ПРОБЛЕМА с подвисанием клиентов.
Приобрели недавно Ирбис 64 2009.1.
Поначалу тестовый период работало нормально. Но
после основных переноса баз данных данных на сервер
начались подвисания и торможения работы клиентов.
Пингуется сервер не очень хорошо - есть потерянные пакеты(где-то 1 из 4).
Антивирусник отключал - тоже самое.

С чем это может быть связано, кроме проблем с сетью?
(завтра сеть постараюсь проверить-перенесу сервер поближе к клиентам)
И еще - какие службы влияют на работу сервера Ирбис 64?
может это быть из-за некорректной работы какой-то из
системных служб?

Очень большая просьба помочь, т.к. работа почти стоит.
Все необходимые файлы могу выслать по электр. почте.

Прямая зависимость от сети. Нужно сеть править. При пинге 3/4...
Нужно искать где теряются пакеты - смотрите внимательно железо (включая сами каналы связи) которое стоит на пути между клиентом и сервером в соответствии с роутингом пакетов, а так же нагрузку на это железо.
Когда до СУБД доходит только 3 из 4 пакетов...

Проблема с зависанием АРМа Комплектатор. При работе с книгами, в которых внесены несколько сотен экземпялров, при попытки довнести в них новые начинает бежать барсик. Барсик бежать не перестает и после получаса ожидания (в записи были внесены 600 экземпляров, хотели внести еще 3 из новой партии). Ситуация одинаковая хоть на клиентских машинах, хоть на сервере. При этом АРМ Каталогизатор, вызванный из Комплектатора, Тянет на себя 100% Процессорной мощности.

С Каталогизатором проблем почти не бывает. Крайне редко когда начинает бежать Барсик. Зачастую не более минуты-полторы.

Может стоит как-то переделать проверку ФЛК записей? Когда смотрел эту запись и ее проверку на ФЛК в Редакторе форматов, то на расформатирование книги с 200-ми экземплярами уходила до 6000 милисекунд. И это при том, что Редактор форматов работает в обход Сервера и всех его обработок.

Сеть в библиотеке 100 Мбит, сервер стоит в другом корпусе. Между библиотекой и сервером лежит оптоволокно. У нас лицензия на 15 пользователей, но чаще работают 9-12 человек.

Если много книг с большим количеством повторений, то могу рекомендовать следующее: доработать соответствующие ФЛК так, чтобы они не производили проверки поля, если количество его повторений больше какого-то числа, заданного, к примеру, в персональных настройках пользователя.
Думаю такая оптимизация в вашем случае просто необходима. Правда делать это можно только в ФЛК. Не стоит забывать, что поле с экземплярами так же обрабатывается и для словаря. И не удивлюсь, если не только в одном месте. И везде будет тратиться по нескольку секунд на итерации по 910 полю. Значит для ускорения можно отключить автоматическую актуализацию при сохранении. Тогда придется оставить на сервере рабочий Администратор с функцией автоактуализации при проверке базы.
Попробуйте, может строит результат.

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

Мдас. не завидую. Кажется мне, что необходимо доработать основные форматы Ирбис для подобных случаев.
Гена, есть желание написать заметочку "Как жить, если экземплярность велика?" и прописать там практические рекомендации по оптимизации.

Переделал форматы отображения записей, ФЛК поля 910 и ФЛК записи в целом. Запись на корректировку брать стало легче, уже не тормозит при входе на запись с большим количеством экземпляров. Но! После обработки и нажатии кнопки "Сохранить" все равно все уходит в далекий и глубокий ступор. Опытным путем выяснил, что сам сервер все же отрабатывает и завершает операцию, но дописывание 30 экземпляров в книгу с уже имеющимися 600-ми экземплярами может длиться пол часа. АРМ виснет на клиентской стороне, инициализирующей сохранения, сервер Ирбиса перехватывает 100% процессорного времени на сервере библиотеки, остальные пользователи сидят и ждут, пока сервер сможет обработать запрос Комплектатора, так для на их запросов уже не остается мощности сервера.

На сервере сейчас стоит ини файл, который выкладывал Илья

Если при сохранении барсик начинает бежать и нажать кнопку "Отмена", то программа корректно возвращается к работе, но никакие изменения в записи не происходят. В это время другие клиенты все же работать могут. Значит сервер все же отвечает на запросы.

У нас такая проблема происходит только при работе с записями, в которых очень большое кол-во повторений каких-либо полей. Пока что это проявляется только в учебниках, которых больше 300-400 номеров и в сборниках, для которых росписывается оглавление, в них бывает и по 170-250 записей. Но есть же перспектива Книгообеспеченности, а там будет совсем тяжко. Возможно стоит пересмотреть именно фст файлы, прибегнуть к сохранению меньшего количества информации. К примеру, ограничиться одним уникальным термином из ряда повторяющихся(номер КСУ сохранять не из всех, а только записей, а только по одному оригинальному). Как вы думаете, на подобное расформатирование результатов ФСТ будет уходить больше времени, чем на сохранение всех 2000 тысяч ссылок на номер ксу, при условии, что оригинальных номеров КСУ всего 3-5?


Ирбис 64, 2009.1



Редактировано 1 раз. Последний раз 11.02.2010 10:44 пользователем Gena.

> АНАЛОГИЧНАЯ ПРОБЛЕМА с подвисанием клиентов.
> Приобрели недавно Ирбис 64 2009.1.
> Поначалу тестовый период работало нормально. Но
> после основных переноса баз данных данных на сервер
> начались подвисания и торможения работы клиентов.
> Пингуется сервер не очень хорошо - есть потерянные пакеты(где-то 1 из 4).
> Антивирусник отключал - тоже самое.
с СЕТЬЮ ВСЕ НОРМАЛЬНО - НАЛАДИЛИ...
ПИНГИ СЕЙЧАС ОТЛИЧНЫЕ. ИРБИС ПО ПРЕЖНЕМУ ПОДВИСАЕТ
ПРИ ЗАГРУЗКЕ (загрузка процессора у клиентов до 100%) -
НУЖНА ПОМОЩЬ Т.К. РАБОТА СТОИТ!!!