473,583 Members | 3,553 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Ulimit and Kernel Param Settings

Hello All,

Brief info on the system:

Db2 version : "DB2 v8.1.0.121" and FixPak "13".
OS : RHEL 3 2.4.21-37.0.1
Memory : 8 GB
Swap : 2 GB

The issue here is the instance not being able to be started after the
reboot of the server. Giving the following error message:

"SQL1220N The database manager shared memory set cannot be allocated."

SQL1220N The database manager shared memory set cannot be allocated.

Explanation:

The database manager could not allocate its shared memory set. The
cause of this error may be insufficient memory resources either for the
database manager or the environment in which its
operation is being attempted. Memory resources that can cause this
error include:

o The number of shared memory identifiers allocated in the system

o The size of the shared memory segment

o The amount of paging or swapping space available in the system

o The amount of physical memory available in the system

User Response:

One or more of the following:

o Validate that sufficient memory resources are available to satisfy
the database manager's requirements, and those of the other programs
running on the system.

o On Linux 32-bit, increase the kernel parameter shmmax to 256 MB. On
Linux 64-bit, increase the kernel parameter shmmax to 1GB.

o Reduce database manager's memory requirement for this memory set by
reducing the database manager configuration parameters which affect it.
These are: maxagents , maxdari and, numdb .

o Where appropriate, stop other programs using the system.
------------------------------------------------------------------------------------------------------------------------
So I Started with reducing the # of maxagent. Which worked ! But the
strange part here was, initially the # of maxagent was set to 400,
which i had to reduce to 300 for bringing up the instance. Though once
the instance was up, i did update the maxagent back to 400. And then
did a db2stop and db2start it worked fine.

Also, I noticed in the diag log the following changes had been made by
db2:

kernel.semmni to 1024
kernel.msgmni to 1024
kernel.shmmax to 268435456 (256MB)

So my understanding of the issue, is that this is related with the
kernel parameters and not with the # of maxagents. So, I am just
wondering whether the parameter has to be set manually in
/etc/sysctl.conf. If so, wud this be ideal values considering the
amount of memory and swap space available. Any thoughts on this will be
greatly appreciated.

Thanks a lot !

Nov 27 '06 #1
8 7578
aj
I used to have issues like this w/ Informix of all things. Mem
segments would not clear out, even after the DB was offline. Perhaps
this is the root cause?

Have a look at the ipcs and ipcrm command.

HTH

cheers
aj

db2_d_b_a wrote:
Hello All,

Brief info on the system:

Db2 version : "DB2 v8.1.0.121" and FixPak "13".
OS : RHEL 3 2.4.21-37.0.1
Memory : 8 GB
Swap : 2 GB

The issue here is the instance not being able to be started after the
reboot of the server. Giving the following error message:

"SQL1220N The database manager shared memory set cannot be allocated."

SQL1220N The database manager shared memory set cannot be allocated.

Explanation:

The database manager could not allocate its shared memory set. The
cause of this error may be insufficient memory resources either for the
database manager or the environment in which its
operation is being attempted. Memory resources that can cause this
error include:

o The number of shared memory identifiers allocated in the system

o The size of the shared memory segment

o The amount of paging or swapping space available in the system

o The amount of physical memory available in the system

User Response:

One or more of the following:

o Validate that sufficient memory resources are available to satisfy
the database manager's requirements, and those of the other programs
running on the system.

o On Linux 32-bit, increase the kernel parameter shmmax to 256 MB. On
Linux 64-bit, increase the kernel parameter shmmax to 1GB.

o Reduce database manager's memory requirement for this memory set by
reducing the database manager configuration parameters which affect it.
These are: maxagents , maxdari and, numdb .

o Where appropriate, stop other programs using the system.
------------------------------------------------------------------------------------------------------------------------
So I Started with reducing the # of maxagent. Which worked ! But the
strange part here was, initially the # of maxagent was set to 400,
which i had to reduce to 300 for bringing up the instance. Though once
the instance was up, i did update the maxagent back to 400. And then
did a db2stop and db2start it worked fine.

Also, I noticed in the diag log the following changes had been made by
db2:

kernel.semmni to 1024
kernel.msgmni to 1024
kernel.shmmax to 268435456 (256MB)

