У нас проблема тоже осталась. Отключили от ИРБИС некоторые филиалы, но результаты не радуют. Такое впечатление, что любой филиал может подвесить ИРБИС. А к тому же у нас уже законсервирована картотека статей и книг несколько лет, филиалы остались с пустыми руками. При такой нестабильной работе ИРБИС о книговыдаче не может быть и речи, а мы вплотную подошли к електронному варианту книговыдачи. Никакого продвижения в работе нет, топчемся на месте. Что делать. Хотелось бы получить результативный совет.

К вопросу о том что виновата сеть:
ну вот в филиале подвис клиент, запускаю каталогизатор на компе с сервером и та же ошибка (10053), помогает онли перезапуск - в этом случае тоже виновата сеть? по моему один клиент не должен страдать от того что проблемы у другого

Хотелось бы чтоб было поправлено как можно раньше. тк с 2007ой версий не было таких проблем

CheGevara29 написал(а):
-------------------------------------------------------
> К вопросу о том что виновата сеть:
> ну вот в филиале подвис клиент, запускаю
> каталогизатор на компе с сервером и та же ошибка
> (10053), помогает онли перезапуск - в этом случае
> тоже виновата сеть?
...

[irbis.gpntb.ru]

Такая же проблема. Подвисает программа, выдается сообщение об ошибке. У нас Ирбис64 2010.1, D6. Сначала подвисание было раз в неделю, потом чаще, сейчас каждый день. На сервере только Ирбис и Web-ирбис. У нас уже налажена электронная книговыдача. Очень мешеает работе это подвисание, т.к. приходится перезагружать весь сервер. У нас электронная выдача была еще на Ирбис64 2009. Таких проблем не было. Да и в сентябре, когда была групповая выдача и загруженность была полная, подвисал раз в неделю, а сейчас без нагрузки каждый день. Может это все же ошибка в версии 2010, а не в настройках сетей?

И еще такой вопрос: может Apach подвешивать систему? Такой вопрос возник, т.к. после перезагрузки сервера в журнале событий выходит сообщение об ошибке. Источник Apache Service. И это сообщение по времени совпадает с подвисанием системы.

Если Вы утверждаете, что на 2009 версии все работало нормально, то проведите эксперимент - верните на сервере все исполняемыe модули к версии 2009 и посмотрите, что получится
Подменить следует следующие файлы:
irbis_server.exe
irbis64.dll
server_64.exe

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

Укажите даты создания для ЭТИХ трех файлов версии 2010.1

У меня стоит обновление D6 для 2010.1.
irbis_server.exe - 21.06.2011
irbis64.dll - 29.08.2011
server_64.exe - 29.08.2011

В системе ИРБИС64 версии 2010.1 не запускается служба Irbis64_Servis (servis_64.exe от 13.12.2005) - появляется
ошибка 1111 - и мы вынуждены запускать систему как приложение.
Другие файлы:
irbis_server.exe - 17.05.2011
irbis_64.dll - 16.05.2011
server_64.exe - 19.04.2011.
эти три .еxe файлы, указанные на форуме (см. вложение1) я не нашел в обновлении D6
для версии 2010.1.

Это происходит из-за отсутствия прав у приложения на папку ИРБИС64 и все ее подпапки.
Дело в том, что когда Вы запускаете ИРБИС как приложение, он запускается с правами текущего пользователя (под которым Вы вошли в операционную систему). Когда запускаете как сервис, ИРБИС запускается (по умолчанию) от имени учетной записи SYSTEM.
Варианта решения два: либо учетной записи SYSTEM выдать необходимые права на папку ИРБИСа, либо сервис ИРБИСа запускать от имени другой учетной записи (например, той из-под которой он запускается как приложение)

Аналогичная проблема с зависаниями. Канал проверяли неоднократно, стабилен, но скорость 256 кбит/с. В постах выше указана рекомендуемая минимальная скорость 10 Мбит/с. Могут ли зависания сервера быть связаны с низкой скоростью канала до филиалов?

Смотрите [irbis.gpntb.ru]

Я только начинаю работать с Ирбис поэтому не все понятно.
Для настройки клиентов, необходимо указать:
#IP или доменное имя сервера (library.gpntb.ru)
ServerIP=193.233.14.9
#Порт сервера. Стандартно для WEB серверов — 80
ServerPort=80
#Переключатель в режим HTTP
WebServer=1
#Путь к WebToIrbisServer.exe, который должен указываться относительно адреса сервера
WebCgi=/cgi-bin/irbis64r_91/WebToIrbisServer.exe

