 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion Groups Database Servers DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybaseDesktop Databases FileMakerFoxProMS AccessParadoxGeneral General DB TopicsDatabase TheoryRelated Topics Java Development.NET DevelopmentVB DevelopmentMore Topics ... |
Database Forum / DB2 Topics / November 2006Ulimit 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 ! 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 > Hello All, > [quoted text clipped - 66 lines] > > 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 ! > 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 [quoted text clipped - 77 lines] > > > > Thanks a lot ! See the "DB2 for Linux Howto" here: http://tldp.org/HOWTO/DB2-HOWTO/prerequisites.html > I had done a ipclean before bringing up the instance. it did not > help. [quoted text clipped - 121 lines] >> > >> > Thanks a lot !  SignatureHaider That was some neat piece of information .. thanks a lot Haider ! > See the "DB2 for Linux Howto" here: > [quoted text clipped - 125 lines] > >> > > >> > Thanks a lot ! > I had done a ipclean before bringing up the instance. it did not help. > [quoted text clipped - 129 lines] > > > > > > 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 ! > > I had done a ipclean before bringing up the instance. it did not help. > > [quoted text clipped - 150 lines] > 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 ! > > I had done a ipclean before bringing up the instance. it did not help. > > [quoted text clipped - 150 lines] > Cheers, > Liam. > Hi Liam, > [quoted text clipped - 159 lines] > > 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. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.