Денис_88Добрый день,
столкнулся с проблемой настройки производительности с репликацией.

Ситуация такова:есть высоконагруженная система, необходимо настроить репликацию с боевого сервера на резерв.

На 2 серверах(linux) прописал 2 одинаковых onconfig,все параметры информикса одинаковы (чанки,пространства,логика и физика) ,железо на секондари сервере меньше по памяти,но диски точно такие же как и на праймари.

Восстанавливаю на секондари физический бэкап, подключаю реплику и секондари догоняет праймари по логике.Все хорошо,все работает, НО:

при запуске приложения, которое активно удаляет временные таблицы или просто проводит высоконагруженные расчеты, приложение работает в 2 раза дольше,чем без репликации на этих же машинах с этими же данными.

checkpoint'ы на праймари делаются раз в минуту и их продолжительность 60-70сек в момент нагрузки.На секондари раз в минуту, продолжительность 0сек.

Подскажите плиз в чем может быть проблема?куда еще покопать?

Onconfig приложил.

Денис,
есть несколько гипотез относительно Вашей сиуации:

1. Длительность прохождения контрольной точки на primary (оптимизация контрольной точки).
2. Настройка параметров конфигурации - BUFFERPOOL, NETTYPE, DRINTERVAL, DRTIMEOUT.
3. Настрока сетевых интерфейсов для primary.
4. Наличие багов для текущей версии Informix (IBM Technical Support - APAR, PMR).
5. Наличие багов для текущей версии платформы (OS - TCP/IP).

С уважением,
Вадим.

GVF112GVFДенис_88Добрый день,
столкнулся с проблемой настройки производительности с репликацией.

Ситуация такова:есть высоконагруженная система, необходимо настроить репликацию с боевого сервера на резерв.

На 2 серверах(linux) прописал 2 одинаковых onconfig,все параметры информикса одинаковы (чанки,пространства,логика и физика) ,железо на секондари сервере меньше по памяти,но диски точно такие же как и на праймари.

Восстанавливаю на секондари физический бэкап, подключаю реплику и секондари догоняет праймари по логике.Все хорошо,все работает, НО:

при запуске приложения, которое активно удаляет временные таблицы или просто проводит высоконагруженные расчеты, приложение работает в 2 раза дольше,чем без репликации на этих же машинах с этими же данными.

checkpoint'ы на праймари делаются раз в минуту и их продолжительность 60-70сек в момент нагрузки.На секондари раз в минуту, продолжительность 0сек.

Подскажите плиз в чем может быть проблема?куда еще покопать?

Onconfig приложил.

Денис,
есть несколько гипотез относительно Вашей сиуации:

1. Длительность прохождения контрольной точки на primary (оптимизация контрольной точки).
2. Настройка параметров конфигурации - BUFFERPOOL, NETTYPE, DRINTERVAL, DRTIMEOUT.
3. Настрока сетевых интерфейсов для primary.
4. Наличие багов для текущей версии Informix (IBM Technical Support - APAR, PMR).
5. Наличие багов для текущей версии платформы (OS - TCP/IP).

С уважением,
Вадим.

После оптимизации контрольной точки,
oбратите внимание на настройки сетевого интерфеса NETTYPE на primary - сервере !!!

PS: Что-то подобное было у людей - http://www.dbforums.com/informix/893968-hdr-impact-db-performance.html

In the asymmetric configuration, the rule of a thumb to avoid long checkpoints in HDR pair:
SECONDARY MUST BE MORE POWERFUL THEN PRIMARY - more memory and more powerful disk subsystem, CPU power is not that important (unless you run out of CPU resources on Secondary).

Kind regards,
Vadim Golovsky.

Денис_88Спасибо всем за помощь,но некоторые моменты не понял:

Вадим:

1.Длительность прохождения контрольной точки на primary (оптимизация контрольной точки).--как этого добиться?Увеличением интервала?
2. Настройка параметров конфигурации - BUFFERPOOL, NETTYPE, DRINTERVAL, DRTIMEOUT.
-DRINTERVAL стоит на обоих серверах одинаковый и выставлен в 150.Как я понимаю,это просто время для соединения
-DRTIMEOUT ставил разный от 30 до 500.Тоже самое,причем производительность не меняется.
-BUFFERPOOL, NETTYPE -- стоит одинаково на 2 серверах и без реплики работает быстро.В какую сторону здесь смотреть?
3. Настрока сетевых интерфейсов для primary.--2 сервера находятся в 1 подсети, файлы по ssh передаются со скоростью 50Мбит/сек стабильно,так что это отпадает
4. Наличие багов для текущей версии Informix (IBM Technical Support - APAR, PMR).--версия на 2 серверах одна и та же+без реплики работает-значит наверное тоже отпадает
5. Наличие багов для текущей версии платформы (OS - TCP/IP).--так же как п.4

cpr,
все временные таблицы создаются с параметром with no log

Ikir,
то есть отработка контрольных точек идет у вас непрерывно. --Да,так и есть.Исправить увеличением интервала?

1.Длительность прохождения контрольной точки на primary (оптимизация контрольной точки).--как этого добиться?Увеличением интервала?

Нет, наоборот - уменьшением интервала ... :)

Длительность прохождения контрольной точки регулируется:
1. Частотой контрольной точки - CKPTINTVL (значением параметра - PHYSFILE, как быстро заполняется физический журнал).
У Вас установлен параметр AUTO_CKPTS 1, что в принципе нормально.

2. Эффективностью работы потоков чистильщиков (CLEANERS) между контрольными точками.
В данном случае нужно пересмотреть значение для BUFFERPOOL !!!

Например,
Я не знаю зачем нужен такой большой размер BUFFERPOOL (возможно, что так и надо)
BUFFERPOOL size=2K,buffers=5500000,lrus=256,lru_min_dirty=25.000000,lru_max_dirty=35.000000
на сброс 10% (грязныз страниц) этого буфера при скорости 50Мб/c, потребуется ~ 22 сек ... :)

Вы можете уменьшить значение buffers или установить меньшие пороги для lru_min_dirty и lru_max_dirty
(например, lru_min_dirty = 1 и lru_max_dirty = 3). Здесь нужно быть осторожным. Уменьшение порогов может
сократить длительность прохождение контрольной точки, но дополнительно нагрузить дисковую подсистему I/O.
Нужно выполнять мониторинг работы потоков чистильщиков (onstat -FR) и т.д.

-DRINTERVAL стоит на обоих серверах одинаковый и выставлен в 150.Как я понимаю,это просто время для соединения

Не совсем так.
Для асинхронной репликации, значение параметра DRINTERVAL, определяет верхний порог временного интервала, в течение которого репликационный буфер должен быть сброшен. Предпологается, что в течение этого интервала - primary-сервер,
отправит репликационный буфкр на secondary-сервер. Другими словами DRINTERVAL - определяет интервал времени, через который репликационный буфер должен быть отправлен на вторичный сервер.

-DRTIMEOUT ставил разный от 30 до 500.Тоже самое,причем производительность не меняется.

DRTIMEOUT specifies the upper limit of time that the Primary will wait for an acknowledgment from the Secondary until it assumes a data replication failure. Checkpoints on the Secondary must not exceed the DRTIMEOUT boundary. Primary and Secondary will also ping each other regardless if logical log records are send. DRTIMEOUT specifies the interval at which those pings are send. A HDR failure is assumed after four sequential ping attempts failed. So the DRTIMEOUT parameter should be set to 1/4 (25 %) of the total time that is appropriate before declaring a failure. This parameter must have the same value on the Primary and on the Secondary.

-BUFFERPOOL, NETTYPE -- стоит одинаково на 2 серверах и без реплики работает быстро.В какую сторону здесь смотреть?

Про BUFFERPOOL - было чуть выше ... :)

Внимательно посмотри onstat -g rea для HDR-потоков - http://www.dbforums.com/informix/893968-hdr-impact-db-performance.html
...
3) To make dr_send thread to use NET VP class. So, it will not hold back other processing in this queue as it will be the only thread
using the NET VP.

... and so on.

С уважением,
Вадим.

cprGVF112GVF,

т.е. я правильно понимаю, что когда запускаем onstat -g rea
, то потоков HDR не должно быть видно?
если они есть, то они чего то ждут?

