Date: Sun, 28 Nov 2004 11:29:19 -0500 From: Paul Mather <paul@gromit.dlib.vt.edu> To: Tomas Zvala <tomas@zvala.cz> Cc: freebsd-geom@freebsd.org Subject: Re: geom_mirror performance issues Message-ID: <41A9FCDF.3070709@gromit.dlib.vt.edu> In-Reply-To: <41A9C110.9050205@zvala.cz> References: <41A9C110.9050205@zvala.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
Tomas Zvala wrote: > Hello, > I've been playing with geom_mirror for a while now and few issues > came up to my mind. > a) I have two identical drives (Seagate 120GB SATA 8MB Cache > 7.2krpm) that are able to sequentialy read at 58MB/s at the same time > (about 115MB/s throughput). But when I have them in geom_mirror I get > 30MB/s at best. Thats about 60MB/s for the mirror (about half the > potential). The throughput is almost the same for both 'split' and > 'load' balancing algorithms altough with load algorithm it seems that > all the reading is being done from just one drive. When I did similar geom_mirror tests (dd'ing large files), I noticed with the 'load' balance algorithm that both drives of my mirror were in fact used, but not simultaneously. One drive would be used exclusively for a few seconds, and then it would switch over to use the other drive for a few seconds, and then back again. I attributed this behaviour to perhaps that the 'load' statistics in GEOM were only being updated relatively infrequently (to minimise performance impact), although I don't know if this is the case. The odd thing is that the overall throughput of 'load' was the second-highest of all the balancing algorithms I tried, coming just a little behind the 'split' balance algorithm. (Mind you, this was on a 300 MHz Pentium II system, where the CPU overheads of a transaction are more significant than a GHz-level system.) > d) When I use round-robin algorithm the performance halves (i get > about 20MB/s raw throughput). Why is this? I would expect round-robin > algorithm to be the most effective one for reading as every drive gets > exactly half the load. My speculation is that perhaps relative drive head positions might deviate more under 'round-robin' leading to more time lost seeking (which is the dominant cost in disk I/O). I also found 'round-robin' to be relatively slow compared to 'load' and 'split.' Cheers, Paul.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41A9FCDF.3070709>