Re: Shared Memory Issues
Lance Rocker wrote: Hello, I too had problems with running out of shared mem segments, so I wrote my first ever perl script that does something useful for me. I've attached it to this email and I'll paste it in below too, for convenience. I noticed that many (most?) of the shared mem segments in use, when I was running out of them, didn't actually have any processes attached to them. This perl script just goes through, finds those non-attached shared mem segments, and deletes them. I've found running it periodically works great for me, you may even want to put it in your crontab and let it run once a day, just as a little proactive housekeeping. Hey, nice script. Is there anything Perl can't do these days? ;^) I'm currently just enjoying the power of awk. I hope it doesn't get forgotten in the shadow of Perl. However, it seems strange that you're getting non-attached memory segments. Surely it is the job of the kernel to clean up after processes (if they're badly programmed and don't do it themselves)? Perhaps one program is leaking? My system has been up for two days now since last reboot, I just ran your program, and I had 55 shared memory segments, 0 non-attached... For the record, here are the kernel options I use with this kernel: options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options SHMALL=16384 options SHMMAX="(SHMMAXPGS*PAGE_SIZE+1)" options SHMMAXPGS=8192 options SHMMIN=128 options SHMMNI=128 options SHMSEG=96 I think that last one makes the biggest difference, and is the one you may want to make as large as possible, though 96 works fine for my 64MB of ram. This is a 4.0-release kernel, and I use XFree86 4.0 with Enlightenment as my window manager. It definitely does! The default setting, as someone correctly pointed out, in LINT, is SHMSEG=9. As you can see above, my system is currently using 55, more than 5X that limit! I've sent in a brief e-mail to freebsd-stable, suggesting that the GENERIC kernel default is altered to something a little higher. The SHMSEG setting is under the "undocumented" options in LINT, which is not helpful or conducive to people fixing this problem. It's a good job freebsd-hackers exists... ;^) The SHMSEG=1024 setting I've got is probably excessive, but I would guess the performance degradation is negligible to non-existent in having more than you need, especially due to FreeBSD's unmatched memory management, as I've noticed no difference in performance. yes, ipcs and ipcrm are the ones my perl script uses. Check out the manpage for each of them. . . I like to run "ipcs -mbop" to get a lot of info about used shared mem segments. -Lance Yes, they both have more settings than I was aware of. Oh, the joy of manpages... -- "I'm entirely unaccountable for any moments of sanity contained herein." :s/Windows/UNIX John Toon | [EMAIL PROTECTED] | "Sonnilon" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Shared Memory Issues
On Fri, Sep 08, 2000 at 02:56:10PM +0100, John Toon wrote: However, it seems strange that you're getting non-attached memory segments. Surely it is the job of the kernel to clean up after processes (if they're badly programmed and don't do it themselves)? Perhaps one program is leaking? SysV shared memory segments are defined to stick around until some appropriately-privileged user process deletes them. I was thinking recently that it might be nice to extend that API so a process creating such a segment could ask the kernel to reference-count it and delete it if the refcount goes to zero, but any app that wants that behavior can just use mmap() anyway, which has the advantage of being portable. -- Ben 220 go.ahead.make.my.day ESMTP Postfix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Shared Memory Issues
John Toon wrote: Hi, I've scoured through the net and the mailing archives, but was unable to find any satisfactory information on a certain problem I'm suffering at the moment. After getting the dreaded "shmget() failed" error message, I have since tried several recompiles of the kernel to fix the problem. The same with me. I added options SHMMAXPGS=16385 options SHMMAX=(SHMMAXPGS*PAGE_SIZE+1) to my new kernel and recompiled. I tried this without success. However, under XFree86 4.0, I still seem to be getting shared memory issues. I'm using XFree86 3.3.6 with the server of 3.3.5. The problem is not in XFree, but in imlib. Compupic refuses to start under GNOME issuing X Error of failed request: BadAccess (attempt to access private resource denied) Major opcode of failed request: 146 (MIT-SHM) Minor opcode of failed request: 1 (X_ShmAttach) Serial number of failed request: 2961 Current serial number in output stream: 2962 Yet works under VTWM - until I load up a few applications, when it terminates again, with the same problem. More annoyingly, FXTV also dies with the same problem. Next, I tried another kernel, this time with the following options: options SEMMNI=100 options SEMMNS=300 options SEMUME=100 options SEMMNU=150 options SHMMAXPGS=16385 I omitted the SHMMAX option, as I have read that this option is now deprecated. Unfortunately, this kernel was not better. For me, playing with SHM options made things worse than it was in the default SHM kernel configuration. I'm currently running FreeBSD 4.0-RELEASE. Several questions; 1. If I upgrade to 4.1-STABLE (which I will be soon), will the shared memory issue disappear? I doubt so. I'm running 5.0-CURRENT, and still have the problem. -- * *Konstantin Chuguev - Application Engineer * * Francis House, 112 Hills Road * Cambridge CB2 1PQ, United Kingdom D A N T E WWW:http://www.dante.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Shared Memory Issues
I think that there is an application that is not releasing memory resources you can check that with ipcs and ipcsrm cheers At 11:35 AM 9/5/2000 +0100, Konstantin Chuguev wrote: John Toon wrote: Hi, I've scoured through the net and the mailing archives, but was unable to find any satisfactory information on a certain problem I'm suffering at the moment. After getting the dreaded "shmget() failed" error message, I have since tried several recompiles of the kernel to fix the problem. The same with me. I added options SHMMAXPGS=16385 options SHMMAX=(SHMMAXPGS*PAGE_SIZE+1) to my new kernel and recompiled. I tried this without success. However, under XFree86 4.0, I still seem to be getting shared memory issues. I'm using XFree86 3.3.6 with the server of 3.3.5. The problem is not in XFree, but in imlib. Compupic refuses to start under GNOME issuing X Error of failed request: BadAccess (attempt to access private resource denied) Major opcode of failed request: 146 (MIT-SHM) Minor opcode of failed request: 1 (X_ShmAttach) Serial number of failed request: 2961 Current serial number in output stream: 2962 Yet works under VTWM - until I load up a few applications, when it terminates again, with the same problem. More annoyingly, FXTV also dies with the same problem. Next, I tried another kernel, this time with the following options: options SEMMNI=100 options SEMMNS=300 options SEMUME=100 options SEMMNU=150 options SHMMAXPGS=16385 I omitted the SHMMAX option, as I have read that this option is now deprecated. Unfortunately, this kernel was not better. For me, playing with SHM options made things worse than it was in the default SHM kernel configuration. I'm currently running FreeBSD 4.0-RELEASE. Several questions; 1. If I upgrade to 4.1-STABLE (which I will be soon), will the shared memory issue disappear? I doubt so. I'm running 5.0-CURRENT, and still have the problem. -- * *Konstantin Chuguev - Application Engineer * * Francis House, 112 Hills Road * Cambridge CB2 1PQ, United Kingdom D A N T E WWW:http://www.dante.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Shared Memory Issues
Clive Lin wrote: Hm... long time ago I asked google about those SHM* and I thought SHMSEG may be the key point. Because SHMSEG stands for maximum number of shared segments per process. Fantastic! You're absolutely correct. Everything is now working perfectly. My mistake had been to think that the system was running out of actual shared memory pages, but successive increases of the maximum pages had no effect. The actual problem, as you've rightly pointed out, was that each process was running out of shared memory segments... Incidentally, how many pages does a segment in FreeBSD correspond to? 4? 16? Ask google ? It's really powerful... I know ;^) Google is considerably better than any other search engine... About the SYSV options, I have small notes about them. Though, I couldn't make sure they are 100% correct. It just works, and I have no more interests to dig more :- SHMALL max shared mem system wide (in pages). SHMMAX max shared memory segment size (bytes). SHMMIN min shared memory segment size (bytes). SHMMNI max num of shared segments system wide. SHMSEG maximum number of shared segments per process. Regards, Clive Just as a side note, are there any commands available that will inform me how many shared memory pages are currently being used by the running system? Thanks. -- :s/Windows/UNIX John Toon | [EMAIL PROTECTED] | "Sonnilon" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
