By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,756 Members | 1,745 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,756 IT Pros & Developers. It's quick & easy.

db2sysc consumes huge memory

P: n/a
Hi expert,

I installed DB2 v8.2 server on Solaris 9 box. When I connect to DB2
using control centre or other applications(except command line),
around 12 db2sysc processes pop up and each one consumes more than 2G
memory(total 30G memory). The server only has 8G physical memory, so
DB2 costs too many memory resources. I tried to reduce the
appgroup_mem_sz and app_ctl_heap_sz, but it didn't work. What else can
I do?

Please help!

Feb 16 '07 #1
Share this Question
Share on Google+
12 Replies


P: n/a
Tony wrote:
Hi expert,

I installed DB2 v8.2 server on Solaris 9 box. When I connect to DB2
using control centre or other applications(except command line),
around 12 db2sysc processes pop up and each one consumes more than 2G
memory(total 30G memory). The server only has 8G physical memory, so
DB2 costs too many memory resources. I tried to reduce the
appgroup_mem_sz and app_ctl_heap_sz, but it didn't work. What else can
I do?

Please help!
Please be sure that they really are chewing up that type of memory. If
you're using top and see that each process is using 2G of memory, much of
that may actually be shared between the processes. Much of it may be
virtual memory (allocated, but not actually used yet).

Is your swap really being used for 22+G of disk space? If that were true,
your system would probably grind to a halt trying to allocate the
diskspace, swapping each db2sysc process in and out of physical RAM.

My guess is that you're looking at top's output and reading its memory
status as if each process were completely independant. Due to the nature
of fork(2), they aren't. Each process shares lots of memory in
copy-on-write memory pages, plus there is actual shared (read-write) memory
on top of that (using something like shmget(2)). So the numbers top shows
can be quite misleading. And yet, I couldn't imagine a way they could make
it accurate and obvious (not misleading to those who don't know unix
internals).
Feb 16 '07 #2

P: n/a
On Feb 15, 10:24 pm, Darin McBride
<dmcbr...@tower.to.org.no.spam.for.mewrote:
Tony wrote:
Hi expert,
I installed DB2 v8.2 server on Solaris 9 box. When I connect to DB2
using control centre or other applications(except command line),
around 12 db2sysc processes pop up and each one consumes more than 2G
memory(total 30G memory). The server only has 8G physical memory, so
DB2 costs too many memory resources. I tried to reduce the
appgroup_mem_sz and app_ctl_heap_sz, but it didn't work. What else can
I do?
Please help!

Please be sure that they really are chewing up that type of memory. If
you're using top and see that each process is using 2G of memory, much of
that may actually be shared between the processes. Much of it may be
virtual memory (allocated, but not actually used yet).

Is your swap really being used for 22+G of disk space? If that were true,
your system would probably grind to a halt trying to allocate the
diskspace, swapping each db2sysc process in and out of physical RAM.

My guess is that you're looking at top's output and reading its memory
status as if each process were completely independant. Due to the nature
of fork(2), they aren't. Each process shares lots of memory in
copy-on-write memory pages, plus there is actual shared (read-write) memory
on top of that (using something like shmget(2)). So the numbers top shows
can be quite misleading. And yet, I couldn't imagine a way they could make
it accurate and obvious (not misleading to those who don't know unix
internals).
On Solaris, I'm using "prstat -a -s rss" to check the process's memory
consumption(not AIX "top"). Do you have any other good ideas to check
real memory consumption?

Thanks a lot.

Feb 16 '07 #3

P: n/a
On Feb 15, 8:15 pm, "Tony" <tonyedr...@gmail.comwrote:
Hi expert,

I installed DB2 v8.2 server on Solaris 9 box. When I connect to DB2
using control centre or other applications(except command line),
around 12 db2sysc processes pop up and each one consumes more than 2G
memory(total 30G memory). The server only has 8G physical memory, so
DB2 costs too many memory resources. I tried to reduce the
appgroup_mem_sz and app_ctl_heap_sz, but it didn't work. What else can
I do?

Please help!
What fixpack are you using? Please type db2level command.

Unless there is a serious bug (most likely resolved in a fixpack
already available) you are probably mistaken about the amount of
memory actaully being used.

Feb 16 '07 #4

P: n/a
On Feb 16, 1:43 am, "Mark A" <m00...@yahoo.comwrote:
On Feb 15, 8:15 pm, "Tony" <tonyedr...@gmail.comwrote:
Hi expert,
I installed DB2 v8.2 server on Solaris 9 box. When I connect to DB2
using control centre or other applications(except command line),
around 12 db2sysc processes pop up and each one consumes more than 2G
memory(total 30G memory). The server only has 8G physical memory, so
DB2 costs too many memory resources. I tried to reduce the
appgroup_mem_sz and app_ctl_heap_sz, but it didn't work. What else can
I do?
Please help!

What fixpack are you using? Please type db2level command.

