Здравствуйте
Мы столкнулись с ошибкой в службе Generic Host Process for Win32 Services, было установлено обновления для сервера. Что позволила успешно работать дальше. После того как устранилась эта ошибка. Произошло зависания Ирбиса! На этом же сервере установлена антивирусная система Symantec! Тогда посоветуйте что теперь делать?
У нас Ирбис64 (7,2).

Ответ Вам уже был дан:
[irbis.gpntb.ru]

Здравствуйте Илья.
Долго меня не было, потому что выяснял где "собака зарыта"...

Ранее я писал что у нас виснет ирбис, сейчас я опишу все проблему по порядку:

Сначало о платформе.Сервер Крафтвей 2 процессора Ксеон и 4 гига памяти, на нем стоит сервер 2003 R2 стандарт sp2 и все обновления, стоит ирбис , архиватор и пожалуй все. Был NOD антивирус ,но я по совету Кирилла Соколинского его деинсталировал.

Зависает сам tcp/ip сервер , в процессах irbis_server.

Пробовал через службу, тоже самое - зависает.(при этом tcp не запускал но ирбис на клиентах работал)

Как проявляется сие действо...начинает бежать барсик сразу у всех пользователей, независимо от запущенного у клиента АРМа.

Прикрепляю скрины экрана сервера и ини файл, для просмотра , помогите, надо работать а мы перезагружаемся по пять и более раз на дню.

И медленно работает по сравнению с 7 версией, там все было быстрей.

С уважением Евгений.

И самое главное ирбис 9.1 без веб(еще не успел поставить)

Умный знает как исправить ошибку, а мудрый знает как её не допустить!!!



Редактировано 1 раз. Последний раз 30.10.2009 09:14 пользователем ferrum.

Да и совсем забыл...
Подскажите какой антивирус нормально работает с ирбисом?
Без антивируса сервак долго не протянет.

Умный знает как исправить ошибку, а мудрый знает как её не допустить!!!

Жалко что на фотографии 29102009(003).jpg не видно последнего исполнившегося процесса (на какой команде собственно повесился)...

Попробуйте:
1. Убрать (или закомментировать) строки
#сигнал окончания процесса обработки посылается через TCP, а не как сообщение windows
LISTEN_RESPONSE=0
IP_PORT_LOCAL=7778
#процесс обработки выполняет сетевое чтение/запись
DUPLICATE_SOCKETS=0
#обмен между процессами обработки и ядром сервера - через системную память (1)
#или через временные файлы в рабочей директории workdir
DUP_MAPING_WORK_FILES=0
#размер системной памяти выделяемой процессу, Kb
Dup_MappingFileSize=100
#число процессов обработки стартуемых сервером при запуске
Dup_ProcessCountPull=0
#сигнал окончания процесса обработки регистрируется в WINDOWS
RegisterWindowMessage=1
...
#обязательно включать при многопоточном режиме!
PROCESS_THREADS_MONITOR=3
...
#УПРАВЛЕНИЕ ЦЕЛОСТНОСТЬЮ СЕТЕВОГО ЧТЕНИЯ/ЗАПИСИ
#Эти параметры эффективны для терминальной работы клиентов
#время ожидания завершения передачи по сети в ms, если 0 - нет ожидания
#по умолчанию=1
TimeSleepOnClose=0


2. ДОБАВИТЬ в секцию [MAIN]
FORMAT_DECOMPILED=0

----------------
1. - Это в основном косметика - параметры, которые не нужно использовать в текущем режиме работы (например, PROCESS_THREADS_MONITOR выставлен в 3 при том что потоки отключены вовсе, все выполняется в отдельном от основного ядра процессе и, как следствие, мониторить просто нечего).
"Косметика" - потому как сервер проверяет возможность использования тех или иных параметров и приведенном примере просто его игнорирует.


2. Вешается скорее всего из за отсутствия
FORMAT_DECOMPILED=0
в секции [MAIN]