So my understanding of the issue, is that this is related with the
kernel parameters and not with the # of maxagents. So, I am just
wondering whether the parameter has to be set manually in
/etc/sysctl.conf. If so, wud this be ideal values considering the
amount of memory and swap space available. Any thoughts on this will be
greatly appreciated.

Thanks a lot !
Nov 27 '06 #2
I had done a ipclean before bringing up the instance. it did not help.

however, this is the ipcs -l output for the system before and after the
instance came up respectively:

Before the instance came up :

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 32768
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1

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

------ Messages: Limits --------
max queues system wide = 16
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384

After the instance came up :

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 262144
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1

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

------ Messages: Limits --------
max queues system wide = 1024
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384

Was just curious to know, if manually keeping these modified entries in
/etc/sysctl.conf will help the initial glitch in bringing up the
instance. Or should I be increasing these max values still further
more.

Thanks a lot !
aj wrote:
I used to have issues like this w/ Informix of all things. Mem
segments would not clear out, even after the DB was offline. Perhaps
this is the root cause?

Have a look at the ipcs and ipcrm command.

HTH

cheers
aj

db2_d_b_a wrote:
Hello All,

Brief info on the system:

Db2 version : "DB2 v8.1.0.121" and FixPak "13".
OS : RHEL 3 2.4.21-37.0.1
Memory : 8 GB
Swap : 2 GB

The issue here is the instance not being able to be started after the
reboot of the server. Giving the following error message:

"SQL1220N The database manager shared memory set cannot be allocated."

SQL1220N The database manager shared memory set cannot be allocated.

Explanation:

The database manager could not allocate its shared memory set. The
cause of this error may be insufficient memory resources either for the
database manager or the environment in which its
operation is being attempted. Memory resources that can cause this
error include:

o The number of shared memory identifiers allocated in the system

o The size of the shared memory segment

o The amount of paging or swapping space available in the system

o The amount of physical memory available in the system

User Response:

One or more of the following:

o Validate that sufficient memory resources are available to satisfy
the database manager's requirements, and those of the other programs
running on the system.

o On Linux 32-bit, increase the kernel parameter shmmax to 256 MB. On
Linux 64-bit, increase the kernel parameter shmmax to 1GB.

o Reduce database manager's memory requirement for this memory set by
reducing the database manager configuration parameters which affect it.
These are: maxagents , maxdari and, numdb .

o Where appropriate, stop other programs using the system.
------------------------------------------------------------------------------------------------------------------------
So I Started with reducing the # of maxagent. Which worked ! But the
strange part here was, initially the # of maxagent was set to 400,
which i had to reduce to 300 for bringing up the instance. Though once
the instance was up, i did update the maxagent back to 400. And then
did a db2stop and db2start it worked fine.

Also, I noticed in the diag log the following changes had been made by
db2:

kernel.semmni to 1024
kernel.msgmni to 1024
kernel.shmmax to 268435456 (256MB)

So my understanding of the issue, is that this is related with the
kernel parameters and not with the # of maxagents. So, I am just
wondering whether the parameter has to be set manually in
/etc/sysctl.conf. If so, wud this be ideal values considering the
amount of memory and swap space available. Any thoughts on this will be
greatly appreciated.

Thanks a lot !
Nov 27 '06 #3
See the "DB2 for Linux Howto" here:

http://tldp.org/HOWTO/DB2-HOWTO/prerequisites.html
"db2_d_b_a" <su*****@gmail. comwrites:
I had done a ipclean before bringing up the instance. it did not
help.

however, this is the ipcs -l output for the system before and
after the instance came up respectively:

Before the instance came up :

------ Shared Memory Limits -------- max number of segments = 4096
max seg size (kbytes) = 32768 max total shared memory (kbytes) =
8388608 min seg size (bytes) = 1

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

------ Messages: Limits -------- max queues system wide = 16 max
size of message (bytes) = 8192 default max size of queue (bytes) =
16384

After the instance came up :

------ Shared Memory Limits -------- max number of segments = 4096
max seg size (kbytes) = 262144 max total shared memory (kbytes) =
8388608 min seg size (bytes) = 1

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

------ Messages: Limits -------- max queues system wide = 1024 max
size of message (bytes) = 8192 default max size of queue (bytes) =
16384

