• Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

  • CTF с учебными материалами Codeby Games

    Обучение кибербезопасности в игровой форме. Более 200 заданий по Active Directory, OSINT, PWN, Веб, Стеганографии, Реверс-инжинирингу, Форензике и Криптографии. Школа CTF с бесплатными курсами по всем категориям.

Проблема с Availability Index в Domino 8.5.2

  • Автор темы maeglin2000
  • Дата начала
M

maeglin2000

Всем привет. Появилась проблема после перехода на Domino 8.5.2. В нашем домене около 250 пользователей с клиентом ln8.5.2 basic и почтовый сервер HP Proliant G5 with 4GB RAM and 4-core processor с Domino 8.5.2fp1. Пользователей переводил следующим образом: добавил в существующий домен новый сервер, перекинул туда CA, сделал сервер административным для основных баз домена, затем планомерно обновлял клиентов на раб местах и перекидывал пользователей со старого сервера 7.0.1fp1 на новый через Move to another server и на новом серваке обновлял design. На каком-то этапе миграции заметил, что скачет на новом сервере Availability Index (AI), причем в широком диапазоне, в то время как на старом 7.0.1fp1 всегда колом стаял на 100. На сегодняший момент всех пользователей перевел на новый сервер. AI вычисляется относительно статистики expansion factor и определяется параметром Server_Transinfo_Range. Чтобы сервер был доступен, временно выставил Server_Transinfo_Range=11, хотя по умолчанию 6, и на старом сервере он был по умолчанию. При сегодняшнем раскладе AI изменяется постоянно в диапазоне где-то между 28 и 73 - это expansion factor между 8 и 256. Долго переписывался с ibm по этому поводу, в рез-те получил след:
The algorithm to compute the Availability Index, which is used to drive
automatic failover under heavy loads, was designed a number of years
ago. The analysis and testing done then was done on machines which were
much smaller and slower. The Availability Index is computed by examining
the difference between the elapsed time to perform transactions on an
idle system and the elapsed time to perform them on a loaded system. As
machines have gotten faster and new releases are more efficient in terms
of processing the transactions, the elapsed time to perform transactions
on an idle system has gotten very much smaller, making the difference
very much larger. The original new Availability Index code did not take
this into account.

That was the reason the SERVER_TRANSINFO_RANGE prameter was introduced
which allows the administrator to adjust the calculation to match the
server actual capacity. The notes.ini variable SERVER_TRANSINFO_RANGE is
used to adjust the AI calculation to match the speed of your server
(which you are already aware of).


Многие пользователи стали жаловаться, что работа с почтой стала медленнее, но для нашей среды нельзя однозначно сказать, что дело в сервере. Поэтому, всем, кто в теме просьба:
1. Если пользуете Domino 8.5 приведите,плиз, здесь свои значения AI и expansion factor с примерной конфигурацией сервера и кол-ом пользователей для сравнения.
2. Подскажите, на что еще обратить внимание
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
В нашем домене около 250 пользователей с клиентом ln8.5.2 basic и почтовый сервер HP Proliant G5 with 4GB RAM and 4-core processor с Domino 8.5.2fp1.
1) ставим 8.5.2FP2
2) 200 пользователей * на 30Mb на сесию = 6Gb - вам не хватает минимум 2 Гиг озу

Многие пользователи стали жаловаться, что работа с почтой стала медленнее
3) создаём им локальные реплики и пусть с почтой через локальный ПЯ общаются - сущесвенно разгрузит сервер/сеть на "опросы почты"

4) Винты - все про это забывают ни нариащивание ОЗУ ни многоядерность это узкое горлышко никогда не решат, или там шустрые рейды или всё будет висеть
 
M

maeglin2000