По антивируснику:
Подойдет любой антивирус, монитору (проверялке "на лету") которого можно прописать исключения - т.е. объяснить ему что папку IRBIS64 и все подпапки и файлы в них проверять на вирусы не надо. В том числе и exe-файлы сервера ИРБИС, т.к. некоторые из них используются для обработки запросов (особенно активно server_64.exe - это процесс обработки команд клиента).
По мониторам сетевой активности более определенно сказать что либо трудно - у меня мало статистики использования от пользователей. Но если порты открыты и антивирус не корежит пакеты то проблем быть не должно (кроме некоторого замедления ответа при проверках антивирусником - но тут выбор между безопасностью и скоростью)

Просьба: если поймаете подвешивание еще раз - пришлите мне скрин окошка списков процессов висящего сервера (Alt+Print Screen и затем Shift+Ins в Paint'е). Хотелось бы видеть все колонки - это даст мне информацию о команде в процессе исполнения которой произошел сбой.

Илья, ты не ошибся насчет
FORMAT_DECOMPILED

м.б. все-таки
FORMAT_CASHABLE

Надеюсь, что ошибся.

Оба параметра должны быть в 0. По крайней мере уже в 2 случаях помогло выставление именно этого параметра в 0. Понять это трудно, особенно учитывая что FORMAT_DECOMPILE по-умолчанию и так FALSE. Мое внутреннее убеждение - это лишь совпадение, не связанное с этим параметром, а вызванное какими-либо другими причинами, но решил все же проверить... В обоих случая зафиксировать и воспроизвести ситуацию, при которой этот параметр может вешать сервер мне на своем тестовом стенде так и не удалось :( В обоих случаях, как и в этом по сути это был единственный параметр отличающийся от эталонного ини-файла.

У меня сейчас 8 тестовых систем, собранных под виртуальными машинами - 2008,Vista, 2003 и XP, платформы и x64 и 86. Плюс 2 сервера под реальной работой - 2008 x64 в НБ ОмГУ и 2003 86 в НБ ОмГТУ. На обоих реальных серверах нагрузка весьма значительная. На обоих стоит эталонный ини без каких-либо правок (кроме process_time_live в НБ ОмГТУ - на их базе задача построения формы КО в 15 минут не укладывается, после чего сервер в соответствии с этим параметром решает что процесс "завис" и насильно его убивает)

Все сделал как сказали, но повис...
Прикрепляю prn scr экрана.
Еще приходится бегать на сервер, так как клиент виснет.

Умный знает как исправить ошибку, а мудрый знает как её не допустить!!!

И еще вопрос, у меня 8 филиалов и они через инет включаются.
>>LISTEN_RESPONSE=0
>>IP_PORT_LOCAL=7778
А для них на роуторе только 6666 порт мапинг, получается 7778 тоже нужен?

И чтобы не вис нужно чтобы ирбис больше 15 минут без работы не стоял, сам он висячих клиентов не рубит.
Проверено, и я сам как админ их рубануть не могу, хотя пишу удалить клиента, а он висит, прошу обновить список зарегенных , а он не обновляется, схожу на серверную перезапущу сервер ирбис, тогда нормально.

Ситуация для меня совсем невероятна.
Напишите мне на moro@omsu.ru
Если есть аська или скайп - поделитесь для более оперативной связи.

Отправил по почте асю.Скайп тож есть

7778 не надо. Этот порт если и используется то только в рамках одного сервера. В Вашей конфигурации порт не используется вовсе.

Илья, здравствуйте!
Договаривались мы сегодня (5 11 2009) потестить и понастраивать ирбис.
Но не дождался.Видать заняты более насущными проблемами.
Доступ я не закрывал, на рабочем столе оставил скрины при подениях.
Хотя наврядли они вам помогут.
Ирбис зависал переодически.За рабочий день 8 раз.
Жду помощи!!!
С уважением Евгений, Усть-Илимская ЦБС.

Умный знает как исправить ошибку, а мудрый знает как её не допустить!!!



Редактировано 1 раз. Последний раз 05.11.2009 12:05 пользователем ferrum.

Евгений, здравствуйте!
Я 5 и 6 вне рабочего места оказался :(
Давайте на понедельник теперь...

я постараюсь создать нагрузку в понедельник.
В какое время?

Умный знает как исправить ошибку, а мудрый знает как её не допустить!!!

Остальные клиенты при этом тоже зависают. Версия 2008.1

Это Вы о чем?..

Михайленко Илья написал(а):
-------------------------------------------------------
> В аттаче ini-файл который пока демонстрирует
> устойчивую работу на всех системах.
>
> В прилагаемом ini-файле необходимо поменять путь к
> системе ИРБИС с d:\irbis64 на ваш!!!
>
> Что в нем критического:
> 1. Отключено кеширование форматов.
> (FORMAT_CASHABLE=0, FORMAT_DECOMPILED=0)
> К сожалению не на всех конфигурациях это
> кеширование работает корректно.
> Отключение кеширования это незначительный минус к
> скорости и достаточно большой плюс к надежности.
> Проявляется как периодическое (до нескольких раз в
> день) подвисание всего сервера.
>
> 2. Отключено определение имен клиентов сервером
> (RECOGNIZE_CLIENT_ADDRESS=0)
> Если сеть "тяжелая", с большими по размеру
> подсетями либо сетями в которых разрешение имен
> NetBIOS и DNS проходит медленно, то при загрузке
> появляется подвисание всего сервера. (В нетбиосе
> некоторые операции блокирующие). Выражается это в
> долго бегущем мурзике на клиентах при открытии.
>
> 3. Обмен между процессами обработки и сервером
> происходит через файлы на диске.
> (MAPING_WORK_FILES=0)
> Минус к скорости, плюс к надежности. При обмене
> через память необходимо знать сколько памяти
> предоставить процессу обработки (есть
> ссответствующий параметр в ини MappingFileSize, по
> умолчанию 10 Мб). На "тяжелых" запросах возможна
> ситуация когда результат работы процесса обработки
> просто не помещается в эту область памяти.
> Особенно проявляется при работе с "тяжелыми"
> задачами АРМ книгообеспеченности. Выражается в не
> до конца выполненных глобальных корректировок,
> подвешивании отдельных АРМ (которым приходит такой
> урезанный пакет). Особенно актуально ВУЗовским
> библиотекам.
>
> Если возникают "проблемы с сервером", то нулевое
> что нужно сделать - это из АРМ Администратор
> проверить на корректность базы данных - не
> порушилось ли что где. Сервис->Диагностика файла
> документов и Сервис->Диагностика файла словаря
>
> Первое что необходимо сделать это убедиться в
> отсутствии причин, не связанных с самим ИРБИС:
>
> 1. Надежность и скорость сети.
> ИРБИС64 нацелен на использование локальных сетей и
> болезненно относится к недоставке пакетов по сети.
> В нормально работающей локальной 100 мегабитной
> сети проблемы с недоставкой пакета очень большая
> редкость и, чаще всего, связана с аппаратными
> неполадками в сети. Если проблемы с доступом к
> серверу у конкрентного клиента, то выглядит это
> как бегущий кот у проблемного клиента при
> нормально работающих остальных клиентах. Строго
> говоря, если есть хоть один работающий клиент в то
> время как остальные клиенты висят - проблема уже
> не в сервере - сервер работает и отвечает. Таким
> образом можно проверить на надежность и сегмент
> сети сервера - запустить локально на сервере
> клиента. Если работает - ковырять сеть.
>
> 2. Фоновые задачи резервного копирования
> Если вы делаете резервное копирование методом
> прямого копирования файлов БД, убедитесь что ни
> один клиент не производит запись в БД. В противном
> случае рискуете получить и битый бекап и битую
> БД.
>
> 3. Права доступа.
> Убедитесь что пользователь, под которым работает
> ИРБИС (в виде сервиса или как приложение) имеет
> полные права на свой каталог. Обратите внимание на
> "Административные" режимы в Висте и 2008, а также
> их трепетное отношение к системному диску. Лучше
> всего держать ИРБИС не на системном диске (т.е.
> если windows установлен на С, то ИРБИС ставить на
> D). При недостатке прав сервис не запустится с
> кодом ошибки 1111.


Можно ли использовать прикрепленный irbis_server.ini для И64 2010.1?

Цитата:

Esil
Можно ли использовать прикрепленный irbis_server.ini для И64 2010.1?

Да. Только проверьте корректность путей в ini-файле