Еще один вопрос: что за параметр Appication.handle в irbis_server.ini и чему он должен быть равен в идеале ?



Редактировано 1 раз. Последний раз 23.07.2010 11:05 пользователем dvv.

dvv написал(а):
-------------------------------------------------------
> Думаю выставить все настройки irbis_server.ini
> согласно стандартным, (кроме путей и
> DUPLICATE_SOCKETS=1, USE_MULTY_PROCESSOR=1), будем
> наблюдать, посмотрим, может даст результат.
Любопытно - какие еще параметры - кроме DUPLICATE_SOCKETS и USE_MULTY_PROCESSOR - Вы еще меняли (по сравнению со стандартными)?

И еще один вопрос dvv

Ваши пользователи (в частности, работающие с АРМом Книговыдача) нажимают кнопку ПРЕРВАТЬ при "бегущем" Ирбисе - И если да, то что они потом нажимают: кнопку ДА (повторить обращение к серверу) или НЕТ?

Предыстория : вначале был ирбис... и время от времени (со стандартным файлом irbis_server.ini, разумеется) он "притормаживал", что очень мешало всем жить и работать. Админы сбивались с ног, искав в чем же была проблема, а проблема тем временем исчезала сама собой через недельку-две и появлялась в следующий раз месяца через 3-4. Тем временем админы, пытаясь выяснить что к чему натыкались только на один или два стандартных аргумента со стороны знающих людей форума ИРБИС. А знающие люди говорили как один : это пропускная способность сети - сеть медленная или антивирус отключите и будет вам счастье :). Поняв, что дело зашло в тупик, а через сеть можно гигабайтами без коллизий и прочих неприятностей перекидывать контент за считанные секунды (что в общем-то может говорить о том, что с сеткой все в порядке) админы начали править файл irbis_server.ini в поисках счастья. Правили они правили и доправились до DUPLICATE_SOCKETS=1, USE_MULTY_PROCESSOR=1 и оказалось, что с этими двумя настройками ИРБИС работает гораздо быстрей, нежели если бы они были по нулям. И отметили горемычные пользователи, что дышать им стало легче на рабочем месте, работая с ИРБИС и комфортнее, однако беда подкралась незаметно и каждые сутки по непонятным причинам (предположительно ночью или поздним вечером, а очень реже и днем) с тех пор стала появляться ошибка отсутствия файла DBNAMXXX.mnu при залогинивании клиентов. Юмора тут конечно мало, но обстановку надеюсь, разрядил.
Во вложении файл irbis_server.ini,может окинете своим взглядом, Александр Иосифович?



Редактировано 3 раз. Последний раз 26.07.2010 05:07 пользователем dvv.

Доправились Вы не только до этих параметров...

#обмен между процессами обработки и ядром сервера - через системную память (1) 
#или через временные файлы в рабочей директории workdir
MAPING_WORK_FILES=1
#размер системной памяти выделяемой клиенту, Mb
MappingFileSize=10

Первый же клиент, запросивший данных больше 10Мб приведет к непредсказуемым результатам. Ускорение и потерю в надежности Вы получили именно установив MAPING_WORK_FILES в 1. Можно поиграться с размером буфера и подобрать более-менее безопасное значение, но памяти на сервере у Вас должно быть много - иначе тормоза получите гораздо более жестокие чем в случае MAPING_WORK_FILES в 0. Определить заранее этот параметр очень сложно - в каждом случае приходится подбирать его достаточно долго. Стоит учесть, что такой объем данных требуется в основном сложным задачам (особенно книгообеспеченность), когда правятся тысячи записей. Если готовы рисковать таким объемом данных - держите MAPING_WORK_FILES выставленным в 1...

Цитата:

dvv
Админы сбивались с ног, искав в чем же была проблема, а проблема тем временем исчезала сама собой через недельку-две и появлялась в следующий раз месяца через 3-4 месяца

Само собой, тем более на серверах обычно ничего не происходит. У всего есть причины.

