locking "nosync" changes effects (benchmark)

[Matthias Andree]

Here are the benchmarks I made before and after changing the code to use
"nosync" when closing a data base that hasn't been written to because of
locking issues. Tests were run once each on my idle otherwise idle
workstation, time given is REAL time (in seconds) to run t.lock2. User
time was always around 2.4s, system time .2 to .5 s. The nosync tests
used marginally less user and system time (.1 to .2 s).

I wonder what BDB has to fsync() before any data have been modified, but
given Linux' sync-the-world semantics (fsync() usually syncs the whole
file system) Linux might sync data of other applications that write to
the same file system that our test data bases are in.

I hope BDB doesn't write anything before the application
adds/changes/deletes data, because if it did, our locking scheme were
broken and based on assumptions that did not hold.

Key data: AMD Duron 700, 320 MB RAM PC133, SuSE Linux + 2.4.19 Kernel,
SCSI Drive Fujitsu MAH 3182MP 18G 7200/min Tagged Queueing, ATA Drive
Maxtor 4K060H3 60G 5400/min. Both drives have their write caches turned
off.

File system      Drive old     nosync
-------------------------------------------
ext3 ordered     SCSI    56.7  4.0
reiser ordered   SCSI  >260    3.7
reiser writeback SCSI  >120    3.8
ext2             ATA     22.4  3.5
shm              RAM      2.7  2.5

">" means: test was aborted after this amount of time

To sum it up: reiserfs stinks for fsync() load but is otherwise slightly
faster than ext3. In any case, closing the word lists without sync when
we haven't modified them speeds things up big time. IOW, fsync() is
expensive. We knew that before, and now we know the price.

Have fun,

-- 
Matthias Andree