Внезапно ( ну конечно, внезапно, иначе не бывает) стала сильно тормозить DB2. Медленный коннект, медленные выборки и апдейты, но "в принципе" всё работает, но с абсолютно неприемлемой скоростью. Пришлось перезапускать, после перезапуска в db2diag.log нашёл следующие записи:
Непосредственно перед замедлением

FUNCTION: DB2 UDB, SQO Memory Management, sqloMemLogPoolConditions, probe:20
DATA #1 : <preformatted>
Reserved heap size exceeded for Database Heap (DBHEAP) on node 0,
allocating additional unreserved memory.
Requested block size : 707808 bytes.
Physical heap size : 60162048 bytes.
Configured heap size : 59572224 bytes.
Unreserved memory used by heap : 589824 bytes.
Unreserved memory left in set : 6402015232 bytes.

После перезапуска
FUNCTION: DB2 UDB, Self tuning memory manager, stmmCalcAutoScaleFactor, probe:100
MESSAGE : Current DB configuration exceeds free physical memory. Self-tuning
memory manager scaling back automatic memory consumers.
DATA #1 : unsigned integer, 8 bytes
69477203968
DATA #2 : unsigned integer, 8 bytes
2743992320
DATA #3 : unsigned integer, 8 bytes
63349653504
DATA #4 : unsigned integer, 8 bytes
60945338368
DATA #5 : unsigned integer, 8 bytes
56822251520
DATA #6 : unsigned integer, 8 bytes
646514312
DATA #7 : unsigned integer, 8 bytes
60298824056
DATA #8 : Decimal, 8 bytes
0.862461588685

Такие записи наводят на мысль, что DB2 (v9.5.7 на Linux) вместо физической памяти почему-то залезла в своп.
Вопрос: Это действительно так и почему? Как этого избежать в дальнейшем?
Вот здесь http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.qb.server.doc/doc/t0008238.html описаны рекомендованные минимальные параметры ядра, есть ли какие-то ограничения на максимальные значения?

Конфигурация DB2 сама использует параметр AUTOMATIC везде, где только можно.

ARIST_A,

Автоконфигуратор не натравливали, буферпул вырос за пару дней до события, когда по ошибке запустили SELECT со сканированием большой таблицы (обычно поиск по индексам только)

Mark Barinstein,

Линукс RHEL 5.6

Мы, к сожалению, храним логи db2diag только за пару последних дней, так что на момент последнего перед событием запуска такого лога давно нет. Фрагмент db2diag утром перед сбоем:

2011-06-29-01.25.58.113261+240 I1E1629 LEVEL: Event
PID : 12454 TID : 47712510667072PROC : db2sysc 0
INSTANCE: db2pf0 NODE : 000
EDUID : 30 EDUNAME: db2logmgr (CPROSD22) 0
FUNCTION: DB2 UDB, RAS/PD component, pdLogInternal, probe:120
START : New Diagnostic Log file
DATA #1 : Build Level, 152 bytes
Instance "db2pf0" uses "64" bits and DB2 code release "SQL09057"
with level identifier "06080107".
Informational tokens are "DB2 v9.5.0.7", "s101129", "IP23143", Fix Pack "7".
DATA #2 : System Info, 440 bytes
System: Linux pd-l11.nbch.msk 6 2 x86_64
CPU: total:12 online:12 Cores per socket:16 Threading degree per core:1
Physical Memory(MB): total:60415 free:161
Virtual Memory(MB): total:134847 free:61176
Swap Memory(MB): total:74432 free:61015
Kernel Params: msgMaxMessageSize:65536 msgMsgMap:2097152 msgMaxQueueIDs:69632
msgNumberOfHeaders:2097152 msgMaxQueueSize:2097152
msgMaxSegmentSize:16 shmMax:63349653504 shmMin:1 shmIDs:17408
shmSegments:17408 semMap:256000 semIDs:17408 semNum:256000
semUndo:256000 semNumPerID:250 semOps:32 semUndoSize:20
semMaxVal:32767 semAdjustOnExit:32767
Cur cpu time limit (seconds) = 0xFFFFFFFF
Cur file size limit (bytes) = 0xFFFFFFFF
Cur data size (bytes) = 0xFFFFFFFF
Cur stack size (bytes) = 0x00A00000
Cur core size (bytes) = 0x00000000
Cur memory size (bytes) = 0xFFFFFFFF
nofiles (descriptors) = 0x0000FFFE

