In the scenario you are describing An ssd should be faster The reason it is not cut and dry is because you are comparing the spare Bandwidth of your array which has possibly many Spindles to the bandwidth of a single device. So it depends on how fast your array is, how much spare bandwidth it has and what is the sustainable write rate of your ssd. There is no guarantee that the ssd will come out on top although in your case it would with the perf fix
::sG:: On Jan 13, 2012, at 6:56 AM, Matt Connolly <matt.connolly...@gmail.com> wrote: > Yes, it is as you guess comparing ZIL on the main pool vs ZIL on an SSD. I > understand that the ZIL on its own is more of an integrity function rather > than a performance boost. > > However, I would have expected some performance boost by using an SSD log > device since writing to the dedicated log device reduces I/O load on the main > pool (or is this wrong?) > > Thanks for the heads up about the bug and pending fix.. I'll take a look. > > -Matt. > > On 13/01/2012, at 9:34 AM, Steve Gonczi <gon...@comcast.net> wrote: > >> Hi Matt, >> >> The ZIL is not a performance enhancer. (This is a common misunderstanding, >> people sometimes view the ZIL as a write cache) . >> >> It is a way to simulate "sync" semantics on files where you really >> need that, instead of the coarser ganularity guarantee that zfs gives >> you without it. (txg level, where the in-progress transaction group may >> roll back if you crash). >> >> If I am reading your post correctly, you are comparing 2 scenarios >> >> 1) Zil is enabled, and goes to the main storage pool >> 2) Zil is enabled but it goes to a dedicated SSD instead. >> Please verify that this is indeed the case. > > Yes, this is the case. > >> You should not expect having an SSD based zil performing better than >> when turning the ZIL off altogether. >> >> The latter of course will have better >> performance, but you have to live with the possibility of losing some data. >> >> Given that the case is (1) and (2), it all depends on how much performance >> headroom your pool has, vs. the write performance of the SSD. >> >> A fast SSD ( e.g.: DRAM based, and preferably dedicated to Zil and not >> split) >> would work best. It does not have to be huge, just large enough to store >> (say) >> 5 seconds worth of your planned peak data inflow. >> >> You need to be aware of a recent performance regression discovered >> pertaining to >> ZIL ( George Wilson has just posted the fix for review on the illumos dev >> list) >> This has been in Illumos for a while, so it is possible, that it is biting >> you. >> >> Steve >> >> ----- Original Message ----- >> Hi, I've installed an SSD drive in my OI machine and have it partitioned >> (sliced) with a main slice to boot from and a smaller slice to use as a >> write cache (ZIL) for our data pool. >> >> I've noticed that for many tasks, using the ZIL actually slows many tasks at >> hand (operation within a qemu-kvm virtual machine, mysql loading importing a >> dump file, etc). I know I bought a cheap SSD to play with so I wasn't >> expected the best performance, but I would have expected some improvement, >> not a slow down. >> >> In one particular test, I have mysql running in a zone and loading a test >> data set takes about 40 seconds without the ZIL and about 60 seconds with >> ZIL. I certainly wasn't expecting a 50% slow down. >> >> Is this to be expected? >> >> Are there any best practices for testing an SSD to see if it will actually >> improve performance of a zfs pool? >> >> >> Thanks, >> Matt >> >> >> _______________________________________________ >> OpenIndiana-discuss mailing list >> OpenIndiana-discuss@openindiana.org >> http://openindiana.org/mailman/listinfo/openindiana-discuss >> _______________________________________________ >> OpenIndiana-discuss mailing list >> OpenIndiana-discuss@openindiana.org >> http://openindiana.org/mailman/listinfo/openindiana-discuss > > _______________________________________________ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss _______________________________________________ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
