Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR. / Informix

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Informix [игнор отключен] [закрыт для гостей] / Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

25 сообщений из 27, страница 1 из 2

все

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36441981

IDS Admin

Гость

Добрый день!

Столкнулся с проблемой - блокируется исполнение транзакций в БД. Проявляется только при включенной репликации.
Система OLTP. 100-200 запросов в секунду. (insert + Update/delete/select по ключу)
Их генерируют ~10 одновременных пользовательских процессов.
Поднята асинхронная репликация типа HDR (Системы одинаковые).

В один прекрасный момент:

1) На Primary сервере начинается КТ.
2) КТ на Primary заканчивается (судя по online.log). Начинается блокировка пользовательских транзакций. Все "встает".
3) Запись о КТ передается на Secondary. На это уходит ~10 секунд (!!!). Все это время висит блокировка.
4) На Secondary сервере начинается КТ.
5) На Secondary сервере заканчивается КТ. Все "отмерзает". Транзакции продолжают обрабатываться. Только пользовательскому софту уже все равно, т.к. превышено максимальное время обработки ((.

Только я обрадoвался механизму неблокирующих КТ - столкнулся с этой проблемой.
В моем примере блокировка длилась 14 секунд. Хотя на flush ушло только 2.7 секунды.
Не могу понять, на что уходят эти 14 секунд.

Буду рад любым комментариям. Пока даже не представляю, в каком направлении смотреть. Ниже некоторая информация. Спасибо

online.log на Primary

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.

10:57:02  Checkpoint Completed:  duration was 3 seconds.
10:57:02  Wed Jan 27 - loguniq 268, logpos 0x1c86e018, timestamp: 0x2fc62006 Interval: 562

10:57:02  Maximum server connections 46 
10:57:02  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 6, Plog used 200332, Llog used 96451

11:02:20  Checkpoint Completed:  duration was 2 seconds.
11:02:20  Wed Jan 27 - loguniq 268, logpos 0x3932a018, timestamp: 0x2fd4fcfd Interval: 563

11:02:20  Maximum server connections 46 
11:02:20  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 2, Plog used 239170, Llog used 118297

11:03:10  Logical Log 268 Complete, timestamp: 0x2fd71827.
11:07:37  Checkpoint Completed:  duration was 2 seconds.
11:07:37  Wed Jan 27 - loguniq 269, logpos 0x1b6fd018, timestamp: 0x2fe4b8ea Interval: 564

11:07:37  Maximum server connections 47 
11:07:37  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 1, Plog used 239816, Llog used 128964

11:12:54  Checkpoint Completed:  duration was 2 seconds.
11:12:54  Wed Jan 27 - loguniq 269, logpos 0x38f78018, timestamp: 0x2ff3ee0e Interval: 565

11:12:54  Maximum server connections 47 
11:12:54  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0, Plog used 239048, Llog used 121291

11:13:46  Logical Log 269 Complete, timestamp: 0x2ff631e9.
11:17:56  Checkpoint Completed:  duration was 2 seconds.
11:17:56  Wed Jan 27 - loguniq 270, logpos 0x19fa9018, timestamp: 0x3002c5d3 Interval: 566

11:17:56  Maximum server connections 47 
11:17:56  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 1, Plog used 221138, Llog used 123888

online.log на Secondary

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.

10:57:10  Checkpoint Completed:  duration was 0 seconds.
10:57:10  Wed Jan 27 - loguniq 268, logpos 0x1c86e018, timestamp: 0x2fc606ed Interval: 574

10:57:10  Maximum server connections 1 
10:57:10  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0, Plog used 341396, Llog used 0

11:02:31  Checkpoint Completed:  duration was 1 seconds.
11:02:31  Wed Jan 27 - loguniq 268, logpos 0x3932a018, timestamp: 0x2fd4e595 Interval: 575

11:02:31  Maximum server connections 1 
11:02:31  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0, Plog used 407259, Llog used 0

11:03:09  Logical Log 268 Complete, timestamp: 0x2fd70b55.
11:07:47  Checkpoint Completed:  duration was 0 seconds.
11:07:47  Wed Jan 27 - loguniq 269, logpos 0x1b6fd018, timestamp: 0x2fe4a0e3 Interval: 576

11:07:47  Maximum server connections 1 
11:07:47  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0, Plog used 433734, Llog used 0

11:13:05  Checkpoint Completed:  duration was 2 seconds.
11:13:05  Wed Jan 27 - loguniq 269, logpos 0x38f78018, timestamp: 0x2ff3e207 Interval: 577

11:13:05  Maximum server connections 1 
11:13:05  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0, Plog used 418300, Llog used 0

11:13:45  Logical Log 269 Complete, timestamp: 0x2ff625e0.
11:18:04  Checkpoint Completed:  duration was 0 seconds.
11:18:04  Wed Jan 27 - loguniq 270, logpos 0x19fa9018, timestamp: 0x3002b7c1 Interval: 578

11:18:04  Maximum server connections 1 
11:18:04  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0, Plog used 404859, Llog used 0

конфигурация HDR

Код: plaintext

1.
2.
3.
4.
5.
6.
7.

DRAUTO                  0
DRINTERVAL              20 #  async mode
DRTIMEOUT               60
HA_ALIAS
DRLOSTFOUND             $INFORMIXDIR/etc/dr.lostfound
DRIDXAUTO               0
LOG_INDEX_BUILDS

onstat -g dri

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

IBM Informix Dynamic Server Version 11.50.FC5W3   -- On-Line (Prim) -- Up 00:52:52 -- 23458472 Kbytes

Data Replication at 0x55f70b028: 
  Type           State        Paired server        Last DR CKPT (id/pg)    Supports Proxy Writes   
  primary        on           onldb24int                  271 / 76761      NA

  DRINTERVAL   20 
  DRTIMEOUT    60 
  DRAUTO       0 
  DRLOSTFOUND  /usr/informix/etc/dr.lostfound 
  DRIDXAUTO    0 
  ENCRYPT_HDR  0

syscheckpoint на Primary (спасибо за совет в соседнем треде)

Код: plaintext

1.
2.
3.
4.
5.

intvl	type		caller		clock_time	crit_time	flush_time	cp_time		n_dirty_buffs	plogs_per_sec	llogs_per_sec	
564	Non-Blocking	CKPTINTVL	1264579712	0.00006096	2.70645165	2.74568892	34541		756		406		

dskflush_per_sec	ckpt_logid	ckpt_logpos	physused	logused	n_crit_waits	tot_crit_wait	longest_crit_wait	block_time
12762			269		460312608	239816	128964		1		0.00876927		0.00876927	0.00000000

Блокировка началась в 11:07:37:17 , закончилась в 11:07:51:52 .

...

Рейтинг:

0 / 0

01.02.2010, 13:07

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36442188

victor16

Гость

Можно посмотреть onstat -g ckp

...

Рейтинг:

0 / 0

01.02.2010, 14:14

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36446360

Andron

Участник

Откуда: Cherepovets

Сообщения: 1 825

Рейтинг: 0 / 0

У вас точно используются неблокирующие КТ? узнать это можно посмотрев вывод onstat -g ckp
И по вашему логу primary видно например вот это (выделено жирным) что косвенно говорит что возможно транзакции блокируются:

10:57:02 Checkpoint Completed: duration was 3 seconds.
10:57:02 Wed Jan 27 - loguniq 268, logpos 0x1c86e018, timestamp: 0x2fc62006 Interval: 562

10:57:02 Maximum server connections 46
10:57:02 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 6 , Plog used 200332, Llog used 96451

11:02:20 Checkpoint Completed: duration was 2 seconds.
11:02:20 Wed Jan 27 - loguniq 268, logpos 0x3932a018, timestamp: 0x2fd4fcfd Interval: 563

11:02:20 Maximum server connections 46
11:02:20 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 2 , Plog used 239170, Llog used 118297

11:03:10 Logical Log 268 Complete, timestamp: 0x2fd71827.
11:07:37 Checkpoint Completed: duration was 2 seconds.
11:07:37 Wed Jan 27 - loguniq 269, logpos 0x1b6fd018, timestamp: 0x2fe4b8ea Interval: 564

11:07:37 Maximum server connections 47
11:07:37 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 1 , Plog used 239816, Llog used 128964
...

И как вариант, посмотрите что с сетью между primary и secondary.

...

Рейтинг:

0 / 0

03.02.2010, 10:42

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36448168

zaiets

Гость

по поводу 14 сек это токо я не увидел по логу?

если тормозит HDR при к.т. то вполне возможно что у вас проблема на HDR сжелезом
нет, не в том плане что там что-то поломалось, а в том, что оно медленнее
Чтоб там не говорили, а на HDR должны быть:
1. дискавая система аналогичная основному
обратите внимание на работу с физ. журналом
2. быстрый проц (не количество, а именно быстрый/мощный)

...

Рейтинг:

0 / 0

03.02.2010, 21:19

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36450747

АнатоЛой

Участник

Откуда: Киев, Украина

Сообщения: 2 910

Рейтинг: 0 / 0

IDS Admin

Блокировка началась в 11:07:37:17 , закончилась в 11:07:51:52 .
И точно - откуда "цифры"?

...

Рейтинг:

0 / 0

04.02.2010, 22:13

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36451296

IDS Admin

Гость

АнатоЛой, zaiets,

И точно - откуда "цифры"?

Цифра из лога приложения. 14 секунд - это фактическое время блокировки. Приложение работает в несколько потоков. Все они "замерзают" на операции insert, либо update. В логи приложения попадает время начала insert/update и время окончания. Судя по этим логам, блокировка длилась ровно 14 секунд. В обычном режиме на каждую такую транзакцию уходит менее 10 мс.

С сетью все в порядке. Там всего 3 машины (приложения, IDS Primary, IDS Secondary). Гигабитная циска.

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

Primary

Код: plaintext

1.
2.
3.

time dd if=/dev/zero of=temp_of bs=4096 count=100000 oflag=direct
100000+0 records in
100000+0 records out
409600000 bytes (410 MB) copied, 5.36903 seconds, 76.3 MB/s

Secondary

Код: plaintext

1.
2.
3.

time dd if=/dev/zero of=temp_of bs=4096 count=100000 oflag=direct
100000+0 records in
100000+0 records out
409600000 bytes (410 MB) copied, 5.17446 seconds, 79.2 MB/s

Еще один пример такой блокировки:
Primary onstat -g ckp

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.

IBM Informix Dynamic Server Version 11.50.FC5W3   -- On-Line (Prim) -- Up 1 days 17:05:13 -- 23458472 Kbytes

AUTO_CKPTS=Off   RTO_SERVER_RESTART=Off

                                                                    Critical Sections                          Physical Log    Logical Log
           Clock                                  Total Flush Block #      Ckpt  Wait  Long  # Dirty   Dskflu  Total    Avg    Total    Avg
Interval   Time      Trigger    LSN               Time  Time  Time  Waits  Time  Time  Time  Buffers   /Sec    Pages    /Sec   Pages    /Sec
12934      08:31:34  CKPTINTVL  1590:0xab8b018    0.7   0.7   0.0   1      0.0   0.0   0.0   15183     15183   471      1      100721   335
12935      08:36:34  CKPTINTVL  1590:0x27047018   0.7   0.7   0.0   0      0.0   0.0   0.0   15658     15658   448      1      116170   387
12936      08:41:35  CKPTINTVL  1591:0x5f83018    0.8   0.8   0.0   1      0.0   0.0   0.0   15077     15077   442      1      114912   381
12937      08:46:35  CKPTINTVL  1591:0x1ebac018   0.7   0.7   0.0   1      0.0   0.0   0.0   15724     15724   460      1      101667   338
12938      08:51:38  CKPTINTVL  1592:0x6cb018     3.2   3.2   0.0   1      0.0   0.0   0.0   29572     9207    51831    172    126733   422
12939      08:56:46  CKPTINTVL  1592:0x218cc018   3.1   3.1   0.0   1      0.0   0.0   0.0   34202     11110   69187    224    136542   443
12940      09:01:55  CKPTINTVL  1593:0x2fda018    2.8   2.8   0.0   4      0.0   0.0   0.0   34204     12193   70076    226    125691   405
12941      09:07:05  CKPTINTVL  1593:0x2423a018   2.6   2.6   0.0   1      0.0   0.0   0.0   34319     13336   69773    225    136630   440
12942      09:12:16  CKPTINTVL  1594:0x8729470    2.6   2.5   0.0   4      0.0   0.0   0.0   34254     13726   69610    223    137436   441
12943      09:17:26  CKPTINTVL  1594:0x29708018   2.7   2.6   0.0   0      0.0   0.0   0.0   34330     13011   69105    222    135486   437
12944      09:22:28  CKPTINTVL  1595:0xb47e018    2.7   2.6   0.0   2      0.0   0.0   0.0   34302     13084   69138    228    127327   421
12945      09:27:39  CKPTINTVL  1595:0x2cc47280   2.6   2.4   0.0   0      0.0   0.0   0.0   33810     13921   67430    216    138021   443
12946      09:32:48  CKPTINTVL  1596:0xeb1e018    1.9   1.9   0.0   1      0.0   0.0   0.0   27364     14456   44232    142    127404   410
12947      09:37:55  CKPTINTVL  1596:0x27d46018   0.8   0.8   0.0   1      0.0   0.0   0.0   15551     15551   458      1      103225   335
12948      09:42:55  CKPTINTVL  1597:0x67c6018    0.7   0.7   0.0   1      0.0   0.0   0.0   15344     15344   452      1      113684   378
12949      09:47:56  CKPTINTVL  1597:0x22630018   0.8   0.8   0.0   0      0.0   0.0   0.0   15189     15189   471      1      114564   380
12950      09:52:56  CKPTINTVL  1597:0x3b355018   0.8   0.8   0.0   1      0.0   0.0   0.0   15612     15612   483      1      101958   339
12951      09:57:56  CKPTINTVL  1598:0x1a1e2018   0.8   0.8   0.0   1      0.0   0.0   0.0   15771     15771   482      1      114757   382
12952      10:02:58  CKPTINTVL  1598:0x32cad018   1.1   1.0   0.0   1      0.0   0.0   0.0   34341     33682   456      1      101473   337
12953      10:07:58  CKPTINTVL  1599:0xe4e7018    0.9   0.9   0.0   1      0.0   0.0   0.0   15951     15951   475      1      100888   335

Max Plog       Max Llog       Max Dskflush   Avg Dskflush   Avg Dirty      Blocked
pages/sec      pages/sec      Time           pages/sec      pages/sec      Time
200            200            74             13493          44             0

online.log

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

09:20:44  Logical Log 1594 Complete, timestamp: 0x379ec93.
09:22:29  Checkpoint Completed:  duration was 2 seconds.
09:22:29  Fri Feb  5 - loguniq 1595, logpos 0xb47e018, timestamp: 0x37f20ba Interval: 12944

09:22:29  Maximum server connections 88 
09:22:29  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 2, Plog used 69138, Llog used 127327

09:27:39  Checkpoint Completed:  duration was 2 seconds.
09:27:39  Fri Feb  5 - loguniq 1595, logpos 0x2cc47280, timestamp: 0x38e9a31 Interval: 12945

09:27:39  Maximum server connections 88 
09:27:39  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0, Plog used 67430, Llog used 138021

09:30:10  Logical Log 1595 Complete, timestamp: 0x3961779.
09:32:49  Checkpoint Completed:  duration was 1 seconds.
09:32:49  Fri Feb  5 - loguniq 1596, logpos 0xeb1e018, timestamp: 0x39af5cb Interval: 12946

Secondary onstat -g ckp

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.

IBM Informix Dynamic Server Version 11.50.FC5W3   -- Read-Only (Sec) -- Up 1 days 01:10:15 -- 23458472 Kbytes

AUTO_CKPTS=Off   RTO_SERVER_RESTART=Off

                                                                    Critical Sections                          Physical Log    Logical Log
           Clock                                  Total Flush Block #      Ckpt  Wait  Long  # Dirty   Dskflu  Total    Avg    Total    Avg
Interval   Time      Trigger    LSN               Time  Time  Time  Waits  Time  Time  Time  Buffers   /Sec    Pages    /Sec   Pages    /Sec
12946      08:31:36 *Recovery   1590:0xab8b018    0.0   0.0   0.0   0      0.0   0.0   0.0   2         2       186280   625    0        0
12947      08:36:40 *Recovery   1590:0x27047018   0.0   0.0   0.0   0      0.0   0.0   0.0   0         0       230955   759    0        0
12948      08:41:39 *Recovery   1591:0x5f83018    0.0   0.0   0.0   0      0.0   0.0   0.0   2         2       227072   759    0        0
12949      08:46:38 *Recovery   1591:0x1ebac018   0.0   0.0   0.0   0      0.0   0.0   0.0   1         1       188816   631    0        0
12950      08:51:43 *Recovery   1592:0x6cb018     1.2   0.0   0.0   0      0.0   0.0   0.0   22        22      261992   858    0        0
12951      08:56:53 *Recovery   1592:0x218cc018   2.5   0.0   0.0   0      0.0   0.0   0.0   23        23      270202   874    0        0
12952      09:02:02 *Recovery   1593:0x2fda018    2.4   0.0   0.0   0      0.0   0.0   0.0   23        23      238660   772    0        0
12953      09:07:14 *Recovery   1593:0x2423a018   2.0   0.0   0.0   0      0.0   0.0   0.0   21        21      267384   857    0        0
12954      09:12:23 *Recovery   1594:0x8729470    1.8   0.0   0.0   0      0.0   0.0   0.0   23        23      271051   874    0        0
12955      09:17:34 *Recovery   1594:0x29708018   1.9   0.0   0.0   0      0.0   0.0   0.0   22        22      267690   866    0        0
12956      09:22:37 *Recovery   1595:0xb47e018    2.4   0.0   0.0   0      0.0   0.0   0.0   23        23      238677   785    0        0
12957      09:27:47 *Recovery   1595:0x2cc47280   1.8   0.0   0.0   0      0.0   0.0   0.0   21        21      271284   877    0        0
12958      09:32:55 *Recovery   1596:0xeb1e018    3.0   0.0   0.0   0      0.0   0.0   0.0   26        26      261798   849    0        0
12959      09:38:04 *Recovery   1596:0x27d46018   3.0   0.0   0.0   0      0.0   0.0   0.0   0         0       191711   620    0        0
12960      09:43:01 *Recovery   1597:0x67c6018    0.0   0.0   0.0   0      0.0   0.0   0.0   2         2       226479   757    0        0
12961      09:48:01 *Recovery   1597:0x22630018   0.0   0.0   0.0   0      0.0   0.0   0.0   5         5       226790   755    0        0
12962      09:53:02 *Recovery   1597:0x3b355018   0.0   0.0   0.0   0      0.0   0.0   0.0   4         4       188775   627    0        0
12963      09:58:03 *Recovery   1598:0x1a1e2018   1.5   0.0   0.0   0      0.0   0.0   0.0   7         7       227765   756    0        0
12964      10:03:01 *Recovery   1598:0x32cad018   0.0   0.0   0.0   0      0.0   0.0   0.0   1         1       200588   673    0        0
12965      10:08:03 *Recovery   1599:0xe4e7018    0.0   0.0   0.0   0      0.0   0.0   0.0   2         2       186550   617    0        0

Max Plog       Max Llog       Max Dskflush   Avg Dskflush   Avg Dirty      Blocked
pages/sec      pages/sec      Time           pages/sec      pages/sec      Time
200            200            0              1              0              0

online.log

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.

09:22:37  Checkpoint Completed:  duration was 3 seconds.
09:22:37  Fri Feb  5 - loguniq 1595, logpos 0xb47e018, timestamp: 0x37f0b71 Interval: 12956

09:22:37  Maximum server connections 1 
09:22:37  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0, Plog used 238677, Llog used 0

09:27:47  Checkpoint Completed:  duration was 2 seconds.
09:27:47  Fri Feb  5 - loguniq 1595, logpos 0x2cc47280, timestamp: 0x38e843d Interval: 12957

09:27:47  Maximum server connections 1 
09:27:47  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0, Plog used 271284, Llog used 0

09:30:09  Logical Log 1595 Complete, timestamp: 0x3961604.
09:32:56  Checkpoint Completed:  duration was 3 seconds.
09:32:56  Fri Feb  5 - loguniq 1596, logpos 0xeb1e018, timestamp: 0x39aec9c Interval: 12958

09:32:56  Maximum server connections 1 
09:32:56  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0, Plog used 261798, Llog used 0

начало пользовательской транзакции 09:27:38:98
оконячание пользовательской транзакции 09:27:47:82.

Почему КТ на Secondary начинается спустя 8 секунд после начала КТ на Primary? Чем вообще сервер занят в это время?

У меня пока только одно предположение: Secondary при большой нагрузке всегда "отстает" от Primary (еще не обработал последние записи в логическом журнале). А во время КТ Secondary должен "догнать" Primary, чем он и занимается, блокируя мои транзакции.

Попробую уменьшить DRINTERVAL чтоли...

...

Рейтинг:

0 / 0

05.02.2010, 10:49

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36452851

zaiets

Гость

а чего нити ожидают в проблемный момент?

Как рассказывал саппорт, при асинхронной репликации не все так просто, обещали включить описание в документацию.
IC65029 IDS 11.50 DOCUMENTATION CONTAINS LIMITED INFORMATION ON THE TRANSFER OF HDR LOGICAL LOG BUFFERS

но, вы все оцениваете с позиции прикладного ПО
то что время к.т. на серверах разное, может также говорить и
о расхождении времени на серверах.
при отстуствии нагрузки или при минимальной нагрузке - толже 8 сек. расхождения?

чтобы со 100% вероятностью утверждать, что виновата к.т. - нужно состояние нитей на момент проблемы.

хотя, судя по статистике, не так и много здесь людей с вашей транзакционной активностью
Бывают ли у вас в процессе работы нити в состоянии G как много и как часто?

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

Если, допустим, выполнять к.т. вручную раз в 1 минуту - теже задержки или нет?

В каком логгируемом состоянии у вас БД?
какие:
PHYSBUFF
LOGBUFF
BUFFERPOOL
AUTO_LRU_TUNING
ON_RECVRY_THREADS
OFF_RECVRY_THREADS
в DBSPACETEMP - перечислены только временные?

Если у вас проблема всетаки в Информиксе- ваш случай интересный.
Можно в принципе и более тесно пообщаться в аське (zaiets 5..)

...

Рейтинг:

0 / 0

05.02.2010, 19:41

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36453246

victor16

Гость

Я бы предложил:
- поскольку гигабитная сетка сделать таки репликацию синхронной (DRINTERVAL -1)
- проверить системное время на обоих серваках, мы для этой цели используем ntpd
- хоть в предыдущей ветке и не советовали (там советы больше касаются 9-ой версии), установить AUTO_CKPTS=1 и RTO_SERVER_RESTART=60. Это заставит LRU быть более агрессивным. Правда, возможно, потребуются дополнительные настройки параметров журналов.
- проверить таки целесообразность большого буферного пула командой onstat -P. Если величина поля other большая, то однозначно лучше уменьшить буферный пул, а освободившуюся память отдать под словарный кэш (DD_HASHSIZE и DD_HASHMAX) и кэш распределения данных (DS_HASHSIZE и DS_HASHMAX). У Вас установлены значения по умолчанию, они очень маленькие (см. Perfomance Guide).
- что касается bufwaits, можно воспользоваться небольшой утилиткой:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.

onstat -p | awk '
/[a-zA-Z]/{
 for (i=1; i <= NF ; i++ ) {
               name[i]=$i ;
 }

 }
/[0-9]/{
 for (i=1; i <= NF ; i++ ) {
               content[name[i]]=$i ;
 }
 }
END {
 ixdaRA = content["ixda-RA"];
 idxRA = content["ixd-RA"];
 daRA = content["da-RA"];
 RApgsused = content["RA-pgsused"];
 print "Read Utilization (UR): ",((RApgsused /( ixdaRA + idxRA + daRA) )*100),"%";

 bufwaits = content["bufwaits"];
 bufwrits = content["bufwrits"];
 pagreads = content["pagreads"];
 print "BufWaits Ratio(BR): ", ((bufwaits/(pagreads + bufwrits)) *100),"%";

 }
'

Если коэффициент bufwaits находится в пределах 2-7, то с большой долей вероятности можно сказать, что буферный пул настроен правильно. Меньше двух - уменьшать, больше 10 - увеличивать (с оговорками).
- не совсем в тему, но крайне не рекомендую переходить на FC6, даже W1, Вам лучше проапгрейдится до FC5W4, на мой взгляд самая стабильная версия из читы.

С уважением,
Виктор

...

Рейтинг:

0 / 0

06.02.2010, 10:16

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36470495

zaiets

Гость

чем-то закончилась история?

...

Рейтинг:

0 / 0

15.02.2010, 16:55

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36470717

vasilis

Участник

Откуда: Украина, Киев

Сообщения: 2 212

Рейтинг: 0 / 0

victor16
- хоть в предыдущей ветке и не советовали (там советы больше касаются 9-ой версии), установить AUTO_CKPTS=1 и RTO_SERVER_RESTART=60. Это заставит LRU быть более агрессивным.
Так ведь до этого и было "на автомате" и никакой "агрессивности" не проявлялось
victor16
Если коэффициент bufwaits находится в пределах 2-7, то с большой долей вероятности можно сказать, что буферный пул настроен правильно. Меньше двух - уменьшать, больше 10 - увеличивать (с оговорками).
Помнится, кто-то из зубров UCDI писал. что "Anything over 7% is slow and over 10% is death".
Я правильно понял, что это рекомендации "в общем", а не для конкретной системы ?
Тогда зачем уменьшать пул если bufwaits < 2 , особенно если нет проблем с КТ ?
На мелких и средних системах bufwaits обычно и равен 0 без больших размеров пула и уменьшать там его вовсе незачем.

...

Рейтинг:

0 / 0

15.02.2010, 18:06

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36470819

IDS Admin

Гость

zaietsчем-то закончилась история?

Пока пауза, т.к. нет доступа к серверам... Позже продолжу и обязательно отпишу.

...

Рейтинг:

0 / 0

15.02.2010, 18:40

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36471211

victor16

Гость

vasilisvictor16
- хоть в предыдущей ветке и не советовали (там советы больше касаются 9-ой версии), установить AUTO_CKPTS=1 и RTO_SERVER_RESTART=60. Это заставит LRU быть более агрессивным.
Так ведь до этого и было "на автомате" и никакой "агрессивности" не проявлялось
[/quot]

В предыдущих версиях IDS инициировать контрольную точку могут следующие четыре условия:
Административные события, например: архивирование, добавление пространства базы данных(dbspace), начальная загрузка или выключение сервера и т.д.

75-процентное заполнение физического журнала.

Наличие всего одной контрольной точки в пространстве логического журнала (сервер IDS не может перезаписать логический журнал, содержащий текущую контрольную точку, поэтому IDS сначала инициирует контрольную точку и лишь затем перемещает данные в этот логический журнал).

Активированный конфигурационный параметр CKPTINTVL в файле ONCONFIG
В версии IDS Version 11.10 появилась новая функция, которая позволяет серверу IDS автоматически переключать контрольные точки. При активированном конфигурационном параметре RTO_SERVER_RESTART сервер IDS сопоставляет показатели прошлого быстрого восстановления с текущей транзакционной активностью и на этом основании автоматически инициирует контрольные точки с целью соблюдения обеих политик – политики RTO_SERVER_RESTART и политики прогнозируемого времени отклика транзакций. Поэтому параметр AUTO_CKPTS, хоть и был включен, но не работал, поскольку RTO_SERVER_RESTART не был активирован.
vasilisvictor16Если коэффициент bufwaits находится в пределах 2-7, то с большой долей вероятности можно сказать, что буферный пул настроен правильно. Меньше двух - уменьшать, больше 10 - увеличивать (с оговорками).
Помнится, кто-то из зубров UCDI писал. что "Anything over 7% is slow and over 10% is death".
Я правильно понял, что это рекомендации "в общем", а не для конкретной системы ?
Тогда зачем уменьшать пул если bufwaits < 2 , особенно если нет проблем с КТ ?
На мелких и средних системах bufwaits обычно и равен 0 без больших размеров пула и уменьшать там его вовсе незачем.
В реальных системах показатель bufwaits никогда не равен нулю, тем не менее надо стремится к его минимизации. На самом деле, внимание надо обращать не на сам показатель bufwaits, а его отношение (bufwaits ratio) к сумме pagreads+bufwrits (см. выше пример на awk), поскольку эти операции блокируют LRU-очереди и чаще всего приводят к увеличению bufwaits. Для более точного анализа нужен вывод команды onstat -P. Показатель other показывает количество неиспользуемых страниц буферного пула. И если этот показатель больше 5% вкупе с bufwaits ratio<2%, однозначно надо уменьшать буферный пул. Хоть механизм контрольной точки в 11 версии и является неблокирующим, тем не менее при большом буферном пуле производительность в этот момент резко падает. В этом случае, более эффективным решением будет отдать память под словарный кэш, кэш распределения данных, кэш хранимых процедур и кэш sql-запросов.

С уважением,
Виктор

...

Рейтинг:

0 / 0

15.02.2010, 22:53

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36471680

Daugava

Участник

Откуда: Riga-Kiev-Gurzuf

Сообщения: 718

Рейтинг: 0 / 0

vasilis
Помнится, кто-то из зубров UCDI писал. что "Anything over 7% is slow and over 10% is death".

Справедливости ради, англоязычные зубры водились и до сих пор бродят по CDI .
В UCDI похоже даже спамеры забыли дорогу и подобной дискуссии я там не помню.

...

Рейтинг:

0 / 0

16.02.2010, 09:31

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36471964

IDS Admin

Гость

zaietsа чего нити ожидают в проблемный момент?
...
чтобы со 100% вероятностью утверждать, что виновата к.т. - нужно состояние нитей на момент проблемы.

Чуть позже скину результат onstat-u в проблемный момент. Только что запустил "мониторинг".

zaiets
но, вы все оцениваете с позиции прикладного ПО
то что время к.т. на серверах разное, может также говорить и
о расхождении времени на серверах.
при отстуствии нагрузки или при минимальной нагрузке - толже 8 сек. расхождения?

Время синхронизируется с одних и тех же NTP серверов. Проверял несколько раз - время одинаковое на Primary и Seсondary. Повторюсь: железо одинаковое абсолютно. Драйвера, прошивки в том числе.

zaiets
В каком логгируемом состоянии у вас БД?
какие:
PHYSBUFF
LOGBUFF
BUFFERPOOL
AUTO_LRU_TUNING
ON_RECVRY_THREADS
OFF_RECVRY_THREADS
в DBSPACETEMP - перечислены только временные?

- Unbuffered logging

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

PHYSFILE        16500000        
PHYSBUFF 256
LOGBUFF 64
BUFFERPOOL	default,buffers=10000,lrus=8,lru_min_dirty=50.000000,lru_max_dirty=60.500000
BUFFERPOOL	size=2K,buffers=4000000,lrus=500,lru_min_dirty=0.300000,lru_max_dirty=0.600000
BUFFERPOOL	size=8K,buffers=1500000,lrus=500,lru_min_dirty=0.700000,lru_max_dirty=1.400000

AUTO_LRU_TUNING 0

ON_RECVRY_THREADS  1
OFF_RECVRY_THREADS 10

Да, в DBSPACETEMP только временные DBS (flags 'N TB')

vasilis ранее уже любезно советовал изменить размер физ. журнала. Уменьшали до 2ГБ, жили пару дней, изменений не заметили и вернули назад, т.к. вроде бы "хлеба не просит". Хотя, очень даже вероятно, не там смотрели результат изменения размера физ. журнала. В любом случае, его можно менять при включенной БД, чего не скажешь о BUFFERPOOL.

...

Рейтинг:

0 / 0

16.02.2010, 11:19

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36472005

IDS Admin

Гость

victor16Я бы предложил:
- поскольку гигабитная сетка сделать таки репликацию синхронной (DRINTERVAL -1)
Пробовал, сильно (примерно на 50-80%) увеличилось время работы одного из ежедневных процессов (удаление старых данных). Насколько я понимаю, это еще и следствие unbuff_logging

victor16
- проверить таки целесообразность большого буферного пула командой onstat -P. Если величина поля other большая, то однозначно лучше уменьшить буферный пул

В конце этого поста выложил onstat -p и onstat -P.

victor16
, а освободившуюся память отдать под словарный кэш (DD_HASHSIZE и DD_HASHMAX) и кэш распределения данных (DS_HASHSIZE и DS_HASHMAX). У Вас установлены значения по умолчанию, они очень маленькие (см. Perfomance Guide).

Спасибо, увеличил, как только прочел пост.

victor16
- что касается bufwaits, можно воспользоваться небольшой утилиткой

Вот результат ее работы, сервер неделю не обнулял статистику и работал в обычном режиме.

Код: plaintext

Read Utilization (UR):  99.7938 %
BufWaits Ratio(BR):  0.341804 %

victor16
- не совсем в тему, но крайне не рекомендую переходить на FC6, даже W1, Вам лучше проапгрейдится до FC5W4, на мой взгляд самая стабильная версия из читы.
Ок, будем ждать

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.

onstat -p

IBM Informix Dynamic Server Version 11.50.FC5W3   -- On-Line (Prim) -- Up 8 days 07:56:21 -- 23469108 Kbytes

Profile
dskreads   pagreads   bufreads   %cached dskwrits   pagwrits   bufwrits   %cached
364020343  3238800123 76548507839 99.52   434495522  1099601192 980017167  55.95

isamtot    open       start      read       write      rewrite    delete     commit     rollbk
70256475223 101518718  433274429  65068574988 22012513   255519113  19092613   256517437  1

gp_read    gp_write   gp_rewrt   gp_del     gp_alloc   gp_free    gp_curs
0          0          0          0          0          0          0

ovlock     ovuserthread ovbuff     usercpu  syscpu   numckpts   flushes
0          0            0          194203.25 26957.89 44272      45416

bufwaits   lokwaits   lockreqs   deadlks    dltouts    ckpwaits   compress   seqscans
14403654   414960     92618642301 1          0          19559      3997140    2056789

ixda-RA    idx-RA     da-RA      RA-pgsused lchwaits
10889929   47         249811414  260163791  3104716

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.

onstat -P

IBM Informix Dynamic Server Version 11.50.FC5W3   -- On-Line (Prim) (CKPT INP) -- Up 8 days 07:58:34 -- 23469108 Kbytes

Buffer pool page size: 2048
partnum  total    btree    data     other    dirty   
0        71736    1920     69784    32       0       
1048577  233      0        224      9        0       
1048578  3        1        1        1        0       
...  
10485772 982      807      0        175      0       
10485773 913      798      0        115      0       

Totals:  4000000  1259355  2660037  80608    81      

Percentages:
Data  66.50 
Btree 31.48 
Other 2.02  

Buffer pool page size: 8192
partnum  total    btree    data     other    dirty   
0        145      91       54       0        0       
11534337 2        0        1        1        0       
11534338 412734   0        412574   160      8       
11534339 234      233      0        1        1       
12582913 8        0        7        1        1       
12582914 5677     5671     0        6        8       
12582915 561      488      0        73       1       
12582916 12534    12533    0        1        13      
12582917 12045    12044    0        1        10      
12582918 10805    10804    0        1        7       
12582919 56       56       0        0        2       
12582920 9987     9986     0        1        7       
12582921 6298     6298     0        0        8       
13631489 3        0        2        1        0       
13631490 999136   0        999133   3        1490    
13631491 5528     5527     0        1        1       
14680065 8        0        7        1        0       
14680066 4047     4046     0        1        9       
14680067 4104     4103     0        1        11      
14680068 6544     6519     0        25       11      
14680069 78       77       0        1        3       
14680070 284      283      0        1        4       
14680071 20       19       0        1        1       
14680072 334      315      0        19       1       
14680073 129      123      0        6        3       
14680074 8699     8698     0        1        11      

Totals:  1500000  87914    1411778  308      1611    

Percentages:
Data  94.12 
Btree 5.86  
Other 0.02

...

Рейтинг:

0 / 0

16.02.2010, 11:37

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36472272

victor16

Гость

Если следовать рекомендациям, то буферный пул настроен верно, правда, с некоторым перекосом в сторону 2K страниц, поскольку основные операции по изменению данных ведутся в 8K страницах (total dirty=1611), 2K страницы используются только для чтения (total dirty=81). Тогда риторический вопрос: второй сервер с какой целью используется? Возможно ли распределить нагрузку между двумя серверами?

...

Рейтинг:

0 / 0

16.02.2010, 13:04

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36472460

IDS Admin

Гость

victor16Если следовать рекомендациям, то буферный пул настроен верно, правда, с некоторым перекосом в сторону 2K страниц, поскольку основные операции по изменению данных ведутся в 8K страницах (total dirty=1611), 2K страницы используются только для чтения (total dirty=81). Тогда риторический вопрос: второй сервер с какой целью используется? Возможно ли распределить нагрузку между двумя серверами?

Ну, возможно, это был не самый удачный момент)
Грязных страниц по 2к примерно в 7-8 раз меньше (по кол-ву), чем грязных страниц по 8к. Самые "тяжелые" вещи как раз в 8к лежат. Запросы INSERT / DELETE, порождаемые OLTP как раз по табличкам из 8ми килобайтных ДБС проходят. UPDATE по табличкам из 2х килобайтных ДБСов. Селекты и там и там в разнобой. Есть и по ПК запросы, и фулл-сканы.

Второй сервер используется как горячий бекап. На самый черный день )

