Last week or so I had posted my request (and answer) on how to create a
ramdisk bigger than the default 4MB/8MB sizes, in order to have a
ram-resident filesystem for some really I/O intensive work.
Unfortunately, I have some bad news to report. I have done some fairly
in-depth benchmark comparisons between running my process from disk and from
ramdisk. The results were surprising to say the least. The ramdisk is only
65% as fast as the hard-disk, instead of the large speed increases I was
expecting.
Specs are as follows:
Pentium II/333MHz processor
256MB SDRAM
Adaptec 2940UW SCSI controller
Seagate Medalist Pro UWSE 4GB SCSI drive, 7200RPM
Linux Slackware 3.6
Kernel versions 2.0.36 and 2.2.2 (no difference)
128MB swapfile defined and active as /dev/swap1.
No swapping occurs according to /proc/meminfo
Filesystem Parameters for /usr/local
ext2 filesystem, standard inode distribution
196MB either as /dev/ram0 or /dev/sda2
/usr/local is where all the action takes place -- processes are executed,
files are read, files are written, libraries are referenced.
The results:
I timed my process execution time using the time command. I ran the
process a total of eight times, four using the ramdisk filesystem and four
using the hard-disk filesystem. None of the execution times varied by more
than 3 seconds from the others in it's group.
The timed process was the only activity on the box during the testing
period, except for normal system operational services (no web servers, etc).
Execution time under the ramdisk filesystem was 230 seconds.
Execution time under the hard-disk filesystem was 150 seconds.
Anybody care to explain this huge time discrepancy?
I have rebooted the system and randomly run the command using either the
ramdisk or the hard-disk, and execution times remain steady at the above
times, so I don't believe there is any significant amount of buffering or
caching that can explain the slower ramdisk.
Doug Apel
Sr. Network Administrator
Omnipoint Technologies, Inc.
[EMAIL PROTECTED]
---
Any personal opinions expressed herein do not necessarily represent
those of Omnipoint Technologies, Inc.
