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