...

Рейтинг:

0 / 0

16.02.2010, 14:01

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36472593

victor16

Гость

В таком случае могу предложить два совершенно противоположных решения:
1) Дать права на запись второму серверу (UPDATABLE_SECONDARY>0) и распределить нагрузку между двумя серверами через Connection Manager. В этом случае предстоят дополнительные усилия по настройке и синхронизации, правда, овчинка выделки стоит, можно получить "dramatically improved perfomance", как обещает Perfomance Guide.
2) Сделать из второго сервера RSS и забыть про проблемы синхронизации контрольной точки.

...

Рейтинг:

0 / 0

16.02.2010, 14:46

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36473472

vasilis

Участник

Откуда: Украина, Киев

Сообщения: 2 212

Рейтинг: 0 / 0

Daugavavasilis
Помнится, кто-то из зубров UCDI писал. что "Anything over 7% is slow and over 10% is death".

Справедливости ради, англоязычные зубры водились и до сих пор бродят по CDI .
В UCDI похоже даже спамеры забыли дорогу и подобной дискуссии я там не помню.

Да, ты прав, буковка U была лишней :)

...

Рейтинг:

0 / 0

16.02.2010, 19:17

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36473510

vasilis

Участник

Откуда: Украина, Киев

Сообщения: 2 212