Unless there is a serious bug (most likely resolved in a fixpack
already available) you are probably mistaken about the amount of
memory actaully being used.
Hi Mark,

I installed the newest fixpack which is fixpack 14. The output of
"prstat -a -s rss" command is:

PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/
NLWP
9762 db2inst8 2384M 2252M sleep 59 0 0:00:01 1.2% db2sysc/1
8933 db2inst8 2317M 2222M sleep 59 0 0:00:18 9.3% db2sysc/1
9752 db2inst8 2316M 2214M sleep 59 0 0:00:00 0.0% db2sysc/1
9760 db2inst8 2316M 2213M sleep 59 0 0:00:00 0.0% db2sysc/1
9757 db2inst8 2316M 2213M sleep 59 0 0:00:00 0.0% db2sysc/1
9758 db2inst8 2316M 2213M sleep 59 0 0:00:00 0.0% db2sysc/1
9759 db2inst8 2316M 2213M sleep 59 0 0:00:00 0.0% db2sysc/1
9756 db2inst8 2316M 2213M sleep 59 0 0:00:00 0.0% db2sysc/1
9753 db2inst8 2316M 2213M sleep 59 0 0:00:00 0.0% db2sysc/1
9761 db2inst8 2316M 2213M sleep 59 0 0:00:00 0.0% db2sysc/1
9755 db2inst8 2316M 2212M sleep 59 0 0:00:00 0.0% db2sysc/1
9754 db2inst8 2316M 2212M sleep 59 0 0:00:00 0.0% db2sysc/1

NPROC USERNAME SIZE RSS MEMORY TIME
CPU
27 db2inst8 29G 26G 87% 0:00:20 11%

Thanks.

Feb 16 '07 #5

P: n/a
On Feb 16, 7:36 am, "Tony" <tonyedr...@gmail.comwrote:
Hi Mark,

I installed the newest fixpack which is fixpack 14. The output of
"prstat -a -s rss" command is:

PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/
NLWP
9762 db2inst8 2384M 2252M sleep 59 0 0:00:01 1.2% db2sysc/1
8933 db2inst8 2317M 2222M sleep 59 0 0:00:18 9.3% db2sysc/1
9752 db2inst8 2316M 2214M sleep 59 0 0:00:00 0.0% db2sysc/1
9760 db2inst8 2316M 2213M sleep 59 0 0:00:00 0.0% db2sysc/1
9757 db2inst8 2316M 2213M sleep 59 0 0:00:00 0.0% db2sysc/1
9758 db2inst8 2316M 2213M sleep 59 0 0:00:00 0.0% db2sysc/1
9759 db2inst8 2316M 2213M sleep 59 0 0:00:00 0.0% db2sysc/1
9756 db2inst8 2316M 2213M sleep 59 0 0:00:00 0.0% db2sysc/1
9753 db2inst8 2316M 2213M sleep 59 0 0:00:00 0.0% db2sysc/1
9761 db2inst8 2316M 2213M sleep 59 0 0:00:00 0.0% db2sysc/1
9755 db2inst8 2316M 2212M sleep 59 0 0:00:00 0.0% db2sysc/1
9754 db2inst8 2316M 2212M sleep 59 0 0:00:00 0.0% db2sysc/1

NPROC USERNAME SIZE RSS MEMORY TIME
CPU
27 db2inst8 29G 26G 87% 0:00:20 11%

Thanks.- Hide quoted text -

- Show quoted text -
Are you using partitioning (DPF)?

Feb 16 '07 #6

P: n/a
On Feb 16, 9:59 am, "Mark A" <m00...@yahoo.comwrote:
On Feb 16, 7:36 am, "Tony" <tonyedr...@gmail.comwrote:


Hi Mark,
I installed the newest fixpack which is fixpack 14. The output of
"prstat -a -s rss" command is:
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/
NLWP
9762 db2inst8 2384M 2252M sleep 59 0 0:00:01 1.2% db2sysc/1
8933 db2inst8 2317M 2222M sleep 59 0 0:00:18 9.3% db2sysc/1
9752 db2inst8 2316M 2214M sleep 59 0 0:00:00 0.0% db2sysc/1
9760 db2inst8 2316M 2213M sleep 59 0 0:00:00 0.0% db2sysc/1
9757 db2inst8 2316M 2213M sleep 59 0 0:00:00 0.0% db2sysc/1
9758 db2inst8 2316M 2213M sleep 59 0 0:00:00 0.0% db2sysc/1
9759 db2inst8 2316M 2213M sleep 59 0 0:00:00 0.0% db2sysc/1
9756 db2inst8 2316M 2213M sleep 59 0 0:00:00 0.0% db2sysc/1
9753 db2inst8 2316M 2213M sleep 59 0 0:00:00 0.0% db2sysc/1
9761 db2inst8 2316M 2213M sleep 59 0 0:00:00 0.0% db2sysc/1
9755 db2inst8 2316M 2212M sleep 59 0 0:00:00 0.0% db2sysc/1
9754 db2inst8 2316M 2212M sleep 59 0 0:00:00 0.0% db2sysc/1
NPROC USERNAME SIZE RSS MEMORY TIME
CPU
27 db2inst8 29G 26G 87% 0:00:20 11%
Thanks.- Hide quoted text -
- Show quoted text -