Information in this record is only valid at the time when this file was
created (see this record's time stamp)

После рестарта DB2 вчера мы сделали, наверно не очень хорошую вещь. Поменяли /etc/sysctl.conf и выполнили sysctl -p :

kernel.shmmni = было 17408 стало 14800
kernel.sem= было 250 256000 32 17408 стало 250 256000 32 14800

На данный момент вывод команд такой:

db2pd -osinfo

Operating System Information:

OSName: Linux
NodeName: pd-l11.nbch.msk
Version: 2
Release: 6
Machine: x86_64

CPU Information:
TotalCPU OnlineCPU ConfigCPU Speed(MHz) HMTDegree Cores/Socket
12 12 12 2799 1 16

Physical Memory and Swap (Megabytes):
TotalMem FreeMem AvailMem TotalSwap FreeSwap
60415 157 n/a 74432 66259

Virtual Memory (Megabytes):
Total Reserved Available Free
134847 n/a n/a 66416

Message Queue Information:
MsgSeg MsgMax MsgMap MsgMni MsgTql MsgMnb MsgSsz
n/a 65536 2097152 69632 2097152 2097152 16

Shared Memory Information:
ShmMax ShmMin ShmIds ShmSeg
59055800320 1 14800 14800

Semaphore Information:
SemMap SemMni SemMns SemMnu SemMsl SemOpm SemUme SemUsz SemVmx SemAem
256000 14800 256000 256000 250 32 n/a 20 32767 32767

CPU Load Information:
Short Medium Long
4.380000 4.330000 4.220000

CPU Usage Information (percent):
Total Usr Sys Wait Idle
36.500000 n/a n/a n/a 63.500000

ipcs -l

------ Shared Memory Limits --------
max number of segments = 14800
max seg size (kbytes) = 57671680
max total shared memory (kbytes) = 115343360
min seg size (bytes) = 1

------ Semaphore Limits --------
max number of arrays = 14800
max semaphores per array = 250
max semaphores system wide = 256000
max ops per semop call = 32
semaphore max value = 32767

------ Messages: Limits --------
max queues system wide = 69632
max size of message (bytes) = 65536
default max size of queue (bytes) = 2097152

Mark Barinstein,

я тоже думаю теперь отказаться от AUTOMATIC для INSTANCE MEMORY, но это только workaround, а причина , видимо, всё же - баг в DB2. Открыл PMR, подожду, что скажет официальная поддержка.

Судя по этой записи:
*** stmmCostBenefitRecord ***
Type: DATABASE_MEMORY
PageSize: 4096
Original Size: 15107600
Desired New Size: 15749503
Actual New Size: 15749503
Potential Increase Amount: 0
Potential Decrease Amount: 0

размер database memory стал 15749503 pages*4096= 64509964288 при физической памяти 63349653504

По буферпулам сказать точно не могу, не понимаю, куда именно в логах глядеть. В db2diag последняя запись - про увеличение DBHEAP.

Если кому интересно, вот цитаты из ответов службы поддержки:

"Она [DB2] просто обращается в память и если ее не хватает то для этого и есть виртуальная т.е. часть памяти свопится на диск что конечно же сильно замедляет работу. Это как раз и происходит в случае когда INSTANCE_MEMORY = AUTOMATIC потому что в этом случае дб2 сама в себе никак не ограничена поскольку ей было тем самым сказано- памяти в системе полно- если надо бери больше."

Меня поразила такая интерпретация режима AUTOMATIC , когда оптимизатор ничем не ограничен и может "by design" брать больше и залезать в виртуальную память

Вот еще цитата (речь идет о буферпулах):

"Если High water mark больше , чем Configured size это говорит о том что произошло переполнение. Configured size это максимальное значение на начальный момент:

The AUTOMATIC keyword is also supported on the UPDATE DB CFG command. In the following example, database_memory will be updated to AUTOMATIC and the database manager will use 20000 as a starting value when making further changes to this parameter:
db2 update db cfg using for sample using database_memory 20000 automatic"

Странная логика у специалиста поддержки: при конфигурации буферпула я задал некоторое НАЧАЛЬНОЕ значение для размера буферпула, оптимизатор его увеличил, а специалист из поддержки говорит о переполнении буферпула. Странно это..... Ну да ладно.

Общее резюме от служьы поддержки:

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

В нашей системе память не так давно была увеличена с 9 ГБ (и работало неплохо, но без stmm) до 60 ГБ. Получается, что оптимизатору мало 60 ГБ там, где реально и 9 ГБ достаточно. Ну и оптимизатор - зачем он такой нужен???? Если следовать совету службы поддержки, придется, видимо, фиксировать память инстанса, самой БД и буферпулов.

Mark Barinstein,

Хотелось бы услышать Ваше мнение - выключать автоматическую память полностью или всё же только на уровне инстанса? БД там одна, буферпулов несколько. Спасибо!

Спасибо, Марк! Вряд ли мне удастся добиться большего от поддержки, тем более что "У нас уже много было таких случаев и мы уже вынесли решение подобной проблемы". С такой позиции их трудно сдвинуть. Так что пока зафиксирую instance memory, а там посмотрим.

Ну вот проблема повторилась, но диагностика немного другая:

Current DB configuration exceeds free INSTANCE_MEMORY. Self-tuning
memory manager scaling back automatic memory consumers.

Ну вот как это??? настраивался, настраивался DB2 и настроился так, что после перезапуска Current DB configuration exceeds free INSTANCE_MEMORY.

Впрочем, скорее всего на сей раз дело в другом. Перед сбоем STMM ничего не менял, но при этом резко вырос объем используемого линуксового свопа. Сейчас открою новую тему

Марк,

меня отвлекли вчера, новую тему не открыл, а Вы уже ответили по существу этой неоткрытой еще темы:-). Я тоже думал про свопинг и как с ним бороться. Непосредственным поводом для возникновения проблемы послужил большой пакетный update на десятки миллионов записей ( с помощью Вашей, Марк, процедуры с промежуточными commit-ами:-) Commit-ы отработали, блокировки ничему не мешали и отработалось больше 2/3 записей, как возник свопинг.
По поводу Ваших рекомендаций:
1. У нас для всех пространств установлено NO FILE SYSTEM CACHING , за исключением временных. Имеет ли смысл, безопасно ли ставить NO FILE SYSTEM CACHING для TEMPSPACE1 (SMS) ?
2. На сервере, кроме DB2, запущены еще приложения, которые собственно с базой и работают, да еще и новеловский LDAP (eDirectory). Я вот думаю, не повлияет ли параметр swappiness на их работу?

Mark Barinstein,

Спасибо большое! Ну вот почему официальная поддержка IBM не подсказала про параметр DB2_MEM_TUNING_RANGE, когда я обратился к ним по проблеме , описанной изначально в этом топике? Наоборот, они меня пытались убедить, что DB2 не различает физическую и виртуальную память, правда, не убедили. Попробую установить swappiness и поиграться с этим параметром.

Между тем, еще одна непонятка:

Смотрю dbm cfg:
INSTANCE_MEMORY = 13830000 (55320000 КБ)

db2mtrk:
Total: 21757952 bytes (instance - 21248 КБ)
Total: 42441310208 bytes (database - 41446592 КБ)


А линукс между тем (команда ps) показывает для процесса db2sysc 57227867 КБ общей памяти, в т ч 45838132 КБ физической.

Непонятно, зачем DB2 нужно около 12 ГБ виртуальной памяти? И какую всё-таки память определяет INSTANCE_MEMORY - физическую или общую? И как вообще соотнести все эти цифры между собой?