Рейтинг: 0 / 0

victor16
vasilis
victor16Если коэффициент bufwaits находится в пределах 2-7, то с большой долей вероятности можно сказать, что буферный пул настроен правильно. Меньше двух - уменьшать, больше 10 - увеличивать (с оговорками).
Помнится, кто-то из зубров UCDI писал. что "Anything over 7% is slow and over 10% is death".
Я правильно понял, что это рекомендации "в общем", а не для конкретной системы ?
Тогда зачем уменьшать пул если bufwaits < 2 , особенно если нет проблем с КТ ?
На мелких и средних системах bufwaits обычно и равен 0 без больших размеров пула и уменьшать там его вовсе незачем.
В реальных системах показатель bufwaits никогда не равен нулю...
По вашему "реальные системы" это большие и всегда тяжело нагруженные? А мне кажется, что "реальные", это те промсистемы, которые реально встречаются в жизни, работают по много лет и на разных железках и поверьте, я их видел не одну сотню, от самых маленьких и слабо нагруженных (но тем не менеее, таких же реальных и нужных) до больших. Я ведь не зря спрашивал - ваши советы "в общем", для любой системы, или же для ТС и его системы ? Специфика все же остается и ее нужно упоминать.
victor16
На самом деле, внимание надо обращать не на сам показатель bufwaits, а его отношение (bufwaits ratio) к сумме pagreads+bufwrits (см. выше пример на awk),
Именно о коеффициенте речь выше и шла, надеюсь, что никто не воспринимал значения 2, 7 или 10 как абсолютные величины.
victor16
И если этот показатель больше 5% вкупе с bufwaits ratio<2%, однозначно надо уменьшать буферный пул.
Еще раз спрошу - зачем? (опять таки в контексте общих рекомендаций, а не конкретной системы ТС и в контексте того, что читают топик и другие админы совершенно разных систем). Если буферный пул и так маленький (всего 400-600М), bufwaits ratio =1%, проблем с КТ нет вообще - зачем уменьшать буферный пул в данном случае и доводить bufwaits ratio до 2 или 5% и создавать будущие проблемы производительности при регламентых задачах (ночных, месячных, квартальных...) для которых как раз и потребуется больший буферный пул ?
Просто я уже представляю, как начитавшись таких рекомендаций и не имея большого и комплексного понимания, многие "админы" (а я таких знаю очень много :) начнут "настраивать" IDS по рекомендациям. которые годятся для больших, транзакционно тяжелых систем, требующих тонкого тьюнига именно для конкретной специфической задачи (прикладной системы).