Was just curious to know, if manually keeping these modified
entries in /etc/sysctl.conf will help the initial glitch in
bringing up the instance. Or should I be increasing these max
values still further more.

Thanks a lot !
aj wrote:
>I used to have issues like this w/ Informix of all things. Mem
segments would not clear out, even after the DB was offline.
Perhaps this is the root cause?

Have a look at the ipcs and ipcrm command.

HTH

cheers aj

db2_d_b_a wrote:
Hello All,

Brief info on the system:

Db2 version : "DB2 v8.1.0.121" and FixPak "13". OS : RHEL 3
2.4.21-37.0.1 Memory : 8 GB Swap : 2 GB

The issue here is the instance not being able to be started
after the reboot of the server. Giving the following error
message:

"SQL1220N The database manager shared memory set cannot be
allocated."

SQL1220N The database manager shared memory set cannot be
allocated.

Explanation:

The database manager could not allocate its shared memory
set. The cause of this error may be insufficient memory
resources either for the database manager or the environment
in which its operation is being attempted. Memory resources
that can cause this error include:

o The number of shared memory identifiers allocated in the
system

o The size of the shared memory segment

o The amount of paging or swapping space available in the
system

o The amount of physical memory available in the system

User Response:

One or more of the following:

o Validate that sufficient memory resources are available to
satisfy the database manager's requirements, and those of the
other programs running on the system.

o On Linux 32-bit, increase the kernel parameter shmmax to 256
MB. On Linux 64-bit, increase the kernel parameter shmmax to
1GB.

o Reduce database manager's memory requirement for this memory
set by reducing the database manager configuration parameters
which affect it. These are: maxagents , maxdari and, numdb .

o Where appropriate, stop other programs using the system.
------------------------------------------------------------------------------------------------------------------------
So I Started with reducing the # of maxagent. Which worked !
But the strange part here was, initially the # of maxagent was
set to 400, which i had to reduce to 300 for bringing up the
instance. Though once the instance was up, i did update the
maxagent back to 400. And then did a db2stop and db2start it
worked fine.

Also, I noticed in the diag log the following changes had been
made by db2:

kernel.semmni to 1024 kernel.msgmni to 1024 kernel.shmmax to
268435456 (256MB)

So my understanding of the issue, is that this is related with
the kernel parameters and not with the # of maxagents. So, I
am just wondering whether the parameter has to be set manually
in /etc/sysctl.conf. If so, wud this be ideal values
considering the amount of memory and swap space available. Any
thoughts on this will be greatly appreciated.

Thanks a lot !
--
Haider
Nov 28 '06 #4
That was some neat piece of information .. thanks a lot Haider !

Haider Rizvi wrote:
See the "DB2 for Linux Howto" here:

http://tldp.org/HOWTO/DB2-HOWTO/prerequisites.html
"db2_d_b_a" <su*****@gmail. comwrites:
I had done a ipclean before bringing up the instance. it did not
help.

however, this is the ipcs -l output for the system before and
after the instance came up respectively:

Before the instance came up :

------ Shared Memory Limits -------- max number of segments = 4096
max seg size (kbytes) = 32768 max total shared memory (kbytes) =
8388608 min seg size (bytes) = 1

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

------ Messages: Limits -------- max queues system wide = 16 max
size of message (bytes) = 8192 default max size of queue (bytes) =
16384

After the instance came up :

------ Shared Memory Limits -------- max number of segments = 4096
max seg size (kbytes) = 262144 max total shared memory (kbytes) =
8388608 min seg size (bytes) = 1

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

------ Messages: Limits -------- max queues system wide = 1024 max
size of message (bytes) = 8192 default max size of queue (bytes) =
16384

Was just curious to know, if manually keeping these modified
entries in /etc/sysctl.conf will help the initial glitch in
bringing up the instance. Or should I be increasing these max
values still further more.

Thanks a lot !
aj wrote:
I used to have issues like this w/ Informix of all things. Mem
segments would not clear out, even after the DB was offline.
Perhaps this is the root cause?

Have a look at the ipcs and ipcrm command.

HTH

cheers aj

db2_d_b_a wrote:
Hello All,

Brief info on the system:

Db2 version : "DB2 v8.1.0.121" and FixPak "13". OS : RHEL 3
2.4.21-37.0.1 Memory : 8 GB Swap : 2 GB

