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

Explanation/help with DB2 memory Usage on Linux?

P: n/a
Hi,

We have a Server running SLES 8 and 3GB memory, with 1 DB2 instance and
2 active Databases.

General info...
DB2level = "DB2 v8.1.0.72", "s040914", "MI00086", and FixPak "7"
uname -a = Linux galahad 2.4.19-64GB-SMP #1 SMP
/etc/sysctl.conf
kernel.shmmax=268435456
kernel.msgmni=1024
kernel.sem="250 32000 32 1024"
From my bufferpool allocations etc.. I reckon I should be using about

1GB of the 3GB available, but I am getting memory allocation errors

e.g from db2diag.log...
2005-01-26-16.10.15.117133+000 I173528014G494 LEVEL: Severe
PID : 4941 TID : 1024 PROC : db2agent
(JBSUKS23)
INSTANCE: db2jbsi1 NODE : 000 DB : JBSUKS23
APPHDL : 0-87 APPID: C0A86313.AC04.00A286161018
FUNCTION: DB2 UDB, base sys utilities, sqleSubsequentConnect, probe:70
RETCODE : ZRC=0x850F0005=-2062614523=SQLO_NOSEG
"No Storage Available for allocation"
DIA8305C Memory allocation failure occurred.

When I look at 'top' I see...
Mem: 3104908K av, 2988836K used, 116072K free, 0K shrd,
89496K buff
Swap: 1052248K av, 279436K used, 772812K free
2000040K cached

When I sum the vmdata of all /proc/nnn/status (idea found on another
forum) i.e grep -i vmdata /proc/$i/status | cut -f 2 ...
I get a total of
1,247,372 KB

When I look at ipcs, i.e ipcs -m , and sum the shared memory segments,
I get
821,274,526 Bytes

So all seems to indicate around 1GB which is what I expected, so why
memory allocation problems?
Any pointers/explanation would be great.

Thanks.

Paul.

Nov 12 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Getting this same error on 8.1FP7a using Windows2000, if its any help to
you. It only seems to occur when the system is under quite heavy stress,
dealing with more than 50 concurrent connections. The error is slightly
different, it mentions nothing about memory allocation failure. Perhaps
it might be an idea to increase your DBM heapsize, or the heap
allocation for that database.

Civilian_Target

PaulR wrote:
Hi,

We have a Server running SLES 8 and 3GB memory, with 1 DB2 instance and
2 active Databases.

General info...
DB2level = "DB2 v8.1.0.72", "s040914", "MI00086", and FixPak "7"
uname -a = Linux galahad 2.4.19-64GB-SMP #1 SMP
/etc/sysctl.conf
kernel.shmmax=268435456
kernel.msgmni=1024
kernel.sem="250 32000 32 1024"
From my bufferpool allocations etc.. I reckon I should be using about

1GB of the 3GB available, but I am getting memory allocation errors

e.g from db2diag.log...
2005-01-26-16.10.15.117133+000 I173528014G494 LEVEL: Severe
PID : 4941 TID : 1024 PROC : db2agent
(JBSUKS23)
INSTANCE: db2jbsi1 NODE : 000 DB : JBSUKS23
APPHDL : 0-87 APPID: C0A86313.AC04.00A286161018
FUNCTION: DB2 UDB, base sys utilities, sqleSubsequentConnect, probe:70
RETCODE : ZRC=0x850F0005=-2062614523=SQLO_NOSEG
"No Storage Available for allocation"
DIA8305C Memory allocation failure occurred.

When I look at 'top' I see...
Mem: 3104908K av, 2988836K used, 116072K free, 0K shrd,
89496K buff
Swap: 1052248K av, 279436K used, 772812K free
2000040K cached

When I sum the vmdata of all /proc/nnn/status (idea found on another
forum) i.e grep -i vmdata /proc/$i/status | cut -f 2 ...
I get a total of
1,247,372 KB

When I look at ipcs, i.e ipcs -m , and sum the shared memory segments,
I get
821,274,526 Bytes

So all seems to indicate around 1GB which is what I expected, so why
memory allocation problems?
Any pointers/explanation would be great.

Thanks.

Paul.

Nov 12 '05 #2

