Во время бэкапа db2 v 9.7 fp 4 на красной шапочке процесс db2sysc периодически грузит проц на 100 и более процентов в результате чего бэкап может выполниться то за 10 минут (если загрузка проца 6-10%) то за 10 часов (если 90 и более %)

при более тщательном просмотре db2pd -edu находим кто именно убийца:

EDU ID TID Kernel TID EDU Name USR (s) SYS (s)
========================================================================================================================================
113 46953727519040 19242 db2agent (idle) 0.020000 0.000000
112 46953731713344 19233 db2agent (idle) 0.060000 0.000000
111 46953735907648 19219 db2med.20.0 (STRAH) 0.000000 4832.720000
110 46953740101952 19218 db2bm.20.0 (STRAH) 1.290000 0.030000
109 46953744296256 19217 db2bm.20.2 (STRAH) 0.650000 0.010000
108 46953748490560 19216 db2bm.20.3 (STRAH) 0.210000 0.030000
107 46953752684864 19215 db2bm.20.1 (STRAH) 0.680000 0.000000
106 46953756879168 19214 db2pfchr (STRAH) 0.060000 11.010000
105 46953761073472 19213 db2pfchr (STRAH) 0.040000 12.350000
104 46953765267776 19212 db2pfchr (STRAH) 0.060000 26.540000
103 46953769462080 19211 db2pfchr (STRAH) 0.070000 74.690000
102 46953773656384 19210 db2pfchr (STRAH) 0.070000 116.790000
101 46953777850688 19209 db2pfchr (STRAH) 0.090000 113.330000
100 46953782044992 19208 db2pfchr (STRAH) 0.080000 342.220000
99 46953786239296 19207 db2pclnr (STRAH) 0.000000 0.000000
98 46953790433600 19206 db2pclnr (STRAH) 0.000000 0.000000
97 46953794627904 19205 db2pclnr (STRAH) 0.000000 0.000000
96 46953798822208 19204 db2pclnr (STRAH) 0.000000 0.000000
95 46953803016512 19203 db2pclnr (STRAH) 0.000000 0.000000
94 46953807210816 19202 db2pclnr (STRAH) 0.000000 0.000000
93 46953811405120 19201 db2pclnr (STRAH) 0.000000 0.000000
92 46953815599424 19200 db2pclnr (STRAH) 0.000000 0.000000
91 46953819793728 19199 db2pclnr (STRAH) 0.000000 0.000000
90 46953823988032 19198 db2pclnr (STRAH) 0.000000 0.000000
89 46953828182336 19197 db2pclnr (STRAH) 0.000000 0.000000
88 46953832376640 19196 db2pclnr (STRAH) 0.000000 0.000000
87 46953836570944 19195 db2pclnr (STRAH) 0.000000 0.000000
86 46953840765248 19194 db2pclnr (STRAH) 0.000000 0.000000
85 46953844959552 19193 db2pclnr (STRAH) 0.000000 0.000000
84 46953849153856 19192 db2pclnr (STRAH) 0.000000 0.000000
83 46953853348160 19191 db2pclnr (STRAH) 0.000000 0.000000


Им оказываются двое: db2med (собственно процесс бэкапа ввода-вывода) и префетчер db2pfchr (который вообще непонятно при чем здесь). Долгие нудные поиски в инете показали, что подобное иногда происходило у некоторых начиная с DB аж 7 версии и ничего не помогало за исключением фикспака версии эдак 9-10 не ниже. В данном случае придётся видимо ждать пока и в этой версии дибишки выйдет соответствующий фикспак. Не уже ли голубые гиганты снова и снова наступают на одни и те же грабли? Странно это всё.

db2 backup database STRAH to /backup with 6 buffers buffer 4096 parallelism 4 without prompting

с этими параметрами добился более-менее нормальной производительности. при чем увеличил NUM_IOCLEANERS до 75
а NUM_IOSERVERS до 6

да, что еще характерно, теже параметры на таком же сервере но с FP 3a не дали такого прироста, так что дырка по памяти именно от голубых гигантов. имхо.

Mark BarinsteinУбийц надо искать так, собирая статистику за определённые интервал времени (например, 30 сек.):
db2pd -edus interval=30


Неделю бодался с этой статистикой. Убийцы именно эти два процесса. При чем если еще db2med как-то понятно зачем тут, то db2pfchr вообще не ясно каким боком. В случаях описанных в инете он вис, как я понял, во время запросов, но что бы при бэкапе...

Mark Barinstein
1) Вы архивируете в 1 путь с 6-ю буферами? И что, производительность такой команды заметно лучше, чем просто
db2 backup database STRAH to /backup without prompting
?

2) NUM_IOCLEANERS не влияет на backup. Зачем вы сделали такое огромное кол-во их, из каких соображений?
Что, если ставить NUM_IOCLEANERS в AUTOMATIC, они не справляются со своей работой?

3) io_server и prefetcher (нить db2pfchr) - это одно и то же.
Они используются при backup.
NUM_IOSERVERS можно оставить в automatic (так лучше),

1) да, заметно выше.

2) это я сделал наткнувшись где-то в инете на такой совет в том случает если prefetcher уходит в 100% попробовать увеличить число чистильщиков.

3) думаю да, это не сильно повлияло на производительность. Повлияли именно параметры в пункте 1.

Да и еще, я соврал когда сказал, что параметры двух серверов одинаковы, на последнем еще менялись по мануалу параметры ядра, но их изменение мало что дало, а вот вкупе с изменением параметров в строке бэкапа всё же дало возможность худо-бедно но выйти из положения.

Самая засада в том, что это всё непредсказуемо. Даже после перезагрузки сервера бэкап может пройти в одном случае из где-то пяти нормально (10-15 минут) , а в остальных CPU 100-120 % . При этом перед бэкапом останавливаю WAS и делаю
db2stop force
ipclean
db2start

то есть всё чисто, но увы.

Mark BarinsteinПопробуйте явно задавать parallelism 1

Если не поможет, открывайте PMR.

parallelism 1 и стоял по умолчанию. Я так думаю, что именно его увеличение и помогло.

Сейчас на втором серваке поставил такие же параметры ядра как и на этом и запустил бэкап - увы медленно. теперь между ними отличие только в FP, вывод напрашивается сам собой.

Прошу прощения, что означает PMR? (если что-то линуховое, то увы в этой системе я чайник, под форточками не имел проблем с дибишкой таких никогда.)

Mark BarinsteinТолько я не понял, увеличение parallelism помогло в чём?
Процессор начал меньше использоваться?


Стал прыгать. То 100% (преимущественно), то 40% . В итоге бэкап проходит не за 8-10 часов, а за 2-3.

Спасибо за разъяснение PMR )