The onstat -g rea command displays the threads that are on the ready queue and are awaiting a VP on which to run.

Если есть потоки HDR, то не хватает ресурсов VP (скорее всего VP CPU).

С уважением,
Вадим.

cprGVF112GVFпропущено...


The onstat -g rea command displays the threads that are on the ready queue and are awaiting a VP on which to run.

Если есть потоки HDR, то не хватает ресурсов VP (скорее всего VP CPU).

С уважением,
Вадим.

позвольте еще вопрос плиз.

по команде
onstat -g con |grep drcb_bqf

я вижу нить репликации ожидающую условие.
она в этом выводе присутствует всегда.
я правлиьно понимаю, что если waittime > 0 то это плохо?

и еще интересно в каких единицах этот waittime - в секундах?

Насколько Я помню в секундах ... :)
http://publib.boulder.ibm.com/infocenter/idshelp/v117/topic/com.ibm.adref.doc/ids_adr_0520.htm

onstat -g con |grep drcb_bqf

Thread waiting for buffer to show up on full Data Replication buffer queue.
Mutex "drcb_bqf" - the latch on the full replication buffer queue (by full this means that the buffer has data in it).

PS: To discover the session associated with the thread ID that is waiting on the condition, execute the following SQL statement against the sysmaster database, replacing the question mark (?) with the thread ID obtained from the onstat -g con output.
SELECT sid FROM rstcb WHERE tid = ?
This will return the session ID for the thread waiting on the condition. It is now possible to analyze the thread at the process level by using the process ID (pid) for the session.

С уважением,
Вадим Головский.

яфшуеіGVF112GVFНасколько Я помню в секундах ... :)
http://publib.boulder.ibm.com/infocenter/idshelp/v117/topic/com.ibm.adref.doc/ids_adr_0520.htm

onstat -g con |grep drcb_bqf

Thread waiting for buffer to show up on full Data Replication buffer queue.
Mutex "drcb_bqf" - the latch on the full replication buffer queue (by full this means that the buffer has data in it).

PS: To discover the session associated with the thread ID that is waiting on the condition, execute the following SQL statement against the sysmaster database, replacing the question mark (?) with the thread ID obtained from the onstat -g con output.
SELECT sid FROM rstcb WHERE tid = ?
This will return the session ID for the thread waiting on the condition. It is now possible to analyze the thread at the process level by using the process ID (pid) for the session.

С уважением,
Вадим Головский.

А теперь вернемся к изначальной проблеме - снижению производительности при выполнении некоего расчета.
Если заполнен буфер репликации а сессия нужно писать в лог - имеем что?
Правильно, имеем ожидание записи в лог журнал, тобишь в буфер лог журнала - определяется более простым и понятным
onstat -u.

Зная, что это происходит при включенном HDR можно сделать выводы:
1. тормозит сеть
2. тормозит железо на HDR
3. тормозит IDS на HDR
...

Сеть - проверяем время отклика и т.п.
Железо - чел. написал, что часть железа послабее.
IDS - смотрим количество каких ISAM операций увеличивается, либо анализируем лог.
"интенсивный" DELETE/UPDATE применяется на HDR дольше чем теже инсерты.
Если тормозит таки IDS и выявили на каких операторах - по логу/трассе и т.п. вычисляем
на каких это операторах "отчета".

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

Ну и сам обращающийся, говорит, что система высоконагруженная.
Чем определяется эта высонагруженность?
Во время к.т. как с использованием ресурсов на HDR?

Кстати, по поводу в 2 раза дольше - простая математика.
мы имеем изначально к.т. 1 раз в минуту продолжительностью 0-1 сек. и время расчета 1 едининца.
При включенном HDR мы имеем время выполнения к.т. 60 сек. при интервале 60 сек. и время выполнения расчета 2 ед.
Т.е. получается, что транзакции 60 сек. работают и 60 сек. стоят. в статусе C
Все логично, причина - долгое выполнение к.т. при включенной репликации.
Для выяснения причин этого, нужно как минимум смотерть на работу HDR сервера, предоставленной инфы мало.

Игорь,
что-то Я не понял - каким боком ты меня цетировать начал? К чему это все ?!

С уважением,
Вадим