Эти (свои) данные вносятся в конце секции [MAIN]?

Да, и еще вопрос, какой клиентский ini имеется ввиду? Тот который лежит непосредственно на компьютере клиента и в нем необходимо изменить
ServerIP=192.168.1.250
ServerPort=6666
WebServer=0
WebCgi=

На указанные выше?

Клиентские ini - это файлы cirbis*.ini (из директории Clients).
В этих файлах следует изменить значения параметров ServerIP, ServerPort, WebServer, WebCgi в секции [Main].

Михайленко Илья написал(а):
-------------------------------------------------------
> Сейчас в качестве эксперимента доделываю шлюз,
> который именно так и обрабатывает запросы прежде
> чем послать их на сервер 64-го. Заодно мониторит
> обе стороны - и сервер и клиентов. Но это совсем
> другая скорость :( Для выявления проблем его
> использовать будет можно, для постоянной работы -
> нет.

Илья Иванович, скажите, пожалуйста, не готова ли тестовая версия шлюза?

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

Готов тестировать новый шлюз.

ЗЫ. По большому счету в процессе развития технологии наткнулись на похожие с Ирбис32 ограничения, когда слабый комп тормозил всех остальных. Только теперь слабым звеном является канал, а не сам компьютер. Можно было бы перекинуться на Ирбис128, но каталогизатор в нем пока что слабоват. А филиалы, на текущем этапе, работают только в нем.



Редактировано 4 раз. Последний раз 19.01.2012 10:31 пользователем Панев Максим.

В ответ на [irbis.gpntb.ru]

OksanaN написал(а):
-------------------------------------------------------
> Здравствуйте! У нас Ирбис 64.2010.1. Постоянно
> происходит подвисание системы. Пробую
> перестартовать сервер через АРМ
> Администратор-клиент, выдает ошибку: Asinchronous
> socket error 10051. В чем может быть причина, и
> что это за ошибка? Система подвисает каждый день,
> в разное время, приходится перезагружать весь
> сервер

Как сообщает MSDN (англ.), ошибка 10051 означает:
---
WSAENETUNREACH
10051
Network is unreachable.
A socket operation was attempted to an unreachable network. This usually means the local software knows no route to reach the remote host.
---

Перевод:
---
Сеть недостижима.
Попытка осуществить операцию с сокетом на недостижимой сети.
Обычно это означает, что программное обеспечение на локальном компьютере не может определить маршрут к удалённому компьютеру.
---

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



Редактировано 1 раз. Последний раз 19.01.2012 12:08 пользователем PRM.

Панев Максим написал(а):
-------------------------------------------------------
> Уже неделю наблюдаю,
> как сервер виснет на мертво и клиенты на сокет
> ругаются.

Максим Васильевич, ошибка 10053?

Попробовал запустить сегодня на своём ПК доступ через WebToIrbisServer. АРМ (Каталогизатор) открывается. Но, к сожалению, скорость работы в таком режиме меньше, чем в обычном.

На номер-то ошибки я и не посмотрел :). Да в общем-то ноги все равно из одного горшка растут.

Клиент соединяется с сервером, работает. Потом канал перегружается и получаются потери пакетов. Клиент отваливается с этой ошибкой.
Но параллельно (!!! ЭТО И ТРЕБУЕТСЯ ИСПРАВЛЯТЬ !!!) подвисает и TCP сервер. Он перестает отвечать на какие-либо другие запросы из сети по любым каналам связи. Все остальные клиенты со стабильным каналом связи считают, что проблема в сети, а проблема, на самом деле, в зависшем сервере. Именно подобное поведение сервера недопустимо. Это и требует исправления.

Ну и само собой пользователь должен видеть "Обнаружены проблемы в сети, попробуйте подключиться позднее". А вот "Async socket error" должен быть в логах. По крайней мере именно так, по моему скромному мнению, должен выглядеть процесс обработки ошибок.



Редактировано 1 раз. Последний раз 19.01.2012 15:15 пользователем Панев Максим.

А кто должен исправлять данную ошибку? И как?
ТСР сервер подвисает все же иногда. Уже не часто, но раз в два дня стабильно. И причем в начале рабочего дня, когда идет первый запуск АРМ Книговыдача.

Это исправление мы ждем от разработчиков.

Добрый день.

