ALIO,

Вы имеете ввиду на сервере в IRBIS64\DATAI\ директорию SPRV?
Нет,такой нет

2Esil
Что есть "одним кабелем(комп->комп)"? nul-modem через ком-порты? Если так, то скорсть такого соединения максимум 115kbps (а при неудачной настройке и вовсе 9,6kbps) вместо 10-100Mbps рекомендуемых...

НЕТ, как обычно через разъем RJ45 и скорость была 1 Gb.!

Цитата:

Esil
НЕТ, как обычно через разъем RJ45 и скорость была 1 Gb.!

Без коммутирующего оборудования? Или нуль-модемный шнур UTP (Rx и Tx скрещены)? Или отстаю от жизни и сетевые теперь умеют договариваться кто их них Rx а кто Tx на каждой линии пары? Не совсем понял как именно Вы соединили 2 компьютера.

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

Как же Вам объяснить, соединил два компьютера напрямую бех хаба, с помощью сетевого кабеля (витая пара обжатая "кроссовером").Архив отправлю вам на почту.

Цитата:

Esil
витая пара обжатая "кроссовером"

Вот это понятно.
Жду.

PRM написал(а):
-------------------------------------------------------
> Ещё же есть рекомендации Александра Иосифовича в
> теме "Вниманию пользователей ИРБИС64 2009.1" (
> [irbis.gpntb.ru] ):
>
> Alio написал(а):
> --------------------------------------------------
> -----
> > Еще одна важная рекомендация для пользователей
> > ИРБИС64 - связанная с работой TCP/IP сервера
> > ИРБИС64
> >
> > При больших нагрузках на сервере (десятки
> > одновременно работающих пользователей):
> >
> > 1.Запускать сервер как СЛУЖБУ
> > 2.НЕ СЛЕДУЕТ НЕПОСРЕДСТВЕННО НА СЕРВЕРЕ вести
> > наблюдение за работой сервера через окна СПИСОК
> > ЗАРЕГИСТРИРОВАННЫХ КЛИЕНТОВ и СПИСОК ЗАПУЩЕННЫХ
> > ПРОЦЕССОВ (которые вызываются по правой кнопке
> > мыши на ярлыке сервера) - это может приводить к
> > зависанию сервера.
> >
> > Для наблюдения за работой сервера следует
> > использовать КЛИЕНТСКИЙ АРМ Администратор
>

Просьба уточнить, эти рекомендации сохраняются для ИРБИС64 2010.1?

Да, сохраняются.

> > При больших нагрузках на сервере (десятки
> > одновременно работающих пользователей):
> >
> > 1.Запускать сервер как СЛУЖБУ

Александр Иосифович, дополнительный вопрос: в связи с чем выработана такая рекомендация?

Видимо с тем, что при большой загруженности и большом количестве команд в секунду затрачиваемые ресурсы на перерисовку этого окошка становятся слишком большими, что будет приводить к дополнительным задержкам в обработке.
Какждая команда вызывает принудительную перерисовку списка, что может и неправильно, но выглядит интересней чем, к примеру, ежесекундное его обновление (за которое множество команд может казаться неотображенным).
Плата за такое "живое" отображение информации понятна - Windows список отрисовывает очень медленно, особенно если это большой список, а если еще и через team viewer или vnc - то совсем красота :)

Собственно, у администраторов две возможности:
1. Если ресурсов хватает с избытком - можно держать это окно открытым.
2. Если система высоконагруженная, либо сервер сам по себе слабый - то через клиентский АРМ Администратор - этот путь мало чем отлтчается от обновления списка по таймеру...

Предпочтение же службе отдается по совсем простой причине - серверные ОС отдают ресурсы в первую очередь службам, а остатки приложениям (если только обратное эти ОС не заставит делать админстраторы).

В клиентских ОС (XP, Vista, 7) все наоборот - там больший приоритет имеют приложения. Но про десятки работающих клиентах на этих ОС лучше даже не задумываться. Одно ограничение на ол-во полуоткрытых соединений чего стоит... Кто работал активно с торрентами наверняка понимает о чем говорю :) (Есть конечно хаки, но это уже будет не лицензионная Windows...)



