Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 (Fortune) 6/7/84; site dmsd.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!hao!hplabs!hpda!dmsd!bass From: bass@dmsd.UUCP (John Bass) Newsgroups: net.unix-wizards Subject: Re: Suggestions for UNIX RAM disks wanted Message-ID: <149@dmsd.UUCP> Date: Wed, 10-Oct-84 14:52:46 EDT Article-I.D.: dmsd.149 Posted: Wed Oct 10 14:52:46 1984 Date-Received: Fri, 12-Oct-84 06:42:32 EDT References: <12808@sri-arpa.UUCP> Lines: 46 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