Панев Максим написал(а):
-------------------------------------------------------
>
> Ну и само собой пользователь должен видеть
> "Обнаружены проблемы в сети, попробуйте
> подключиться позднее". А вот "Async socket error"
> должен быть в логах. По крайней мере именно так,
> по моему скромному мнению, должен выглядеть
> процесс обработки ошибок.

Может быть, был бы полезным лог-файл сообщений об ошибках, которые выдавались на клиенте (об ошибках АРМ и об ошибках "Async socket error")?

OksanaN написал(а):
-------------------------------------------------------
> А кто должен исправлять данную ошибку? И как?
> ТСР сервер подвисает все же иногда. Уже не часто,
> но раз в два дня стабильно. И причем в начале
> рабочего дня, когда идет первый запуск АРМ
> Книговыдача.

Скажите, пожалуйста, а ошибка точно «socket error 10051»?
В момент появления ошибки компьютер – сервер ИРБИС пингуется (ping)?
Трассировка маршрута (команда tracert) к компьютеру – серверу ИРБИС выполняется нормально?

(
Михайленко Илья написал(а):
-------------------------------------------------------
> Большинство проблем, связанных с зависаниями
> сервера на сегодня связаны с механизмом передачи
> данных по сети: обрезка пакетов, неожиданный
> разрыв соединения и т.д. С версии 2010.1 сетевые
> ошибки уровня протокола tcp/ip стали показываться
> пользователям. Наличие таких ошибок говорит о
> проблемах в сети, которые администраторам
> необходимо решать.
)

В системных требованиях к ИРБИС 64 указана ЛОКАЛЬНАЯ вычислительная сеть. Сервер ИРБИС64 в силу своей архитектуры НЕ ПРЕДНАЗНАЧЕН для работы в условиях сети Интернет. Если Интернет-канал 100% устойчивый - работоспособность сервера так же будет приближаться к 100%.

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

Исправить эту ситуацию можно лишь сменив архитектуру системы, что, в общем-то, и происходит в ИРБИС-128.

Отдельно о зависаниях и "нормальных" ping. Нет смысла проверять сеть, запустив десяток-другой пинг-пакетов. Сервер 64-го ведь то же не за 10 пакетов падает и не каждые 2 минуты.
Для помощи системным администраторам, что бы дать им хоть какую-то информацию о том, что приводит к сбою на сервере, сейчас и выводятся на экран сообщения об ошибках winsock.
Еще раз напоминаю, что хоть эти сообщения и выводятся клиентами/сервером ИРБИС-64, сам ИРБИС к ним не имеет никакого отношения - это сообщения модуля операционной системы, отвечающего за сетевые коммуникации. Если появляются такие ошибки - не надо ничего "крутить" в ИРБИС - нужно искать неполадки на сетевом уровне.

Понял. Значит буду переводить филиалы на Ирбис128 принудительно.

Илья Иванович, спасибо.

Но не готова ли тестовая версия шлюза?

Решил чуток поиграть с параметрами сервера. Для начала изменил параметр
Dup_ProcessCountPull=10
Мало ли поможет. Но вот после старта сервера я не увидел 10 процессов server64.exe, которые бы ждали клиентов. Где-нибудь описано подробнее, что означает и к какому эффекту приводит использование всех параметров irbis_server.ini?

Панев Максим написал(а):
-------------------------------------------------------
> Решил чуток поиграть с параметрами сервера. Для
> начала изменил параметр
> Dup_ProcessCountPull=10
> Мало ли поможет. Но вот после старта сервера я не
> увидел 10 процессов server64.exe, которые бы ждали
> клиентов. Где-нибудь описано подробнее, что
> означает и к какому эффекту приводит использование
> всех параметров irbis_server.ini?

Думаю, это "Сервер 64.doc" (п. 5.2.9).
Dup_ProcessCountPull работает, если DUPLICATE_SOCKETS=1, DUP_MAPING_WORK_FILES=1?

Ой, и правда. Спасибо, за подсказку.

UPD. Параметры сработали. Поставил 10 из соображения "по одному процессу на клиента + бонусы если что-то повиснет и придется переподключаться". Будем ждать результата.



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

Сообщаю о результатах тестирования. Клиенты все равно отвалились. Но уже с ошибкой -1112. Сервис на сервере успешно остановился и стартовал (при прошлых настройках процессы приходилось убивать из диспетчера). Так что можно сказать, что эксперимент с пулом процессов несколько упростил жизнь. Но не избавил от проблем.