Редактировано 2 раз. Последний раз 15.03.2011 22:04 пользователем Михайленко Илья.

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

Доброе утро!

Сейчас встретился ещё один вид ошибки - сообщение "Ошибка при регистрации" на клиентах. Был открыт АРМ Администратор - Клиент, удалось заснять список запущенных процессов (скриншот).
Можно заметить, что текущее время - 9:54, а время запуска первого процесса - 9:07:27.
В настройках сервера ИРБИС64 (irbis_server.ini во вложении) установлены параметры:
----
#максимально возможное число процессов обработки - если превышено сервер возращает код ошибки
MAX_PROCESS_COUNT=20
#максимальное время обработки запроса
PROCESS_TIME_LIVE=30
---

Перезапустили сервер ИРБИС64 с использованием пункта меню сервера "Перезапустить"

Вопросы:
1) скажите, пожалуйста, сообщение "Ошибка при регистрации" в клиентах ИРБИС64 может быть связано с ответом сервера SERVER_OVERLOAD?
2) максимальное время обработки запроса - это максимальное время обработки процесса? Если да, то по каким-то причинам сервером ИРБИС64 не были завершены процессы, стартовавшие до 9:24...
Может ли такое поведение сервера быть связано с MAPING_WORK_FILES=1?

---
MAPING_WORK_FILES=1 - обмен между процессами обработки и ядром сервера - через системную память (1) или через временные файлы (0) в рабочей директории workdir. Если системной памяти не хватает, происходит обмен через файл. При включении этого режима, необходимо также включить проверку клиентов на подтверждение - CLIENT_TIME_LIVE, чтобы за ними не оставалась выделенная память.
---

3) можно ли повторить вопрос о параметре LISTEN_RESPONSE ( [irbis.gpntb.ru] )?

---
Серверная часть ИРБИС64 - 2010.1. server_64.exe - 31.03.2010 г.
IRBIS64.dll - 02.02.2011 г. Метод запуска сервера - как приложение Windows. Режим работы сервера - обычный (DUPLICATE_SOCKETS=0, THREADS_AVAILABLE=0). Способ обмена информацией сервера с процессами обработки - через системную память (!).

Посмотрел ini.

CHECK_REDIRECT=1
Вы используете удаленные БД ИРБИС64? Если да - то каналы между двумя серверами ИРБИС 64 должны быть более чем хорошие. Если нет - то в 0.

IP_PORT=23
Этот порт пользует telnet - ИРБИС очень удивится такому порту. Лучше все же использовать не зарезервированные порты, если не устраивает стандартный 6666.

MAX_SERVERS=10
MAX_PROCESS_COUNT=20

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

CLIENT_TIME_LIVE=600
Убивать клиента если он не подает признаков жизни 10 часов. Сурово. Или у Вас кол-во лицензий с очень большим избытком? Если в клиентских ини стоит параметр CLIENT_TIME_LIVE 15 минут, то сюда стоит прописать значение, равное PROCESS_TIME_LIVE+2*CLIENT_TIME_LIVE

PROCESS_TIME_LIVE=30
Время жизни процессов, которые отражены у Вас на скриншоте. Тут дилемма. С одной стороны, при такой загрузке этот параметр нужно уменьшать (не успел отработать - умри и освободи ресурсы другим). С другой.... Если используется книгообеспеченность и база обеспеченности достаточно большая - я бы тут выставил 180 (3 часа). В общем, пора задуматься об апгрейде сервера.

MAPING_WORK_FILES=1
Если с мощностями сервера все нормально, то именно этот параметр и является скорее всего источником проблем. Установите его в 0. Либо
MappingFileSize= не 15, а хотя бы 512 если пользуете КО. В любом случае, параметр очень опасный и может приводить как к убиению отдельного процесса так и к убиению всего сервера, если мертвых процессов накопится много (способом как на скриншоте). Если выставляете в 256...512, то СВОБОДНОЙ оперативной памяти на сервере должно быть MAX_PROCESS_COUNT*MappingFileSize. В Вашем случае это 20*(256...512)=5...10Гб плюс на накладные расходы около 1Гб. ОС естественно в этом случае 64bit. 15Мб хватит если кроме каталогизатора вы больше ничего не используете (тогда вам и 10 Мб тут хватит). Смотрите по мощностям... Запросы, результат которых более 100Мб в рамках рабочей системы я видел (АРМ КО в ОмГТУ).

