correction, shmmax is the shared memory setting, not the semaphores. the semaphore settings are in /proc/sys/kernel/sem
the command ipcs can provide you some more information ipcs -l shows you the limits (for the semaphores, the information is retrieved from /proc/sys/kernel/sem) ipcs -u shows you a summary of current semaphore usage. these are my settings for ipcs -l (2cpu intel xeon 2GB RAM system) ------ 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 = 1024 max semaphores per array = 250 max semaphores system wide = 256000 max ops per semop call = 32 semaphore max value = 32767 ------ Messages: Limits -------- max queues system wide = 128 max size of message (bytes) = 8192 default max size of queue (bytes) = 16384 This what is in the sem file 250 256000 32 1024 which corresponds to : SEMMSL_value SEMMNS_value SEMOPM_value SEMMNI_value. SEMMSL = the maximum number of semaphores per semaphore set SEMMNI = the maximum number of semaphore sets in the entire Linux system. SEMMNS = SEMMSL * SEMMNI (any number greater than this does not make sense) SEMOPM = maximum number of semaphore operations that can be performed per semop(2) system call. Maybe ipcs -u while running your incremental backups can provide you some interesting information. Than change the appropriate values in the sem file. Greets, Filip. On Thu, 2004-06-03 at 09:56, Michael Andrewes wrote: > Hi, > > I have 8 gig of ram, the current size is shmmax is 33554432, or 32 meg, at > 1.5 would this be 24 meg? > > What would you suggest I set this to? > I am doinng regular nightly backups (around 2 gig now, was 10-15 before the > major crash). > Hourly incremental, overwriting the existing file (copying off server during > that hour), which by the last backup tend to be around 3-400 mb. > > Is the amount of memory for semaphores (as I assume this setting is) the > general consensus on why this is happening? > > > Regards > Michael Andrewes > > -----Original Message----- > From: Filip Sergeys [mailto:[EMAIL PROTECTED] > Sent: Thursday, 3 June 2004 5:53 PM > To: Michael Andrewes > Cc: 'Brunzema Martin'; [EMAIL PROTECTED] > Subject: RE: SapDB 7.4 regular crash on backup > > I believe it is in the shmmax file. > > cd /proc/sys/kernel > echo xxxxxxx > shmmax #where xxxxxxx is 1,5 x the RAM size in bytes. > However it does noet hurt if you take a much higher number. It has no > performance impact. > > Greets, > > Filip > > > On Thu, 2004-06-03 at 09:33, Michael Andrewes wrote: > > Hi, > > > > I'm unfamiliar with the term semaphores in regards to my operating > > system (redhat linux 7.3). > > > > I've googled and can see they are used for controlling concurrent > > access to memory/resource, but am unfamiliar with how To allocate > > more, or if it would actually assist my problem. > > > > > > Could you please provide some more information? > > > > > > Regards > > Michael Andrewes > > > > -----Original Message----- > > From: Brunzema, Martin [mailto:[EMAIL PROTECTED] > > Sent: Thursday, 3 June 2004 4:41 PM > > To: 'Michael Andrewes'; [EMAIL PROTECTED] > > Subject: AW: SapDB 7.4 regular crash on backup > > > > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Michael Andrewes [mailto:[EMAIL PROTECTED] > > > Gesendet: Donnerstag, 3. Juni 2004 01:45 > > > An: [EMAIL PROTECTED] > > > Betreff: SapDB 7.4 regular crash on backup > > > > > > > > > Hi, > > > > > > I have a problem with sapdb crashing on my regular incremental > > > backups. This happens reguarly, at random intervals. > > > > > > If I then bring the db back online again, and run the backup script > > > again, it works fine. > > > > > > The message in the knldiag is > > > 2004-06-02 22:30:02 857 12821 TASKING Thread 857 starting > > > 2004-06-02 22:30:02 30303 ERR 11277 IPC create_sem: > > > semget error, No > > > space left on device > > > 2004-06-02 22:30:02 30303 ERR 11599 BTRACE ----> Emergency > > > Stack Back > > > Trace <---- > > > > > > > > > Which would seem pretty self explanatory, except for the fact that > > > the DB volumes are nowhere near full LOG volumes are nowhere near > > > full > > > > Hi, > > > > I suppose your operating system runs out of semaphores. Can you > > configure it to supply some more of them to the kernel? > > > > regards, Martin > > > > -- > > MaxDB Discussion Mailing List > > For list archives: http://lists.mysql.com/maxdb To unsubscribe: > > http://lists.mysql.com/[EMAIL PROTECTED] > > > > > > > > -- > > MaxDB Discussion Mailing List > > For list archives: http://lists.mysql.com/maxdb > > To unsubscribe: > http://lists.mysql.com/[EMAIL PROTECTED] > > > -- > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > * System Engineer, Verzekeringen NV * > * www.verzekeringen.be * > * Oostkaai 23 B-2170 Merksem * > * 03/6416673 - 0477/340942 * > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > > > > -- > MaxDB Discussion Mailing List > For list archives: http://lists.mysql.com/maxdb > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] > -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* * System Engineer, Verzekeringen NV * * www.verzekeringen.be * * Oostkaai 23 B-2170 Merksem * * 03/6416673 - 0477/340942 * *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