...

Рейтинг:

0 / 0

16.02.2010, 19:45

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36473521

vasilis

Участник

Откуда: Украина, Киев

Сообщения: 2 212

Рейтинг: 0 / 0

victor16...поскольку основные операции по изменению данных ведутся в 8K страницах (total dirty=1611), 2K страницы используются только для чтения (total dirty=81).
вывод достаточно спорный, т.к. кол-во грязных страниц в выводе onstat -P зависит от момента выполнения команды, а этот момент может быть очень разным, тем более, что и нагрузка в прикладной системе обычно неравномерная по многим параметрам.

...

Рейтинг:

0 / 0

16.02.2010, 19:51

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36473702

victor16

Гость

vasilisуменьшать буферный пул в данном случае и доводить bufwaits ratio до 2 или 5% и создавать будущие проблемы производительности
Василий, совершенно с Вами согласен, так я вроде и говорил, что надо стремиться к минимизации bufwaits.
vasilisкол-во грязных страниц в выводе onstat -P зависит от момента выполнения команды
И опять я соглашаюсь с Вами, нужно мониторить onstat -P, чтобы сделать вывод о целесообразности большого буферного пула.

С уважением,
Виктор

...

Рейтинг:

0 / 0

16.02.2010, 22:11

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36473774

victor16