Спасибо за ответ.
2) 200 пользователей * на 30Mb на сесию = 6Gb - вам не хватает минимум 2 Гиг озу
А откуда такой расчет? Сейчас сервер в рабочие часы больше 2-х гигов не использует. Насколько я знаю, то, с чем клиент работает, он кеширует у себя на РС. Когда юзер завершает операцию, передает на сервер, оно недолго наход. в оперативной памяти и попадает в базу. Обычно это письма в неск. килобайт, бывают аттачи по неск. мегабайт. На старом сервере с 7.0.1fp1 также 4Гб озу, одновременных польз сессий у нас в раб. время примерно 190-210, средний размер баз 500 Мб. Тормазов при работе с базой там никогда не наблюдалось.
3) создаём им локальные реплики и пусть с почтой через локальный ПЯ общаются - сущесвенно разгрузит сервер/сеть на "опросы почты"
К сожалению, этот вариант для нашей конторы неприемлем.
4) Винты - все про это забывают ни наращивание ОЗУ ни многоядерность это узкое горлышко никогда не решат, или там шустрые рейды или всё будет висеть
Стоит аппаратный контроллер raid, диски собраны в raid 10. На старом сервере был raid 5 и 2-хядерный проц.
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
А откуда такой расчет? Сейчас сервер в рабочие часы больше 2-х гигов не использует. Насколько я знаю, то, с чем клиент работает, он кеширует у себя на РС. Когда юзер завершает операцию, передает на сервер, оно недолго наход. в оперативной памяти и попадает в базу. Обычно это письма в неск. килобайт, бывают аттачи по неск. мегабайт. На старом сервере с 7.0.1fp1 также 4Гб озу, одновременных польз сессий у нас в раб. время примерно 190-210, средний размер баз 500 Мб. Тормазов при работе с базой там никогда не наблюдалось.
Внимательней меня читаем я сказал на сесию - когда клиент конектится к сервере инициализируется сесия, в настройках так же указано через сколько она разрушается, инфа от ИБМ - использовать среднее значение в 30Mb на сесию.
Дальше хуже - если у вас серве используют только 2Гига ОЗУ значит он у вас 32битный, потому как нормальный домино старается схавать ВСЮ память, у него там свой контролер памяти и ему виднее сколько кешировать и на сколько долго(хоть там и есть куча настроек на это, но я не верю что вы в них разбираетесь, потому как инфы о них весьма мало)
Не надо сравнивать "тогда 7.0.1" и сейчас "8.5.2" я готов утверждать что в идентичной ситуации 8.5.2 будет всегда быстрее, значит ситуация у вас поменялась.
Ищите причину тормозов.


К сожалению, этот вариант для нашей конторы неприемлем.
Использование локальной реплики, является дополнительным механизмом целостности и бекапирования ПЯ, не стоит его игнорировать

Стоит аппаратный контроллер raid, диски собраны в raid 10. На старом сервере был raid 5 и 2-хядерный проц.
какова его скорость на I/O?
делали замеры с утра/обед/вечер?
вели статистику?
банально запускали в винде на сервере Администрирование/Производительность - какова очеред операция I/O
Если взять во внимание 200 пользователей и размер ПЯ каждого в 500Mb и то что сервер в какой-то момент начинает читать все ПЯ для всех пользователей то получается пиковая нагрузка 200*500Mb=100Gb/s - вы понимаете, что это за скорость?
 
A

am4

maeglin2000, AI никак не связан с реальной производительностью и используется только для fileover-а.

Смотрите статистику сервера (sh stat platform), в частности:
Platform.System.PctCombinedCpuUtil
Platform.Memory.RAM.PctUtil
Platform.LogicalDisk.N.AvgQueueLen.Peak и Platform.LogicalDisk.N.PctUtil.Peak

И убедитесь что затык в последнем, т.е. в дисковой подсистеме ;)
 
M

maeglin2000

AI никак не связан с реальной производительностью и используется только для fileover-а.

AI связан, как уже указывал выше, со статистикой expansion factor, определяемой как отношение времени, требуемого на обработку определенных транзакций в текущий момент, к мин. времени, когда либо измеренному для данного типа транзакций. AI действительно нужен для кластера и указывает, насколько доступен сервер для клиентов. По изменению AI можно судить об изменении expansion factor, и если для AI можно указать, какое значение должно быть при опред. значении expansion factor, через переменную SERVER_TRANSINFO_RANGE, то по expansion factor можно судить, что некоторые транзакции проходят с задержками. Если появились задержки, значит что то не так с производительностью.

Platform.System.PctCombinedCpuUtil = 0,44
Platform.Memory.RAM.PctUtil = 46

show stat server.expansionfactor
Server.ExpansionFactor = 186,083498987134
1 statistics found