MaxLogFileSize=100000000
Ресурсов обработка 100Мб файла при обрезке есть очень много на каждую команду. Скажите, Вы хоть кода-нибудь находили в этом файле полезную для себя информацию? Если нет, то пару-тройку нулей я бы убрал из этой цифры.

По LISTEN_RESPONSE отвечу точно чуть позже. Заодно перепроверю: по-умолчанию он должен быть 0, т.к. технологию не поддерживаем в полном объеме - по эффективности себя не оправдала, лишь добавила проблем (особенно на больших системах).

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

Михайленко Илья написал(а):
-------------------------------------------------------
> MAX_SERVERS=10
> MAX_PROCESS_COUNT=20
>
> Судя по скриншоту - у Вас действительно происходит
> перенагрузка сервера. Если такая картина постоянно
> - нужно менять сервер на что-то более мощное...
> Эти параметры являются защитой от перегрузки.

К сожалению, в апреле не записывали информацию по процессам в журнал. Но ситуация на скриншоте - необычная: при PROCESS_TIME_LIVE=30 сервер к 9:54 не завершил обработку процессов под номерами 1, 2 и 3, стартовавших в 9:07, 9:12 и 9:21… Это не является ошибкой?

---
UPDATE. Если за последние PROCESS_TIME_LIVE минут для процесса была выполнена хотя бы одна команда, то это не ошибка:

Михайленко Илья написал(а):
-------------------------------------------------------
...
> Кроме того, в сервере предусмотрена защита от
> "зависших" процессов. PROCESS_TIME_LIVE - это
> время в минутах, сколько максимально может
> исполняться каждая команда. Если дольше, то
> процесс считается зависшим и уничтожается ядром
> сервера.
---

Тогда, если ресурсов сервера достаточно, то следует увеличить MAX_SERVERS и MAX_PROCESS_COUNT?...
(В ГПНТБ СО РАН – современный шестнадцатипроцессорный сервер. Свободной оперативной памяти около 36 гигабайт. АРМ "Книгообеспеченность" не используется. Используются АРМ "Комплектатор", "Каталогизатор", "Книговыдача", "Читатель", "Корректор", "Администратор". Работает Web-ИРБИС.)

> CLIENT_TIME_LIVE=600
> Убивать клиента если он не подает признаков жизни
> 10 часов. Сурово. Или у Вас кол-во лицензий с
> очень большим избытком?

Да, количество лицензий избыточное.

> Если в клиентских ини
> стоит параметр CLIENT_TIME_LIVE 15 минут, то сюда
> стоит прописать значение, равное
> PROCESS_TIME_LIVE+2*CLIENT_TIME_LIVE
>

Понятно.

> MAPING_WORK_FILES=1
> Если с мощностями сервера все нормально, то именно
> этот параметр и является скорее всего источником
> проблем. Установите его в 0.

Понятно. В начале апреля меняли значение параметра на 1.
Снова установим в 0.

> MaxLogFileSize=100000000
> Ресурсов обработка 100Мб файла при обрезке есть
> очень много на каждую команду. Скажите, Вы хоть
> кода-нибудь находили в этом файле полезную для
> себя информацию? Если нет, то пару-тройку нулей я
> бы убрал из этой цифры.
>

Полезную информацию находили. Не поняли предложение «Ресурсов обработка 100Мб файла при обрезке есть очень много на каждую команду».



Редактировано 2 раз. Последний раз 22.04.2011 18:41 пользователем PRM.

По состоянию на третье мая изменили настройки:
IP_PORT=6666
MAPING_WORK_FILES=0
CLIENT_TIME_LIVE=90
MaxLogFileSize=1000000
FORMAT_CASHABLE=1
MAX_PROCESS_COUNT=50