Гость

Если уж речь зашла о команде onstat -P, то есть три вещи, на которые надо обратить внимание в выводе этой команды.
1) Первая строка (partnum 0), число в поле 'other' показывает количество неиспользуемых страниц в буферном пуле, оно должно быть значительно меньше, чем значения других полей. Сохраняющееся в течении длительного периода высокое значение в этом поле указывает на то, что можно уменьшить количество буферов без особого ущерба для производительности. Однако, чтобы быть полностью уверенным в своих выводах, это надо проверить в моменты пиковой нагрузки (я солидарен с Василием)
2) Totals в конце страницы. В "правильной" OLTP/DSS системе нормальным считается соотношение 60-80% data pages, 15-35% index (BTree) pages и малое значение "other". Естественно, что в DW-системах с небольшим количеством индексов это соотношение будет другим. Нужно иметь в виду, что для старых систем (7.3 и 9.2), если Btree выше 60%, это может свидетельствовать о наличии старого "buffer aging bug".
3) Каждая строка с указанием partnum. Эта информация может использоваться для вычисления часто используемых таблиц с целью их последующего фрагментирования для распределения нагрузки от параллельного сканирования. Также в этой строке можно вычислить таблицы небольшого размера, но очень часто используемые в течении рабочего дня, с целью сделать их резидентными, правда, для новых версий это уже неактуально, поскольку сервер сам решает вопрос о резидентности таблиц и индексов.