P: n/a
If memory serves, I think there's a limit of around 800MB for the total
size of a database shared memory.
I'd look at the db cfg parms that make this:buffer pools, lock list,
package cache, catalog cache and util_heap (if you are running
concurrent utilities.
The sumk of all these values must fit in 800MB per db. Over and above
that the applic. control heap must be allocated and room for each and
every dbagent that is running. All thuis must fit in the physical
memoey (I'm not mentionning all of them here...)
Turn on your health monitor and set the indicators that will track this
so they give you warnings before you get in to trobleHTH, Pierre.

Civilian_Target wrote:
Getting this same error on 8.1FP7a using Windows2000, if its any help to
you. It only seems to occur when the system is under quite heavy stress,
dealing with more than 50 concurrent connections. The error is slightly
different, it mentions nothing about memory allocation failure. Perhaps
it might be an idea to increase your DBM heapsize, or the heap
allocation for that database.

Civilian_Target

PaulR wrote:
Hi,

We have a Server running SLES 8 and 3GB memory, with 1 DB2 instance and
2 active Databases.

General info...
DB2level = "DB2 v8.1.0.72", "s040914", "MI00086", and FixPak "7"
uname -a = Linux galahad 2.4.19-64GB-SMP #1 SMP
/etc/sysctl.conf
kernel.shmmax=268435456
kernel.msgmni=1024
kernel.sem="250 32000 32 1024"
From my bufferpool allocations etc.. I reckon I should be using about


1GB of the 3GB available, but I am getting memory allocation errors

e.g from db2diag.log...
2005-01-26-16.10.15.117133+000 I173528014G494 LEVEL: Severe
PID : 4941 TID : 1024 PROC : db2agent
(JBSUKS23)
INSTANCE: db2jbsi1 NODE : 000 DB : JBSUKS23
APPHDL : 0-87 APPID: C0A86313.AC04.00A286161018
FUNCTION: DB2 UDB, base sys utilities, sqleSubsequentConnect, probe:70
RETCODE : ZRC=0x850F0005=-2062614523=SQLO_NOSEG
"No Storage Available for allocation"
DIA8305C Memory allocation failure occurred.

When I look at 'top' I see...
Mem: 3104908K av, 2988836K used, 116072K free, 0K shrd,
89496K buff
Swap: 1052248K av, 279436K used, 772812K free
2000040K cached

When I sum the vmdata of all /proc/nnn/status (idea found on another
forum) i.e grep -i vmdata /proc/$i/status | cut -f 2 ...
I get a total of
1,247,372 KB

When I look at ipcs, i.e ipcs -m , and sum the shared memory segments,
I get
821,274,526 Bytes

So all seems to indicate around 1GB which is what I expected, so why
memory allocation problems?
Any pointers/explanation would be great.
Thanks.

Paul.


--
Pierre Saint-Jacques - Reply to: sescons at attglobal dot net
IBM DB2 Cerified Solutions Expert - Administration
SES Consultants Inc.
Nov 12 '05 #3

P: n/a
Pierre Saint-Jacques wrote:
If memory serves, I think there's a limit of around 800MB for the total size of a database shared
memory. I'd look at the db cfg parms that make this:buffer pools, lock list, package cache,
catalog cache and util_heap (if you are running concurrent utilities. The sumk of all these
values must fit in 800MB per db. Over and above that the applic. control heap must be allocated
and room for each and every dbagent that is running. All thuis must fit in the physical memoey
(I'm not mentionning all of them here...) Turn on your health monitor and set the indicators that
will track this so they give you warnings before you get in to trobleHTH, Pierre.

Civilian_Target wrote:
Getting this same error on 8.1FP7a using Windows2000, if its any help to you. It only seems to
occur when the system is under quite heavy stress, dealing with more than 50 concurrent
connections. The error is slightly different, it mentions nothing about memory allocation
failure. Perhaps it might be an idea to increase your DBM heapsize, or the heap allocation for
that database.

Civilian_Target

PaulR wrote:
We have a Server running SLES 8 and 3GB memory, with 1 DB2 instance and 2 active Databases.

General info... DB2level = "DB2 v8.1.0.72", "s040914", "MI00086", and FixPak "7" uname -a =
Linux galahad 2.4.19-64GB-SMP #1 SMP /etc/sysctl.conf kernel.shmmax=268435456
kernel.msgmni=1024 kernel.sem="250 32000 32 1024"

From my bufferpool allocations etc.. I reckon I should be using about
1GB of the 3GB available, but I am getting memory allocation errors

e.g from db2diag.log... 2005-01-26-16.10.15.117133+000 I173528014G494 LEVEL: Severe PID
: 4941 TID : 1024 PROC : db2agent (JBSUKS23) INSTANCE: db2jbsi1
NODE : 000 DB : JBSUKS23 APPHDL : 0-87 APPID:
C0A86313.AC04.00A286161018 FUNCTION: DB2 UDB, base sys utilities, sqleSubsequentConnect,
probe:70 RETCODE : ZRC=0x850F0005=-2062614523=SQLO_NOSEG "No Storage Available for
allocation" DIA8305C Memory allocation failure occurred.

When I look at 'top' I see... Mem: 3104908K av, 2988836K used, 116072K free, 0K shrd,
89496K buff Swap: 1052248K av, 279436K used, 772812K free 2000040K cached

When I sum the vmdata of all /proc/nnn/status (idea found on another forum) i.e grep -i
vmdata /proc/$i/status | cut -f 2 ... I get a total of 1,247,372 KB

When I look at ipcs, i.e ipcs -m , and sum the shared memory segments, I get 821,274,526
Bytes

So all seems to indicate around 1GB which is what I expected, so why memory allocation
problems? Any pointers/explanation would be great. Thanks.

Paul.


One other aspect to consider is that some of the shared memory allocations need a contiguous region.
This can be hard to optimize when many different possible configurations must be accomodated.

If you are willing to move to FP8 code, there are now some additional parameters (DB2_MAPPED_BASE,
DB2DBMSADDR) that might be helpful. The following is from the ReleaseNotes, buried in the section
Documentation Updates : Administration : Performance (Linux)-

The DB2_MAPPED_BASE registry variable can be used to increase
the amount of contiguous virtual address space available to a
DB2 Universal Database (UDB) process by relocating the
attachment address of the shared libraries for the specific
process. The contiguous virtual address space is important to
maximize the amount of database shared memory available to DB2
UDB. This variable is only effective on distributions that
include the mapped_base file in the process identification
directory in the proc file system.

Note the fine-print caution:
"Use of these registry variables is only recommended for advanced users."

I hope to test this myself soon on a x346 dual Xeon system w/4GB and SLES9-1

CHeers,
Eric.Jones

Nov 12 '05 #4

P: n/a
Problem cured. The app I'm using was trying to open more connection
pools than the DB had to offer.

Civilian_Target

Civilian_Target wrote:
Getting this same error on 8.1FP7a using Windows2000, if its any help to
you. It only seems to occur when the system is under quite heavy stress,
dealing with more than 50 concurrent connections. The error is slightly
different, it mentions nothing about memory allocation failure. Perhaps
it might be an idea to increase your DBM heapsize, or the heap
allocation for that database.

Civilian_Target

PaulR wrote:
Hi,

We have a Server running SLES 8 and 3GB memory, with 1 DB2 instance and
2 active Databases.

General info...
DB2level = "DB2 v8.1.0.72", "s040914", "MI00086", and FixPak "7"
uname -a = Linux galahad 2.4.19-64GB-SMP #1 SMP
/etc/sysctl.conf
kernel.shmmax=268435456
kernel.msgmni=1024
kernel.sem="250 32000 32 1024"
From my bufferpool allocations etc.. I reckon I should be using about


1GB of the 3GB available, but I am getting memory allocation errors

e.g from db2diag.log...
2005-01-26-16.10.15.117133+000 I173528014G494 LEVEL: Severe
PID : 4941 TID : 1024 PROC : db2agent
(JBSUKS23)
INSTANCE: db2jbsi1 NODE : 000 DB : JBSUKS23
APPHDL : 0-87 APPID: C0A86313.AC04.00A286161018
FUNCTION: DB2 UDB, base sys utilities, sqleSubsequentConnect, probe:70
RETCODE : ZRC=0x850F0005=-2062614523=SQLO_NOSEG
"No Storage Available for allocation"
DIA8305C Memory allocation failure occurred.

When I look at 'top' I see...
Mem: 3104908K av, 2988836K used, 116072K free, 0K shrd,
89496K buff
Swap: 1052248K av, 279436K used, 772812K free
2000040K cached

When I sum the vmdata of all /proc/nnn/status (idea found on another
forum) i.e grep -i vmdata /proc/$i/status | cut -f 2 ...
I get a total of
1,247,372 KB

When I look at ipcs, i.e ipcs -m , and sum the shared memory segments,
I get
821,274,526 Bytes

So all seems to indicate around 1GB which is what I expected, so why
memory allocation problems?
Any pointers/explanation would be great.
Thanks.

Paul.

Nov 12 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.