The issue here is the instance not being able to be started
after the reboot of the server. Giving the following error
message:

"SQL1220N The database manager shared memory set cannot be
allocated."

SQL1220N The database manager shared memory set cannot be
allocated.

Explanation:

The database manager could not allocate its shared memory
set. The cause of this error may be insufficient memory
resources either for the database manager or the environment
in which its operation is being attempted. Memory resources
that can cause this error include:

o The number of shared memory identifiers allocated in the
system

o The size of the shared memory segment

o The amount of paging or swapping space available in the
system

o The amount of physical memory available in the system

User Response:

One or more of the following:

o Validate that sufficient memory resources are available to
satisfy the database manager's requirements, and those of the
other programs running on the system.

o On Linux 32-bit, increase the kernel parameter shmmax to 256
MB. On Linux 64-bit, increase the kernel parameter shmmax to
1GB.

o Reduce database manager's memory requirement for this memory
set by reducing the database manager configuration parameters
which affect it. These are: maxagents , maxdari and, numdb .

o Where appropriate, stop other programs using the system.
------------------------------------------------------------------------------------------------------------------------
So I Started with reducing the # of maxagent. Which worked !
But the strange part here was, initially the # of maxagent was
set to 400, which i had to reduce to 300 for bringing up the
instance. Though once the instance was up, i did update the
maxagent back to 400. And then did a db2stop and db2start it
worked fine.

Also, I noticed in the diag log the following changes had been
made by db2:

kernel.semmni to 1024 kernel.msgmni to 1024 kernel.shmmax to
268435456 (256MB)

So my understanding of the issue, is that this is related with
the kernel parameters and not with the # of maxagents. So, I
am just wondering whether the parameter has to be set manually
in /etc/sysctl.conf. If so, wud this be ideal values
considering the amount of memory and swap space available. Any
thoughts on this will be greatly appreciated.

Thanks a lot !

--
Haider
Nov 28 '06 #5

db2_d_b_a wrote:
I had done a ipclean before bringing up the instance. it did not help.

however, this is the ipcs -l output for the system before and after the
instance came up respectively:

Before the instance came up :

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 32768
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1

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

------ Messages: Limits --------
max queues system wide = 16
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384

After the instance came up :

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 262144
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1

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

------ Messages: Limits --------
max queues system wide = 1024
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384

Was just curious to know, if manually keeping these modified entries in
/etc/sysctl.conf will help the initial glitch in bringing up the
instance. Or should I be increasing these max values still further
more.

Thanks a lot !
aj wrote:
I used to have issues like this w/ Informix of all things. Mem
segments would not clear out, even after the DB was offline. Perhaps
this is the root cause?

Have a look at the ipcs and ipcrm command.

HTH

cheers
aj

db2_d_b_a wrote:
Hello All,
>
Brief info on the system:
>
Db2 version : "DB2 v8.1.0.121" and FixPak "13".
OS : RHEL 3 2.4.21-37.0.1
Memory : 8 GB
Swap : 2 GB
>
The issue here is the instance not being able to be started after the
reboot of the server. Giving the following error message:
>
"SQL1220N The database manager shared memory set cannot be allocated."
>
SQL1220N The database manager shared memory set cannot be allocated.
>
Explanation:
>
The database manager could not allocate its shared memory set. The
cause of this error may be insufficient memory resources either for the
database manager or the environment in which its
operation is being attempted. Memory resources that can cause this
error include:
>
o The number of shared memory identifiers allocated in the system
>
o The size of the shared memory segment
>
o The amount of paging or swapping space available in the system
>
o The amount of physical memory available in the system
>
User Response:
>
One or more of the following:
>
o Validate that sufficient memory resources are available to satisfy
the database manager's requirements, and those of the other programs
running on the system.
>
o On Linux 32-bit, increase the kernel parameter shmmax to 256 MB. On
Linux 64-bit, increase the kernel parameter shmmax to 1GB.
>
o Reduce database manager's memory requirement for this memory set by
reducing the database manager configuration parameters which affect it.
These are: maxagents , maxdari and, numdb .
>
o Where appropriate, stop other programs using the system.
------------------------------------------------------------------------------------------------------------------------
So I Started with reducing the # of maxagent. Which worked ! But the
strange part here was, initially the # of maxagent was set to 400,
which i had to reduce to 300 for bringing up the instance. Though once
the instance was up, i did update the maxagent back to 400. And then
did a db2stop and db2start it worked fine.
>
Also, I noticed in the diag log the following changes had been made by
db2:
>
kernel.semmni to 1024
kernel.msgmni to 1024
kernel.shmmax to 268435456 (256MB)
>
So my understanding of the issue, is that this is related with the
kernel parameters and not with the # of maxagents. So, I am just
wondering whether the parameter has to be set manually in
/etc/sysctl.conf. If so, wud this be ideal values considering the
amount of memory and swap space available. Any thoughts on this will be
greatly appreciated.
>
Thanks a lot !
>
Hello,