О параметрах про которые говорите Вы.
DUPLICATE_SOCKETS=1
Этой командой решается у кого будет сокет (и, соответственно, кто ответит клиенту) - сам сервер который принял соединение (=0) или же сокет будет передан процессу обработки и ответит клиенту этот процесс (=1). Вот и все :) Теоретический выигрыш в скорости ответа при потере надежности за счет передачи сокета между процессами windows. При том что у вас количество этих процессов ограничено 20 (MAX_PROCESS_COUNT=20) смысл не очень просматривается. И MAPING_WORK_FILES=1 тогда не имеет смысла - ответ отдается клиенту обработчиком... Плюс, тут есть еще одна опасность. Если обработчик по каким-либо причинам безвременно помер - клиент об этом долго не узнает...

####РАСПАРАЛЛЕЛИВАТЬ ПРОЦЕССЫ - (ТОЛЬКО В СЛУЧАЕ МНОГОПРОЦЕССОРНОГО СЕРВЕРА!)
USE_MULTY_PROCESSOR=1

"Многопроцессорный сервер" - имеется ввиду не железо, а режим работы сервера ирбис. Если выставлен в 1, то для каждого процесса обработки создается отдельный поток в ядре сервера, который общается с процессом обработки. Учитывая что за 20 процессов обработки Вы не выходите, смысла использовать этот параметр особого не вижу. К надежности конечно минус за счет усложнения алгоритма общения...

Параметр Appication.Handle - это внутренний параметр сервера. Перезаписывается каждый раз при старте сервера. Собственно хендл процесса сервера, по которому его получают процессы обработки. Идеальное значение - соответствующее хендлу сервера :) Если поправить во время работы сервера - рискуете получить неработоспособную систему.

Резюмируя.

Из Вашего конфига - ощутимый прирост скорости Вы получаете за счет параметра MAPING_WORK_FILES=1. Опасность использования такого параметра мною описана. Решать использовать его или нет - Вам. Видите периодически падающий сервер и битые записи (например, половина записей с сохраненными коэффициентами КО, половина - без) - регулируйте MappingFileSize с оглядкой на общий объем памяти на сервере. Сам я в свое время поигравшись с этим параметром, доведя его до 100Мбайт, намучавшись с висами сервера по превышению этого объема, последующими восстановлениями из бекапов и упершись в деградацию скорости по свопу памяти операционкой выставил MAPING_WORK_FILES в 0 и забыл о зависаниях наглухо сервера совсем. Кеш windows тут весьма кстати - обработка файлов происходит в памяти.

Как и говорил - заменил все настройки в файле irbis_server.ini на стандартные, кроме DUPLICATE_SOCKETS=1 и USE_MULTY_PROCESSOR=1 в субботу, а в понедельник вечером опять таже ситуация : отсутствует файл dbnamXXX.mnu при залогинивании. Дамы и Господа, есть еще размышления ?

dvv написал(а):
-------------------------------------------------------
> Как и говорил - заменил все настройки в файле
> irbis_server.ini на стандартные, кроме
> DUPLICATE_SOCKETS=1 и USE_MULTY_PROCESSOR=1
Установите ВСЕ параметры в стандартные значения. Никаких иных советов нет.

Подниму эту тему, чтобы не создавать новую.
Каковы принципиальные отличие работы сервера в многопроцессорном режиме от обычного и многопоточного для конечного пользователя?
На данный момент работает около 40 клиентов одновременно (как через обычные, так и через 128ой). Эта цифра увеличится на 15-20.

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

Еще бы получить рекомендованные значения для параметров в ини для данного режима, т.к в руководстве неоднозначно описано, для чего конкретно они (например параметр Dup_ProcessCountPullБ что будет если 0 поставить? А если 100?)

Настоятельно НЕ РЕКОМЕНДУЕТСЯ менять какие-либо параметры в irbis_server.ini (относительно дистрибутивных настроек)

Интересно для чего тогда анонсировать новые возможности, если ими не рекомендуется пользоваться...