show stat platform.log*
Platform.LogicalDisk.1.AssignedName = D - здесь Domino с почтовыми базами
Platform.LogicalDisk.1.AvgQueueLen = 0
Platform.LogicalDisk.1.AvgQueueLen.Avg = 0,02
Platform.LogicalDisk.1.AvgQueueLen.Peak = 1,42
Platform.LogicalDisk.1.BytesReadPerSec = 2 867,27
Platform.LogicalDisk.1.BytesWrittenPerSec = 95 635,27
Platform.LogicalDisk.1.PctUtil = 0,24
Platform.LogicalDisk.1.PctUtil.Avg = 1,58
Platform.LogicalDisk.1.PctUtil.Peak = 141,86
Platform.LogicalDisk.1.ReadsPerSec = 0,33
Platform.LogicalDisk.1.WritesPerSec = 4,82
Platform.LogicalDisk.2.AssignedName = C - здесь ОС
Platform.LogicalDisk.2.AvgQueueLen = 0
Platform.LogicalDisk.2.AvgQueueLen.Avg = 0
Platform.LogicalDisk.2.AvgQueueLen.Peak = 0,91
Platform.LogicalDisk.2.BytesReadPerSec = 0
Platform.LogicalDisk.2.BytesWrittenPerSec = 16 708,65
Platform.LogicalDisk.2.PctUtil = 0,02
Platform.LogicalDisk.2.PctUtil.Avg = 0,29
Platform.LogicalDisk.2.PctUtil.Peak = 91,03
Platform.LogicalDisk.2.ReadsPerSec = 0
Platform.LogicalDisk.2.WritesPerSec = 2,2
Platform.LogicalDisk.TotalNumofDisks = 2


Смотрите статистику сервера (sh stat platform), в частности:
Platform.System.PctCombinedCpuUtil
Platform.Memory.RAM.PctUtil
Platform.LogicalDisk.N.AvgQueueLen.Peak и Platform.LogicalDisk.N.PctUtil.Peak

И убедитесь что затык в последнем, т.е. в дисковой подсистеме

Затыка вроде как нет: мониторил Platform.LogicalDisk.N.AvgQueueLen.Avg и Platform.LogicalDisk.N.PctUtil в течении всего раб. дня - значения оставались в приведенных выше пределах, пиковых значений не достигали.

Ищите причину тормозов.

Этим и занимаюсь.
вели статистику?

Да. Выше привожу значения статистик Platform.LogicalDisk.N.AvgQueueLen и Platform.LogicalDisk.N.PctUtil. Кроме того, снимал nsd на протяжении раб. дня и отсылал на Ibm.
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
maeglin2000
нет ответа по памяти и по дискам
Пример проца:
утилизация ЦПУ 44% может означать 0% 100% 0% 98% для 4х ядерного - понимаете что это значит?
нет ответа 64битная ли это версия

Память:
утилизачия 46%?
из чего? какой обмен I/O?
Доступна ли вообще вся память?
за какой период статистика?
где статистика по максимальным пикам(память, сессий, транзакий, юзеров и т.д.)?
кстати ТЛ у вас вообще поднят?
как получилось что дисков всего 2?
 

rinsk

Lotus Team
12.11.2009
1 151
125
BIT
3
AI связан, как уже указывал выше, со статистикой expansion factor, определяемой как отношение времени, требуемого на обработку определенных транзакций в текущий момент, к мин. времени, когда либо измеренному для данного типа транзакций. AI действительно нужен для кластера и указывает, насколько доступен сервер для клиентов. По изменению AI можно судить об изменении expansion factor, и если для AI можно указать, какое значение должно быть при опред. значении expansion factor, через переменную SERVER_TRANSINFO_RANGE, то по expansion factor можно судить, что некоторые транзакции проходят с задержками. Если появились задержки, значит что то не так с производительностью.
...

AI через SERVER_TRANSINFO_RANGE можно установить практически любым, выровняв "загрузку" между писюком и сервром например...
На самом деле AI эт такие попугаи, конкретный эшелон бултыхания можно регулировать через _range...
Далее, при работе в кластере через Server_Availability_Threshold указывается тот эшелон, при падении попугаем которого он благополучно отстреливается и сервер переходит в состоянии Busy.
Т.е. AI попугаи эт средство настройки кластера, а не прямое средство диагностики проблем производительности. Для этого есть sh stat ..
По опыту, надо глядеть сеть у свежеиспеченного сервера - в случае если с дисками все в порядке.
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!