john@sol1.UUCP (john) (09/27/84)
We are looking at the possibility of adding a RAM
disk to our PLEXUS UNIX SysIII system. (multibus)
Would appreciate responses as to the following:
1> specific products that would function on our system. (cost per meg, etc.)
2> Experiences with RAM disks. (performance, implementation, etc.)
3> Suggestions on what to mount on the disk. (/tmp, swap, etc.)
The PLEXUS harddisk controller is very intelligent now.
It occurs to me that A more or less generic multibuss controller would
possibly slow down the otherwise optimized system.
Thanks in advance,
John Korsmeyer
THE SOLUTION
akgua!sol1!johnbass@dmsd.UUCP (John Bass) (10/10/84)
The suggestion that "If you only have one ramdisk /tmp will produce the most noticeable speed up of system operation" may not be optimal for most systems. I have both measured and analytical data that suggests that a small root filesystem will have the largest effect for most combinations of best response time and throughput. There are strong arguments against using /tmp mounted on a small ramdisk. 1) ramdisk sizes of .5-1.5mb are typical tradeoffs for available memory sizes of 1 to 4mb. This is often to small for a tmp area. Some programs like sort require tmp areas twice or more larger than the file being sorted. For 10-20 users systems the tmp areas must be 1-5mb in size. Multiple C compiles of large programs also require large tmp areas. Some mail systems copy the entire mbox to tmp ... often 100kb or more. Ar copies the entire library to tmp for updates ... often 100kb or more. 2) On most multi-user systems 10-20 users often 25-45% of the filesystem accesses are in the root. This traffic is in /bin, directory's, and pipes. This of course is highly system dependent -- non-developmental system will be loading dependent upon the major application. 3) Most file accesses are to read files less than 3kb in length. For files of this size the open times (IE nami search) represent 50-90% of the real time handling the file. 4) /tmp is used primarily by editors, compilers, mail and tools. Most editing is entry and local changes ... tmp file access time has little effect on response times. For other programs /tmp access represent 10-40% of the total I/O traffic for the job. The rest of the traffic is program loading, directory searches, and accesses to /lib, /usr/lib, and /usr/include data -- transfering the mostly comonly used programs and data to a ram disk root has a much bigger effect on reducing overall response times and increasing system throughput. These arguments generally point toward building a small root after bootup by init ... and having init chroot before going multiuser. The speed increases in terms of BOTH throughput and response time are significant for many applications. Generally place the top 35 most accessed programs in /bin. Move the infreqently accessed utilities in /etc to /usr/etc. Leave ample space free to handle pipes ... maxpipe*2*#users for systems up to about 10 users. Larger systems can get by with less, systems using pipes a lot require more. John Bass Systems Performance Consultant
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/14/84)
No utility should use /tmp for large files. That is what /usr/tmp is for.
henry@utzoo.UUCP (Henry Spencer) (10/16/84)
> No utility should use /tmp for large files. That is what /usr/tmp is for.
The philosophy we tend to follow around here is the exact opposite:
temporary files go on /tmp. If there is a size/speed tradeoff involved,
that's the system's problem, not yours. Most machines hereabouts have
a separate /tmp filesystem; some don't even *have* a /usr/tmp directory.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henrywls@astrovax.UUCP (William L. Sebok) (10/19/84)
On our system (running 4.2 BSD) /usr/tmp is a symbolic link to /tmp .
--
Bill Sebok Princeton University, Astrophysics
{allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls