brsmith@cs.umn.edu (Brian R. Smith) (04/06/90)
luis@octopus.tds.kth.se (Luis Barriga) writes: >I have read that shared memory is implemented in sequent series as a >mapped file into memory via the mmap() system call. >A friend of mine is running a *LARGE* program that dynamically >allocates huge amounts of data from shared memory. At some point >during execution the program crashes with a "filesystem full" message. >The program we test increases up to 60 MB virtual memory. My suggestion >was the shared memory creates temporary files in the home directory. Hmmm. Anyone know what /usr/tmp/SysVshmem is for, then? I'm not contesting that shared memory is allocated in your home directory (I've never tried it), just wondering aloud... >Trying to confirm my supposition we did the following. >We have been monitoring the execution of his program, BUT his home >directory does not increase during execution!. We have monitored disk >usage via "du". However, the file system where his home directory resides >becomes full during execution (using df). Why? Where are the mapped >files allocated from? Or are mapped files not visible to "du"? /usr/etc/quot is GREAT for finding those large, unlinked files. We have had many problems with students running jobs in the background, with the output redirected to a file. When they login later and see that the output file is getting too big, they delete it, but forget (or don't know how) to kill their job. All this has done is make an invisible file that slowly grabs all the disk space... fstat, from the 4.3 tahoe sources, is also an *extremely* useful tool. With it, you can actually find out what files a process has open. I'd expect that you could use it to actually SEE which file is mapped into memory. (Not sure on how mmap'd files are implemented, though, so I could be wrong.) [Should be in a comp.sources.unix archive, somewhere.] Brian brsmith@cs.umn.edu