Are you using partitioning (DPF)?- Hide quoted text -

- Show quoted text -
No, it's only a single -partition system.

Feb 16 '07 #7

P: n/a
On Feb 16, 8:35 am, "Tony" <tonyedr...@gmail.comwrote:
>
No, it's only a single -partition system.- Hide quoted text -
I would first consult a Solaris expert to verify that DB2 is really
using that much memory, and then contact the DB2 Support Center if you
still think there is a problem.

Feb 16 '07 #8

P: n/a
Tony wrote:
On Feb 15, 10:24 pm, Darin McBride
<dmcbr...@tower.to.org.no.spam.for.mewrote:
>Tony wrote:
Hi expert,
I installed DB2 v8.2 server on Solaris 9 box. When I connect to DB2
using control centre or other applications(except command line),
around 12 db2sysc processes pop up and each one consumes more than 2G
memory(total 30G memory). The server only has 8G physical memory, so
DB2 costs too many memory resources. I tried to reduce the
appgroup_mem_sz and app_ctl_heap_sz, but it didn't work. What else can
I do?
Please help!

Please be sure that they really are chewing up that type of memory. If
you're using top and see that each process is using 2G of memory, much of
that may actually be shared between the processes. Much of it may be
virtual memory (allocated, but not actually used yet).

Is your swap really being used for 22+G of disk space? If that were
true, your system would probably grind to a halt trying to allocate the
diskspace, swapping each db2sysc process in and out of physical RAM.
[...]
>can be quite misleading. And yet, I couldn't imagine a way they could
make it accurate and obvious (not misleading to those who don't know unix
internals).

On Solaris, I'm using "prstat -a -s rss" to check the process's memory
consumption(not AIX "top"). Do you have any other good ideas to check
real memory consumption?
No, there is no good way to check real memory consumption. As I said above,
I can't imagine a way that the prstat/top/kernel developers could display
accurate real memory usage. We're talking about a tree here where some
memory is being mapped into multiple process spaces, with flags set such
that if any of the processes attempts to write to that memory, the kernel
gets an exception at which point it copies the memory to a new page and
then allows the write to continue. Since most of this 2G of memory that
db2sysc seems to be using will never be written to, that exception never
occurs, and you save on physical RAM.

Your best bet really is to be paying attention to swap usage and total RAM
allocation. If there is no swap usage, and total RAM allocation shows 4-5
GB free RAM, you can thus deduce that DB2 is only using 2-3G of RAM. If
total RAM free is over 6G, then DB2 is not only using less than 2G of RAM,
we can further deduce that some of the memory is still virtual, and not
committed by the kernel yet.
Feb 16 '07 #9

P: n/a
Ian
Darin McBride wrote:
No, there is no good way to check real memory consumption.
From Solaris, that's true. And of course you know this Darin, but
Tony can use the db2mtrk command to show how much memory has actually
been allocated. Of course, this requires trusting the tool, but we
don't have much choice (and no reason to believe it isn't accurate).


Feb 16 '07 #10

P: n/a
On Feb 16, 4:46 pm, Ian <ianb...@mobileaudio.comwrote:
Darin McBride wrote:
No, there is no good way to check real memory consumption.

From Solaris, that's true. And of course you know this Darin, but
Tony can use the db2mtrk command to show how much memory has actually
been allocated. Of course, this requires trusting the tool, but we
don't have much choice (and no reason to believe it isn't accurate).
Yeah Ian, for a DBA like me, I'd like to trust the db2mtrk command,
but for our SA, he only believes his solaris command, you know...

Feb 19 '07 #11

P: n/a
Ian
Tony wrote:
>
Yeah Ian, for a DBA like me, I'd like to trust the db2mtrk command,
but for our SA, he only believes his solaris command, you know...
Well, any Solaris sys admin worth his salt should understand the concept
of shared memory and how the OS doesn't report this accurately. I mean,
it's not like this is anything new or unique to DB2.


Feb 26 '07 #12

P: n/a
On 26 Feb, 07:01, Ian <ianb...@mobileaudio.comwrote:
Tony wrote:
Yeah Ian, for a DBA like me, I'd like to trust the db2mtrk command,
but for our SA, he only believes his solaris command, you know...

Well, any Solaris sys admin worth his salt should understand the concept
of shared memory and how the OS doesn't report this accurately. I mean,
it's not like this is anything new or unique to DB2.
Typically DB2 admin, does not understand the OS layer properly.
Solaris does report this accurately via the pmap -x command.
You just need to collate the results yourself..

Feb 26 '07 #13

This discussion thread is closed

Replies have been disabled for this discussion.