Re: Performance data points

On Friday 05 Nov 2004 10:57, Matt Hamilton wrote:

> Changing
> from 3 disks to 4 disks for the ZODB should in theory only increase
> performance by a 25% as I don't think RAID5 and RAID1+0 would have any
> significant differences in read performance beyond the number of spindles
> you have.

DirectoryStorage (and zodb in general) only issues one read request at a time, 
so there is no good way to make use of that potential concurrency to improve 
read throughput. On zodb-dev we have occasionally discussed an object 
prefetching system that I suspect could make good use of your spindles.

> I'm not sure which part of the changes made the most significant
> difference.

I can share a guess..... 

> Copying the ZODB to another machine and back again is an interesting one.
> I don't see how this would make that much difference to UFS.  IIRC, UFS
> attempts to spread files out evenly across a disk so I don't think it
> could be anything to do with the order of files.

I dont know for sure about UFS, but many filesystems allocate space for inodes 
and file bodies so that files from one directory are nearby on disk.

All DirectoryStorage data files are initially created in one transaction 
directory, so all objects changed in one transaction will have their data 
files nearby on disk. 

They then get renamed into their final resting place, one directory per zodb 
object in the 'bushy' format. But their on-disk layout does not change. It 
retains the grouping based on transactions. The result is that a naturally 
created DirectoryStorage filesystem will have very fragmented directories. 
Thats why 'find' had so much room for improvement.

Your rsync will have effectively defragmented the directories. That improves 
'find', and also the final phase of packing, which operates similar to 'find'

The disadvantage is that you have increased fragmentation of oids that were 
written at the same time. This has the potential to slow down the earlier 
packing phases that traverse the zodb object reference tree. I have seen some 
application benchmarks where it was significant too.

> So we managed to get a 3-fold increase in
> random disk read IO.

It will be interesting to see the level of improvement you see in packing and 
catalog reindexing.



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click