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 !
8  7561 
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 !
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 !
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
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
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.
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.
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.
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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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
|
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...
|
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...
|
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...
|
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...
|
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...
|
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)...
|
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...
|
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:...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
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,...
|
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...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
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...
| |