Установили клиентскую и серверную часть из обновления D5 версии 2010.1.

Наблюдаем различные ошибки:

1) на клиентах "Asynchronous socket error 10053" и окно "Ожидание ответа от сервера"; при запуске АРМ - те же ошибки, подключение не выполняется.
Через 1-3 минуты запуск АРМ проходит нормально.
В директории CGI-BIN Web-ИРБИС сформированы Error_terminate_*.log. (Вероятно, не хватило ресурсов сервера для обработки запросов Web-ИРБИС.)

2) тоже ошибки на клиентах "Asynchronous socket error 10053", но в течение длительного времени. На сервере загрузка CPU низкая, irbis_server.exe не отвечает. Исправили завершением процесса irbis_server.exe и запуском irbis_server.exe.

3) лавинообразный рост числа процессов ИРБИС, находящихся в обработке (такая же ситуация, как в сообщении от 22 апреля)
Ошибку удалось выявить, когда число процессов было меньше MAX_PROCESS_COUNT, и запуск АРМ проходил нормально.
На сервере загрузка CPU низкая. Irbis_server.exe работал, запустили окно «Список запущенных процессов»…
Успели перезапустить сервер ИРБИС64 с использованием пункта меню сервера "Перезапустить".
Такая ситуация была только сегодня, повторялась уже дважды.

Дополнение 1: в ходе анализа ситуации 3 найден интересный момент, в irbis_server.log существуют строки:
14.05.2011 11:25:49 192.168.0.100 ID=B Length=60 Command=I ARM=? Num=I
и
14.05.2011 11:28:10 192.168.0.105 ID=B Length=68 Command=I ARM=? Num=I
В строках - нечисловые идентификаторы процесса и номера команд.



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

Собственно, Сетевая ошибка 10053 - это ошибка на уровне протокола TCP/IP.
Характеризуется в первоисточниках следующим образом:

WSAECONNABORTED
10053
Software caused connection abort.
An established connection was aborted by the software in your host computer, possibly due to a data transmission time-out or protocol error.

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


В части ИРБИС с чем можно поиграться (поможет врядли, но для успокоения совести...):
1. FORMAT_CASHABLE=1 можно попробовать установить в 0 в качестве теста, но это, вроде, уже в 10.1 поправлено было.
2. Веб-ИРБИС живет на той же машине? Если да, то попробовать временно погасить - сохранится ли ошибка?
3. Лавинообразное размножение процессов - такое наблюдал только на высокозагруженных серверах, когда происходит обрушение операционной системы (нехватка дескрипторов, переполнение очередей сообщений ОС и т.д. при этом процессорные мощности могут быть задействованы совсем на смешной процент) - это уже повод для разнесения нагрузки по разным серверам, либо комбинирование разных по типу нагрузки сервисов на разных серверах. Тут, не видя сервера "в динамике" - мало что могу сказать.

Важное уточнение. У PRM, насколько я знаю, ИРБИС работает в ТЕРМИНАЛЬНОМ режиме.

Александр Иосифович, Илья Иванович, спасибо.
Будем думать.

ИРБИС, действительно, работает в ТЕРМИНАЛЬНОМ режиме, но:
1) терминальные станции АРМ Каталогизатор и АРМ Книговыдача почти полностью заменены на обычные компьютеры;
2) на терминальных станциях читателей АРМ Читатель почти полностью заменён на Web-ИРБИС.

Добрый день.

В "Сервер 64.doc" в разделе 5.4 Несколько замечаний для администраторов написано "Если будет зависание системных функций чтения-записи, беспотоковый сервер не сможет продолжать обработку запросов."
Появился вопрос: известно ли что-то о поведении сервера в данной ситуации. Может ли в данной ситуации "зависнуть" графический интерфейс сервера?

Графический интерфейс сервера работает в том же потоке что и ядро сервера, которое работает с сокетами.
Как следствие - ответ "да".

Илья Иванович, здравствуйте.

Скажите, пожалуйста, а можно ли определить, что зависание сервера ИРБИС произошло именно из-за зависания системных функций чтения-записи?

Прочитал сообщения в теме [irbis.gpntb.ru].