...

Рейтинг:

0 / 0

16.02.2010, 23:11

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36474829

vasilis

Участник

Откуда: Украина, Киев

Сообщения: 2 212

Рейтинг: 0 / 0

IDS Admin
vasilis ранее уже любезно советовал изменить размер физ. журнала. Уменьшали до 2ГБ, жили пару дней, изменений не заметили и вернули назад, т.к. вроде бы "хлеба не просит". Хотя, очень даже вероятно, не там смотрели результат изменения размера физ. журнала.
А результат , если и был, то чисто умозрительный и померить его тяжело (если вообще возможно). Я ведь исходил из общей теории что "обслуживать такой (большой) файл и искать там нужную точку тоже нужно время", а также из старого опыта "В моей жизни 1-2Гб хватало даже в самых нагруженных системах, но на истину не претендую".
По тому же принципу можно создавать все пространства "с запасом" (что часто и делают, если есть возможность, дабы в будущем иметь меньше хлопот), а можно "по необходимости", особенно при ограниченных ресурсах или желании всем управлять.
IDS Admin
В любом случае, его можно менять при включенной БД
А с какой версии это можно ?

...

Рейтинг:

0 / 0

17.02.2010, 13:16

| Ответить | Цитировать | Написать

Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

#36474894

vasilis

Участник

