Unanswered: DB2VEND / db2logmgr Consuming lots of memory
I am running on both AIX and Linux, with DB2 V9.7 Fixpak 8. Logs are achiving to TSM. I noticed a high amount of memory being used on my hosts with a large chunk of the memory being used by db2vend, specifically:
Then when I look at the underlying pid for db2vend:
ps -ef | grep -i 27983932
27983932 28311720 0 Jan 29 - 1:04 db2vend (db2logmgr.meth1 - 4014 (MNB))
It seems strange that the db2logmgr is using almost as much memory as my database/instance. Has anyone else seen this issue? Any ideas on how to limit the amount of memory the db2logmgr is using? I can see it is slowing increasing the amount of memory it using almost like there is a memory leak. I am not receiving any errors, just lots of people questioning why this is using so much memory.
I see the same. If you do svmon -P for db2vend, you will see that most of the segments are shared memory (shmat/mmap). This means db2vend is not really consuming memory, just attaches to db memory set.
db2inst1 10158142 5439560 0 Nov 19 - 0:02 db2vend (db2logmgr.meth1 - 2829 (xxxxxxx))
> svmon -P 10158142 | grep -i 'shmat/mmap'
83854e 7000000d work default shmat/mmap m 4096 0 0 4096
850574 7000000e work default shmat/mmap m 4096 0 0 4096
820568 7000000f work default shmat/mmap m 4096 0 0 4096
840570 70000004 work default shmat/mmap m 3666 0 2672 4096
800560 70000005 work default shmat/mmap m 3176 0 2967 4096
804201 7000000c work default shmat/mmap m 2254 0 1842 4096
81c587 70000006 work default shmat/mmap m 2047 0 3570 4096
850594 70000010 work default shmat/mmap m 1613 0 0 1613
85c577 70000007 work default shmat/mmap m 1129 0 2967 4096
818506 77000000 work default shmat/mmap sm 1541 0 0 1541
83050c 7000000b work default shmat/mmap m 0 0 4096 4096
87459d 70000011 work default shmat/mmap m 0 0 0 0
818566 70000012 work default shmat/mmap m 0 0 0 0
84c393 70000009 work default shmat/mmap m 0 0 4096 4096
844571 7000000a work default shmat/mmap m 0 0 4096 4096
81c567 70000008 work default shmat/mmap m 0 0 4096 4096
86c57b 70000013 work default shmat/mmap m 0 0 0 0
> svmon -P 10158142 | grep -i 'process private'
8044a1 f00000002 work process private m 5 3 0 5
we have the same problem with db2 v10.1 and also when using db2adutl retrieve .. we get db2 killed by oom process (redhat ticket has been opened and noy corrected yet, but they suggested a kernel upgrade)
Best Regards, Guy Przytula
Database Software Consultant
Good DBAs are not formed in a week or a month. They are created little by little, day by day. Protracted and patient effort is needed to develop good DBAs.
Spoon feeding : To treat (another) in a way that discourages independent thought or action, as by overindulgence.
DB2 UDB LUW Certified V7-V8-V9-V9.7-V10.1-V10.5 DB Admin - Advanced DBA -Dprop..
Information Server Datastage Certified http://www.infocura.be
Sounds like you have a different issue. I heard back from IBM and they confirmed what dbgirl had posted:
"in general all of the db2 processes in the database will be using the same set of
shared memory segments and so the memory sets should only really exist
once. Then the db2vend processes that consumed a lot memory you described really were not using much memory overall, but in reality, it just attached to memory segments that are used by that db2 process db2sysc."