Nathan, There are other factors to consider, blocksize and storage backend being the two most important ones.
I just fired off a quick test with 1 instance of dd on two different LUNs. One gave me 55MB/sec read and 110MB/sec write at 1MB blocksize, the other gave me 250 MB/sec read, 135MB/sec write, again at 1MB blocksize. Since we are discussing the capabilities of dd and LDom virtual disk IO, I'll not elaborate on the storage backends used... But please note the very different behaviour of both. However, this clearly shows that LDom virtual disks when tested with dd, are capable of transfering at least 250MB/sec read, 135MB/sec write at 1MB blocksize. Note that the faster of the two devices delivered less than 40MB/sec at 8k blocksize and only 2.5 MB/sec if dd is started without any blocksize parameter (which means it'll use 512 byte blocks). my 2 cents stefan On 15.06.10 07:49, Nathan Kroenert wrote: > Hi Alex - > > It's all well and good to say that it's not representative of real > workloads, but that's sidestepping the issue completely. > > Doing a DB import or export, for example, is certainly something that > likes fast sequential access. > > Batch workloads that do lots of table scanning like lots of fast > sequential access. > > Lots of workloads require fast sequential access, and as such, dd is a > great tool for such testing. > > Yes - it's not a 100% ACCURATE test case for all workloads, but it's a > perfect example of what needs to happen when you need a single thread to > spew out a lot of data onto disk or ingest it quickly, and I can > certainly think of a few. > > 100MB/s is not fabulous. 40-50 is even worse. I can get 100MB/s from a > single commodity 3..5" 7200rpm SATA spindle - hardly impressive. > > Note that I'm not poo pooing the LDOM capability, or saying that 100MB/s > is all you can get from it. I have certainly had good experiences with > LDOMS etc - I'm saying that just writing dd off as a bad test because > you don't necessarily have a good answer for how to get it faster is a > little weak. > > How's about we consider what it would take to get dd running much faster > so that it becomes a non-issue? > > Or - at least discussing why dd is a worst case, and what folks could do > to help avoid such worst cases. > > Cheers! > > Nathan. > > > > > Alexandre Chartre wrote: >> >> Using dd is not a got way to evaluate performances. dd does sequential >> serialized I/Os, and this is the worst case scenario for vdisk. With real >> applications, most your disk I/Os will be multiple parallel random I/Os >> (done by the filesystem) so this is definitively not what dd is testing. >> >> A better way to test I/Os is to use vdbench, with which you can simulate >> different type of workload. But the best test is to run your >> applications, >> and see how it behaves and if you have unexpected response time. >> >> alex. >> >> On 06/10/10 03:01, Tom Kuther wrote: >>> We have seen the same problem on a T5220, LDOMs 1.3, 8 internal 10k >>> SAS drives and ZFS all around. >>> >>> Even on the ZFS RAID1 ldompool inside the control domain, I couldn't >>> get over 46MB/s with dd testing. Same for the 6-disk RAIDz inside the >>> guest LDOM (exported slice 2 of EFI labeled disk, formed into RAIDZ) >>> >>> I deleted all LDOM configs and rebooted factory-default, same tests >>> reveal around 100MB/s on the same ldompool now, and about 90MB/s for >>> the RAIDZ, >>> >>> So now we end up using zones instead. >>> >>> (Originally posted on sun forums: >>> http://forums.sun.com/thread.jspa?threadID=5441479) >> _______________________________________________ >> ldoms-discuss mailing list >> [email protected] >> http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss > _______________________________________________ > ldoms-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss -- Stefan Hinker Systems LOB - Systems & Performance Sun Microsystems GmbH Tel: +49 6103 752-300 Brandenburger Str. 2-6 [email protected] D-40880 Ratingen http://www.sun.de/ http://blogs.sun.com/cmt http://blogs.sun.com/cmt/en --------------------------------------------------------------------------- Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Jürgen Kunz
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ ldoms-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss
