Suggestions for UNIX RAM disks wanted
John Bass
bass at dmsd.UUCP
Thu Oct 11 04:52:46 AEST 1984
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
More information about the Comp.unix.wizards
mailing list