Q: memory usage
Robert Knop wrote on Feb 02, 1999
I'm trying to run IRAF on a whole bunch of PCs all at the same time. However, they're all accessing the same filesystem via NFS. What this means is that they're all starting to conflict with each other for disk read/writes. Each PC has a lot of memory (128M or 256M). However, the ccdproc process only seems to be using about 20M of the memory. Is there a way I can tell IRAF to use more memory, so that it doesn't have to read and write from disk so often? (There are other things I can try to work around the problem, but since the memory is available it'd be nice if I could get IRAF to use it.) -Rob =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ==== Rob Knop ===== rknop@lbl.gov ====== http://panisse.lbl.gov/~rknop ======
Mike Fitzpatrick wrote on Feb 03, 1999
> Each PC has a lot of memory (128M or 256M). However, the ccdproc process > only seems to be using about 20M of the memory. Is there a way I can tell > IRAF to use more memory, so that it doesn't have to read and write from > disk so often? Not really. What you want is a memory-based filesystem such as 'tmpfs' on a Sun, but I'm not aware of any thing like this (that works anyway) for Linux or FreeBSD. The normal CCDPROC task has a 'max_cache' param you can set that will cause it to cache calibration images, if you were referring to MSCRED then try setting the MSCRED 'im_bufsize' package parameter to increase the image I/O buffer. This may gain you a little, is it worth copying the images to a local disk before process- ing? -Mike
Robert Knop wrote on Feb 03, 1999
On Wed, 3 Feb 1999, Mike Fitzpatrick wrote: > Not really. What you want is a memory-based filesystem such as > 'tmpfs' on a Sun, but I'm not aware of any thing like this (that works > anyway) for Linux or FreeBSD. The normal CCDPROC task has a 'max_cache' > param you can set that will cause it to cache calibration images, if > you were referring to MSCRED then try setting the MSCRED 'im_bufsize' > package parameter to increase the image I/O buffer. This may gain you > a little, is it worth copying the images to a local disk before process- > ing? I will try the im_bufsize, to see if that changes things. However, your latter suggestion is good; I've managed to get local scratch disks on each of the computers, and am copying the files over ahead of time. Since that only needs to be done once for the calibration images, that seems to be giving a big win in processing time. Thanks, -Rob =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ==== Rob Knop ===== rknop@lbl.gov ====== http://panisse.lbl.gov/~rknop ======
Tim Pickering wrote on May 03, 1999
On 3 Feb 1999 15:33:35 -0700, Robert Knop <rknop@panisse.lbl.gov> wrote: >On Wed, 3 Feb 1999, Mike Fitzpatrick wrote: > >> Not really. What you want is a memory-based filesystem such as >> 'tmpfs' on a Sun, but I'm not aware of any thing like this (that works >> anyway) for Linux or FreeBSD. The normal CCDPROC task has a 'max_cache' >> param you can set that will cause it to cache calibration images, if >> you were referring to MSCRED then try setting the MSCRED 'im_bufsize' >> package parameter to increase the image I/O buffer. This may gain you >> a little, is it worth copying the images to a local disk before process- >> ing? > >I will try the im_bufsize, to see if that changes things. However, your >latter suggestion is good; I've managed to get local scratch disks on each >of the computers, and am copying the files over ahead of time. Since that >only needs to be done once for the calibration images, that seems to be >giving a big win in processing time. the problem with doing heavy NFS with linux or freebsd is that NFS writes are done synchronously only so you won't take advantage of the file caching that these OS's can do on local disks. also, the NFS performance isn't all that great for either linux or freebsd unless you get the very latest kernels. i see almost a factor of two improvement for both reads and writes using linux 2.2.7 and knsfd 1.2.2 as opposed to the stock redhat 5.2 nfsd and 2.0.36. still, unless you have a massive RAID array on the other end of the NFS mount, you may be limited by the performance of that NFS mounted disk. i know from experience that linux caches local disk reads and writes well which is why my CCD reduction scripts run faster on my K6-2 system than on an ultra 10 running solaris 2.6 even though the ultra has a faster disk (the ultra is faster if i do everything in /tmp. go figure.). i don't know if linux caches files read over NFS as well, if at all, since i don't use NFS that heavily. i know writes aren't cached because the v2 NFS that linux uses specify that. even with solaris 2.6 and a 100base-T switched network, though, NFS will still be a factor of two or three slower than local access given the speeds of modern drives (even cheap UDMA ones) so doing as much as possible on local scratch disks is a good thing. tim -- +----------------------------------------------------------------------+ | Tim Pickering | Kapteyn Institute, Postbus 800 | | tim@astro.rug.nl | 9700 AV Groningen, The Netherlands | | http://www.astro.rug.nl/~tim/ | +31-50-363-6519 | +----------------------------------------------------------------------+ I came home the other night and tried to open the door with my car keys...and the building started up. So I took it out for a drive. A cop pulled me over for speeding. He asked me where I live... "Right here". -- Steven Wright
Last post on May 03, 1999