Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Mar 1996 01:10:14 +1100
From:      Bruce Evans <bde@zeta.org.au>
To:        bde@zeta.org.au, toor@dyson.iquest.net
Cc:        hackers@FreeBSD.ORG, julian@ref.tfs.com, rashid@rk.ios.com
Subject:   Re: pwd_mkdb - really slow :(
Message-ID:  <199603041410.BAA16147@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>> >it might also be quicker to build the entire databse in ram 
>> >and bang it out to disk as a single write.. :)
>> 
>> Not much, if write() is suitably buffered.
>> 
>Ahh... Come on, you know that the disk cache works, it simply does not
>write-behind as much as you would like.  It read-caches very nicely.

It has esentially no write-behind.  This is harmful for more than highly
random writes:

	$ du -ks /sys/
	15238
	$ time tar cf /dev/null /sys/
	10.25 real   0.15 user    1.18 sys
	$ expr 15328 \* 100 / 1025
	1495 # K/s read, not great
	$ time tar cf /dev/null /sys/
	 2.98 real   0.11 user    1.04 sys
	$ expr 15328 \* 100 / 298
	5143 # K/s read, good (?) (I think the previous step cached all data
	                           or all metadata, not sure which)
	$ cd /c/tmp  # /c is mounted with -o async and is on same disk as /sys/
	$ time cp -pR /sys/ .
	39.63 real   0.10 user    3.02 sys
	$ expr 15238 / 59
	386 # K/s read+write, caching was ineffective
	$ iozone 256 8192 # iozone 16 would move about the same amount of data,
	                    but caches too effectively to be accurate
	4623837 bytes/second for writing the file
	5087316 bytes/second for writing the file
	$ expr 386 \* 1024 \* 2 \* 100 \( 4623837 + 5087316 \)
	8 # % efficiency

BTW, for 30000 password entries, pwd.db and spwd.db were 9.5MB each.
Keeping them all in real memory, either in user space or in the disk
cache, would at best have barely worked on the 32MB system that I tested
on.  A system 32MB of memory, especially one with only one disk,
probably shouldn't allow anywhere near 18MB of pending writes even if
there is currently RAM to spare, because it would take too long to
satisfy future RAM requirements.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603041410.BAA16147>