It sounds like you probably resolved your problem, but here's some
extra background in case you're curious.

You were hitting a problem with the kernel.shmmax setting. The reason
the problem "goes away" after bringing the database up succesfully once
is that DB2 modifies the current shmmax setting internally, but only
after the database manager shared memory segment is allocated. Once
you reboot though, you'll see that shmmax gets reverted back to it's
original setting, and the first time you bring the instance back up
you'll hit the shmmax issue again. Permanently updating kernel.shmmax
to 256MB (1GB on 64-bit Linux) will ensure you don't hit this same
problem again (the other kernel parms listed are good recommendations
as well).

This kernel.shmmax issue has been fixed in DB2 9.

Cheers,
Liam.

Nov 28 '06 #6
Hi Liam,

I have some how figured out that its the issue is with the shmax kernel
parameter. And it will be good to keep it at 256MB in the sysctl.
However, I would like to know, whether 256MB will be good enough or
should i be setting it slightly higher.

cheers !


Liam Finnie wrote:
db2_d_b_a wrote:
I had done a ipclean before bringing up the instance. it did not help.

however, this is the ipcs -l output for the system before and after the
instance came up respectively:

Before the instance came up :

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 32768
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1

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

------ Messages: Limits --------
max queues system wide = 16
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384

After the instance came up :

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 262144
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1

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

------ Messages: Limits --------
max queues system wide = 1024
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384

Was just curious to know, if manually keeping these modified entries in
/etc/sysctl.conf will help the initial glitch in bringing up the
instance. Or should I be increasing these max values still further
more.

Thanks a lot !
aj wrote:
I used to have issues like this w/ Informix of all things. Mem
segments would not clear out, even after the DB was offline. Perhaps
this is the root cause?
>
Have a look at the ipcs and ipcrm command.
>
HTH
>
cheers
aj
>
db2_d_b_a wrote:
Hello All,

Brief info on the system:

Db2 version : "DB2 v8.1.0.121" and FixPak "13".
OS : RHEL 3 2.4.21-37.0.1
Memory : 8 GB
Swap : 2 GB

The issue here is the instance not being able to be started after the
reboot of the server. Giving the following error message:

"SQL1220N The database manager shared memory set cannot be allocated."

SQL1220N The database manager shared memory set cannot be allocated.

Explanation:

The database manager could not allocate its shared memory set. The
cause of this error may be insufficient memory resources either for the
database manager or the environment in which its
operation is being attempted. Memory resources that can cause this
error include:

o The number of shared memory identifiers allocated in the system

o The size of the shared memory segment

o The amount of paging or swapping space available in the system

o The amount of physical memory available in the system

User Response:

One or more of the following:

o Validate that sufficient memory resources are available to satisfy
the database manager's requirements, and those of the other programs
running on the system.

o On Linux 32-bit, increase the kernel parameter shmmax to 256 MB. On
Linux 64-bit, increase the kernel parameter shmmax to 1GB.

o Reduce database manager's memory requirement for this memory set by
reducing the database manager configuration parameters which affect it.
These are: maxagents , maxdari and, numdb .

o Where appropriate, stop other programs using the system.
------------------------------------------------------------------------------------------------------------------------
So I Started with reducing the # of maxagent. Which worked ! But the
strange part here was, initially the # of maxagent was set to 400,
which i had to reduce to 300 for bringing up the instance. Though once
the instance was up, i did update the maxagent back to 400. And then
did a db2stop and db2start it worked fine.

Also, I noticed in the diag log the following changes had been made by
db2:

kernel.semmni to 1024
kernel.msgmni to 1024
kernel.shmmax to 268435456 (256MB)

So my understanding of the issue, is that this is related with the
kernel parameters and not with the # of maxagents. So, I am just
wondering whether the parameter has to be set manually in
/etc/sysctl.conf. If so, wud this be ideal values considering the
amount of memory and swap space available. Any thoughts on this will be
greatly appreciated.

Thanks a lot !

Hello,

It sounds like you probably resolved your problem, but here's some
extra background in case you're curious.

You were hitting a problem with the kernel.shmmax setting. The reason
the problem "goes away" after bringing the database up succesfully once
is that DB2 modifies the current shmmax setting internally, but only
after the database manager shared memory segment is allocated. Once
you reboot though, you'll see that shmmax gets reverted back to it's
original setting, and the first time you bring the instance back up
you'll hit the shmmax issue again. Permanently updating kernel.shmmax
to 256MB (1GB on 64-bit Linux) will ensure you don't hit this same
problem again (the other kernel parms listed are good recommendations
as well).

This kernel.shmmax issue has been fixed in DB2 9.

Cheers,
Liam.
Nov 28 '06 #7
Hi Liam,

I have some how figured out that its the issue is with the shmax kernel
parameter. And it will be good to keep it at 256MB in the sysctl.
However, I would like to know, whether 256MB will be good enough or
should i be setting it slightly higher.

cheers !


Liam Finnie wrote:
db2_d_b_a wrote:
I had done a ipclean before bringing up the instance. it did not help.

however, this is the ipcs -l output for the system before and after the
instance came up respectively:

Before the instance came up :

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 32768
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1

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

------ Messages: Limits --------
max queues system wide = 16
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384

After the instance came up :

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 262144
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1

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

------ Messages: Limits --------
max queues system wide = 1024
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384

Was just curious to know, if manually keeping these modified entries in
/etc/sysctl.conf will help the initial glitch in bringing up the
instance. Or should I be increasing these max values still further
more.

Thanks a lot !
aj wrote:
I used to have issues like this w/ Informix of all things. Mem
segments would not clear out, even after the DB was offline. Perhaps
this is the root cause?
>
Have a look at the ipcs and ipcrm command.
>
HTH
>
cheers
aj
>
db2_d_b_a wrote:
Hello All,

Brief info on the system:

Db2 version : "DB2 v8.1.0.121" and FixPak "13".
OS : RHEL 3 2.4.21-37.0.1
Memory : 8 GB
Swap : 2 GB

The issue here is the instance not being able to be started after the
reboot of the server. Giving the following error message:

"SQL1220N The database manager shared memory set cannot be allocated."

SQL1220N The database manager shared memory set cannot be allocated.

Explanation:

The database manager could not allocate its shared memory set. The
cause of this error may be insufficient memory resources either for the
database manager or the environment in which its
operation is being attempted. Memory resources that can cause this
error include:

o The number of shared memory identifiers allocated in the system

o The size of the shared memory segment

o The amount of paging or swapping space available in the system

o The amount of physical memory available in the system

User Response:

One or more of the following:

o Validate that sufficient memory resources are available to satisfy
the database manager's requirements, and those of the other programs
running on the system.

o On Linux 32-bit, increase the kernel parameter shmmax to 256 MB. On
Linux 64-bit, increase the kernel parameter shmmax to 1GB.

o Reduce database manager's memory requirement for this memory set by
reducing the database manager configuration parameters which affect it.
These are: maxagents , maxdari and, numdb .

o Where appropriate, stop other programs using the system.
------------------------------------------------------------------------------------------------------------------------
So I Started with reducing the # of maxagent. Which worked ! But the
strange part here was, initially the # of maxagent was set to 400,
which i had to reduce to 300 for bringing up the instance. Though once
the instance was up, i did update the maxagent back to 400. And then
did a db2stop and db2start it worked fine.

Also, I noticed in the diag log the following changes had been made by
db2:

kernel.semmni to 1024
kernel.msgmni to 1024
kernel.shmmax to 268435456 (256MB)

So my understanding of the issue, is that this is related with the
kernel parameters and not with the # of maxagents. So, I am just
wondering whether the parameter has to be set manually in
/etc/sysctl.conf. If so, wud this be ideal values considering the
amount of memory and swap space available. Any thoughts on this will be
greatly appreciated.