За прошедшее время удалось определить ещё два момента по ошибке "...10053":
- в случае зависания сервера ИРБИС ошибка "...10053" появляется и в АРМ Администратор (клиент), запущенном на сервере (через подключение к удалённому рабочему столу);
- иногда после ошибок "...10053" на клиентах сервер ИРБИС возобновляет работу (самостоятельно, без перезапуска) через некоторое время.

АРМ Администратор (клиент), когда запущен локально использует весь стек tcp/ip, включая сетевые драйвера. Разница лишь в отсутствии физического провода и разъемов.
Раз появляется такая ошибка и через какое-то время сервер продолжает работу (после того, как сбросит побившееся соединение по таймауту), то механизм возникновения ошибки скорее всего такой:
По-идее, пока это соединение не будет сброшено, другие клиенты должны сидеть в очереди ожидания. Вполне могу допустить что часть клиентов при этом так же отвалится с подобной ошибкой - пока сервер не закончит с отсылкой пакета (успешно или не успешно), остальным клиентам он ничего не отвечает. Клиенты в свою очередь тоже не ждут вечность - отваливаются с сетевой ошибкой по таймауту.

Соответственно, если ошибка произошла при общении с сетевым клиентом, то локально запущенный клиент так же может отвалиться с ошибкой 10053.

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

Илья Иванович, спасибо, это было бы полезно.

Коммент от чукчи.
Однако подтверждается старое наблюдение, что Веб-ИРБИС удобнее, чем АРМ Читатель.

Добрый день :) Вот и мы приобрели обновление системы и опять зависли :( В прошлый раз нам Илья Иванович Михайленко променял нам irbis_server.ini, и все заработало.. Поэтому сейчас оставила пока этот старый файл, пока вроде работает.. Но хотелось бы узнать все таки причину. Высылаю старый и новый файл. Пожалуйста, подскажите, какие параметры нужно поменять в новом.
С уважением, Академия управления МВД РФ.
Ольга.

Попробуйте в новом ini FORMAT_CASHABLE установить в 0 и поделитесь результатом, пожалуйста

Поставила в новом такой параметр, так же все зависало..
Мне посоветовали обновиться, так как дистрибутив с новой версией 10 был вроде D1. Я скопировала все файлы обновлений D1 - D5, запустила, так у клиентов даже перестали загружаться программы (висит, даже Ирбис не бегает). Поставила опять обратно irbis_server.ini с 9 версии, опять вроде все заработало, вот сейчас проверяем...
Зато на сервере теперь не отображается список зарегестрированных пользователей и запущенных процессов.., а если запустить клиентский администратор, то он все показывает..
В общем, грустно совсем... Начальство скоро меня съест ;)
Может быть, к нам кто-нибудь может подъехать, посмотреть... Боюсь, что сама не справлюсь :(
Жду ответа :)



Редактировано 1 раз. Последний раз 28.07.2011 12:35 пользователем ovkuz.

Цитата:

ovkuz
Зато на сервере теперь не отображается список зарегестрированных пользователей и запущенных процессов.., а если запустить клиентский администратор, то он все показывает..

Такое может происходить, если сервер у Вас запущен одновременно и как сервис и как приложение.

Цитата:

ovkuz
Может быть, к нам кто-нибудь может подъехать, посмотреть... Боюсь, что сама не справлюсь :(

к нам - это в какой город? :)
Проще, наверное, через TeamView дать посмотреть на свой сервер... Думаю, дешевле обойдется чем дорога из Омска... :)
(ИД и пароль в личку)

Академия находится в Москве, на Войковской. К нам Константин как-то приезжал уже, может быть, придется беспокоить еще раз.. Так как сервак на просмотр нам давать не разрешено по секретности, наверное, нужно на какой-нибудь комп все скопировать без прикрепленных документов и его уже показывать.. В общем, подумаем, ведь мы еще ОПАК приобрели, попробуем с ним разобраться, вот, если уж не получится, тогда будем звать на помощь со всеми нашими проблемами.. А пока так и работаем на старом irbis_server.ini, пока не виснет ;)