Откуда: Украина, Киев

Сообщения: 2 212

Рейтинг: 0 / 0

victor16vasilisуменьшать буферный пул в данном случае и доводить bufwaits ratio до 2 или 5% и создавать будущие проблемы производительности
Василий, совершенно с Вами согласен, так я вроде и говорил, что надо стремиться к минимизации bufwaits.
Ну, Вы еще несколько раз говорили, что при "bufwaits ratio<2%, однозначно надо уменьшать буферный пул", а уменьшение буферного пула уж никак не будет способствовать минимизации bufwaits. Именно против этого Вашего вывода я и возражал, намекая, что системы разные и далеко не всегда это нужно.
И я рад, что мы вместе (и надеюсь, наши читатели :) пришли к пониманию.

...

Рейтинг:

0 / 0

17.02.2010, 13:31

| Ответить | Цитировать | Написать

25 сообщений из 27, страница 1 из 2

все

Форумы / Informix [игнор отключен] [закрыт для гостей] / Блокировка IDS 11.5 при выполнении КТ с асинхронной HDR.

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=44&fpage=24&tid=1607621]:	0ms
get settings:	9ms
get forum list:	12ms
check forum access:	4ms
check topic access:	4ms
track hit:	38ms
get topic data:	12ms
get forum data:	2ms
get page messages:	315ms
get tp. blocked users:	2ms
others:	361ms

total:	759ms