Thanks a lot !

Hello,

It sounds like you probably resolved your problem, but here's some
extra background in case you're curious.

You were hitting a problem with the kernel.shmmax setting. The reason
the problem "goes away" after bringing the database up succesfully once
is that DB2 modifies the current shmmax setting internally, but only
after the database manager shared memory segment is allocated. Once
you reboot though, you'll see that shmmax gets reverted back to it's
original setting, and the first time you bring the instance back up
you'll hit the shmmax issue again. Permanently updating kernel.shmmax
to 256MB (1GB on 64-bit Linux) will ensure you don't hit this same
problem again (the other kernel parms listed are good recommendations
as well).

This kernel.shmmax issue has been fixed in DB2 9.

Cheers,
Liam.
Nov 28 '06 #8

db2_d_b_a wrote:
Hi Liam,

I have some how figured out that its the issue is with the shmax kernel
parameter. And it will be good to keep it at 256MB in the sysctl.
However, I would like to know, whether 256MB will be good enough or
should i be setting it slightly higher.

cheers !


Liam Finnie wrote:
db2_d_b_a wrote:
I had done a ipclean before bringing up the instance. it did not help.
>
however, this is the ipcs -l output for the system before and after the
instance came up respectively:
>
Before the instance came up :
>
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 32768
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1
>
------ Semaphore Limits --------
max number of arrays = 128
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 32
semaphore max value = 32767
>
------ Messages: Limits --------
max queues system wide = 16
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384
>
After the instance came up :
>
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 262144
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1
>
------ Semaphore Limits --------
max number of arrays = 1024
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 32
semaphore max value = 32767
>
------ Messages: Limits --------
max queues system wide = 1024
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384
>
Was just curious to know, if manually keeping these modified entries in
/etc/sysctl.conf will help the initial glitch in bringing up the
instance. Or should I be increasing these max values still further
more.
>
Thanks a lot !
>
>
aj wrote:
I used to have issues like this w/ Informix of all things. Mem
segments would not clear out, even after the DB was offline. Perhaps
this is the root cause?

Have a look at the ipcs and ipcrm command.

HTH

cheers
aj

db2_d_b_a wrote:
Hello All,
>
Brief info on the system:
>
Db2 version : "DB2 v8.1.0.121" and FixPak "13".
OS : RHEL 3 2.4.21-37.0.1
Memory : 8 GB
Swap : 2 GB
>
The issue here is the instance not being able to be started after the
reboot of the server. Giving the following error message:
>
"SQL1220N The database manager shared memory set cannot be allocated."
>
SQL1220N The database manager shared memory set cannot be allocated.
>
Explanation:
>
The database manager could not allocate its shared memory set. The
cause of this error may be insufficient memory resources either for the
database manager or the environment in which its
operation is being attempted. Memory resources that can cause this
error include:
>
o The number of shared memory identifiers allocated in the system
>
o The size of the shared memory segment
>
o The amount of paging or swapping space available in the system
>
o The amount of physical memory available in the system
>
User Response:
>
One or more of the following:
>
o Validate that sufficient memory resources are available to satisfy
the database manager's requirements, and those of the other programs
running on the system.
>
o On Linux 32-bit, increase the kernel parameter shmmax to 256 MB. On
Linux 64-bit, increase the kernel parameter shmmax to 1GB.
>
o Reduce database manager's memory requirement for this memory set by
reducing the database manager configuration parameters which affect it.
These are: maxagents , maxdari and, numdb .
>
o Where appropriate, stop other programs using the system.
------------------------------------------------------------------------------------------------------------------------
So I Started with reducing the # of maxagent. Which worked ! But the
strange part here was, initially the # of maxagent was set to 400,
which i had to reduce to 300 for bringing up the instance. Though once
the instance was up, i did update the maxagent back to 400. And then
did a db2stop and db2start it worked fine.
>
Also, I noticed in the diag log the following changes had been made by
db2:
>
kernel.semmni to 1024
kernel.msgmni to 1024
kernel.shmmax to 268435456 (256MB)
>
So my understanding of the issue, is that this is related with the
kernel parameters and not with the # of maxagents. So, I am just
wondering whether the parameter has to be set manually in
/etc/sysctl.conf. If so, wud this be ideal values considering the
amount of memory and swap space available. Any thoughts on this will be
greatly appreciated.
>
Thanks a lot !
>
Hello,

