Informix Logo


O CLEANERS и LRUS".

Все таки для установки CLEANERS необходим более обширный анализ, как
мне кажется. Хотя наверное я повторю общеизвестные вещи.

Шаг 1.
CPU, Chunks, AIO/KAIO или BIOS ;-) (Basic IO System)

Сначало хорошо бы убедиться, что система может в плане IO

CPU - количество и их мощность.
В зависимости от этих параметров мы можем определить какое количество
AIO/KAIO мы можем позволить себе в системе. Что касается KAIO то тут
все понятно, на каждый CPU мы имеем один KAIO и по моим наблюдениям
KAIO приближается по IO к пропускной способности контроллера и hard
drive (IMHO Пожалуй это наилучший вариант). Если же используем AIO то
взависимости от мощности CPU можно позволить себе от 2 до 8 AIO которые
процессор будет успевать обрабатывать.

Chunks - количество и bottleneck (узкие места)
Количество Chunks и их нагрузка. Например сбор всех активных таблиц
в один chunk яркий показатель, проблемности системы. Тут уже не до
Cleaners.
В зависимости от количества активных chunks мы можем рассчитать
количество количество AIO, которое нам необходимо.

Первый шаг закончен, мы имеем систему без каких либо явных IO проблем.

Шаг 2. LRU Writes/Chunk Writes
Теперь определяем стратегию работы системы.

В зависимости от смеси OLTP/OLAP в системе определиться со стратегией
записи, т.е. какая запись предпочтительнее LRU Writes/Chunk Writes и
к какому соотношению будем стремиться. Например соотношение 70/30
более подходит к системе с преобладанием OLTP

Шаг 3. BUFFERS, LRUS, checkpoints
В зависимости от шага 2 и BUFFERS определяем LRU MIN/MAX и CKPTINTVL.

Шаг 4. И наконец то CLEANERS

Пробуем считатать в случае KAIO
MIN_CLEANERS=active chunks + CPU's*TCPU + (LRU Writes/Chunk Writes)*TCPU
Для AIO
MIN_CLEANERS=active chunks + AIO's/TCPU + (LRU Writes/Chunk Writes)*TCPU

TCPU - константа отражающая мощьность CPU, для PII(200Mhz) это 2, дальше
можно апроксимировать.

В итоге для системы
PII(200Mhz)
KAIO
6 active chunks
2 CPU
70/30 LRU Writes/Chunk Writes
Получим стартовую цифру
MIN_CLEANERS=6+2*2+(70/30)*2=14

Шаг 5. И опять CLEANERS
Подгонка CLEANERS под систему

А вот дальше уже учитывается шаг 3 и подгонка идет только в сторону
увеличения.
1. Если процент грязных буферов постоянно превышает LRU_MAX_DIRTY
(IMHO это так же может быть проблемой IO описанной в шаге 1.)
2. ? интуиция ...


С регардсами,
Евгений

P.S. Все вышенаписанное является моим личным мнением и мнения отличные
от моего не преследуются по закону. ;-)


Итак. Все буфера равномерно распределены между LRU очередями. В свою
очередь, внутри каждой очереди имеется 2 списка указателей - FLRU и MLRU.
Изначально все указатели на страницы данной очереди находятся в FLRU списке,
по мере "загрязнения" буферов, они постепенно переходят в MLRU список. Когда
нити sqlexec требуется буфер, она по хэш-функции выбирает одну из LRU
очередей, смотрит в ее FLRU список, и если там есть ссылка на свободный
буфер, то пытается им завладеть. В течение всего этого процесса очередь LRU
заблокирована для доступа других нитей, и каждая попытка другой нити
получить буфер из этой очереди будет вести к увеличению bufwaits.
Следовательно, если мы имеем большое количество сессий при малом количестве
очередей, то существует вероятность того, что некоторые сессии будут ждать
свободной очереди очень долго. Кроме того, существует вероятность того, что
даже получив доступ к LRU очереди, нить не найдет там свободных буферов, и
процесс поиска придется повторять снова. Теперь про установки LRUS.
Рекомендаций есть несколько. Первая - установить количество очередей равным
количеству виртуальных процессоров в системе. Ни на одной системе я не
видел, чтобы эта рекомендация была оптимальной. Впрочем, это дела вкуса.
Вторая - установить по одной очереди на 500-750 буферов, но не более, чем
127 дозволенных. Я придерживаюсь этой рекомендации, по крайней мере с
практической точки зрения она оправдана. Опять же, дело вкуса.
Непосредственно по установке LRUS следует помнить, что есть так называемые
"магические значения" этого параметра, при которых работа сервера
значительно замедляется (не знаю, признается ли это багом). Таких значений
известно два - 64 и 96. Так что avoid them.

Вот, собсно и все. Если я где-то был не прав, то подправьте.

С наилучшими, Юрий.


> А теперь CLEANERS. Конечно на разном железе и на разных платформах
> эффект может различаться, но на наших серверах я пришёл к формуле
> CLEANERS = LRUS. Т. е. когда процент "грязных" буферов в одной очереди
> превышает LRU_MAX_DIRTY, то очередь обращается к очистителю -
> а он в это время занят очисткой другой очереди, и первой приходится
> ждать, а буферы тем временем продолжают пачкаться. Поэтому я
> решил: каждой очереди - свой собственный очиститель. Это можно
> отмониторить: onstat -R -r 1.

Каждой очереди - по очистителю! :) Хороший лозунг и идеальный вариант
(кстати, так, по-моему, и в документации), но ведь в конечном итоге обычно
нужен не идеально логично построенный onconfig, а скорее неплохо (идеально
оптимально:)) работающая система на совершенно конкретном hardware.
Последнее достигается как раз мониторингом и мучительными раздумиями, в том
числе и "а не добавить ли еще CLEANERS для моих 128 LRUS?". ;)

> Если процент грязных буферов постоянно
> превышает LRU_MAX_DIRTY, значит количество CLEANERS маловато.

К несчастью, можно наблюдать то же самое и при CLEANERS=LRUS...

Eсть периоды работы систем, когда по той или иной причине более предпочтительны
chunk или LRU writes. Если преобладают первые, действительно хорошо бы иметь
клинеров по крайней мере столько, сколько имеется чанков, т.к. во время
чекпоинта IDS пытается назначить каждому чанку по клинеру. Если же,
напротив, есть заинтересованность выжать все, что можно из LRU writes ( а
это типичное OLTP), то я бы все-таки подходил более агрессивно к количеству
page-cleaners, и, с сожалением поглядывая на идеал (CLEANERS=LRUS), начинал
бы как-нибудь так: 8 клинеров при 8 очередях (оверхэд здесь обычно
небольшой, почему нет?), 8-12 при 16, 12-16 при 32, 16-24 при 64, ..., etc.
Хм... Но опять таки, сколько процессоров, сколько CPU VPs работает в
системе? Где-то я встречал такую рекомендацию - 4 cleaners на 1 CPU VP для
начала (подразумевается, что таковых несколько :)), что также дает легкий
намек и на потребляемые ими ресурсы... Кроме того, иногда бывает возможность
решить проблему CLEANERS/LRUS не наращиванием количества клинеров, а
увеличением длины очередей (уменьшением количества оных)...

Regards,
Alexey


Украинская баннерная сеть
 

[Home]

Сайт поддерживается группой пользователей Информикс на Украине.

Hosted by NO-more.