It sounds like you probably resolved your problem, but here's some
extra background in case you're curious.

You were hitting a problem with the kernel.shmmax setting. The reason
the problem "goes away" after bringing the database up succesfully once
is that DB2 modifies the current shmmax setting internally, but only
after the database manager shared memory segment is allocated. Once
you reboot though, you'll see that shmmax gets reverted back to it's
original setting, and the first time you bring the instance back up
you'll hit the shmmax issue again. Permanently updating kernel.shmmax
to 256MB (1GB on 64-bit Linux) will ensure you don't hit this same
problem again (the other kernel parms listed are good recommendations
as well).

This kernel.shmmax issue has been fixed in DB2 9.

Cheers,
Liam.
Hello,

Having it set to 256 MB is good enough to prevent failures.
Internally, if DB2 needs a piece of shared memory larger than 256 MB,
it will convert that into multiple 256MB segments. If you set
kernel.shmmax larger than the biggest piece of shared memory you will
need (likely your database shared memory segment), then we will try to
allocate the entire piece of shared memory using a single segment. So,
there could be a very slight performance/resource benefit to setting
shmmax higher.

Cheers,
Liam.

Nov 29 '06 #9

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

16
3402
by: Maciej Kalisiak | last post by:
I use this simple test in Python: def foo(i): print i foo(i+1) import sys sys.setrecursionlimit(1000000) foo(0) Now, my understanding is that I get the segfault when Python overruns the C
12
2063
by: Andrew Chalk | last post by:
My app. sees an exception from the kernel at an obscure address, 0x7c59ba9d. When running under the VC++ 6.0 debugger, I can trap this each time it occurs. If I want to trap it in my program and just tell the program to just continue (i.e. not pass the exception up the chain) how do I do this? Any idea how I can find out what the cause of...
7
2844
by: Harolds | last post by:
The code below worked in VS 2003 & dotnet framework 1.1 but now in VS 2005 the pmID is evaluated to "" instead of what the value is set to: .... xmlItems.Document = pmXML // Add the pmID parameter to the XSLT stylesheet XsltArgumentList xsltArgList = new XsltArgumentList(); xsltArgList.AddParam("pmID", "", pmID);...
2
2521
by: Rick | last post by:
Does anyone have any recommendations for setting kernel.shmmax and/or some of the other kernel parms that affect DB2, on a system that has 24-32GB of RAM available? I am also looking for a good resouce that describes what these parms really control. I want DB2 to take advantage of the large amount of RAM. These machines will have an...
0
1854
by: Daimy | last post by:
I meet the same problem below, please help me! Thanks! //written by some one I have developed a windows forms user control, which I am going to host in Internet Explorer.. I am familiar with the security settings requirement inorder to do the
2
2016
by: zhicheng wang | last post by:
Dear all i have a dedicated server mainly running postgresql, currently rh-posgtresql-7.3.6.7 (and samba, ypbind etc). The server is a dual processor machine and the OS is RHEL AS 3. I am currently running kernel-smp-2.4.21-15.0.4.EL. My question is: do i need to run smp kernel for
1
3022
by: SR | last post by:
Good morning/afternoon: What are the recommended ULIMIT settings for the following on a 32-Bit DB2 instance running on a 64-Bit AIX (5.3)? time(seconds) file(blocks) data(kbytes) stack(kbytes) memory(kbytes)
6
7025
by: Maxim Veksler | last post by:
Hi, I've written this code, the general idea was to listen on all 65535 port of tcp for connection. """ #!/usr/bin/env python import socket, select def get_non_blocking_socket(port_number):
3
7526
by: Jarek Zgoda | last post by:
Hi, all, anybody has an idea on how to set ulimit (-v in my case, linux) for process started using subprocess.Popen? -- Jarek Zgoda Skype: jzgoda | GTalk: zgoda@jabber.aster.pl | voice: +48228430101 "We read Knuth so you don't have to." (Tim Peters)
0
7894
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
0
7821
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language...
0
6577
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
1
5697
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes...
0
5370
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert...
0
3841
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
2328
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
1
1424
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
0
1152
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.