[Gluster-users] How to evaluate the glusterfs performance with small file workload?

[Torbjørn Thorsen]

On Mon, Mar 18, 2013 at 11:27 AM, nlxswig <nlxswig at 126.com> wrote:
> Hi guys
>     1: What kind of benchmark should I use to test the small file operation
> ?

I've been wondering a bit about the same thing.
I was thinking it would be nice to have something record and
synthesize IO patterns.
One could record a process which does a lot of handling of small
files, for example Dovecot,
and be able to replay those IO patterns on top of any filesystem.

A quick look around revealed ioreplay[1].
It seems to work by replaying strace output, which is cool idea.
I haven't tried it, but it looks to be a nice testing tool.

[1]: https://code.google.com/p/ioapps/wiki/ioreplay

>     4: From the glusterfs document, I get that in order to avoid the cache
> coherency there is no write cache feature.
>
>         Does it mean that there is no inference of memory cache for small
> file write performance of glusterfs?
>
>         So, when we testing glusterfs with:
>
>         "dd if=/dev/zero of=test.img bs=10k count=1 oflag=direct" and
>
>         "dd if=/dev/zero of=test.img bs=10k count=1"
>
>         These two commands should get the same write performance.
>
>         While when I do this, the results of these two commands are not same
> each other. and the gap is big.
>
>         How to explain?

My impression is that there are write caching features,
but Gluster tries hard to maintain coherency and correctness regarding writes.
For one type of cache, see the write-behind translator that is enabled
by default.

AFAIK, the difference between the to dd invocations is that the first
one disables
all caches, while the last one doesn't even wait for the sync before finishing.
My understanding leads me to say that the first one can't use cache at all,
while the second one uses all the cache there is.

Try to run the last one with "conv=fsync".
This will sync the file at the end of writing, ensuring that when dd
returns the data should be on disk. This will probably even out the
run time for the two invocations.



--
Vennlig hilsen
Torbjørn Thorsen
Utvikler / driftstekniker

Trollweb Solutions AS
- Professional Magento Partner
www.trollweb.no

Telefon dagtid: +47 51215300
Telefon kveld/helg: For kunder med Serviceavtale

Besøksadresse: Luramyrveien 40, 4313 Sandnes
Postadresse: Maurholen 57, 4316 Sandnes

Husk at alle våre standard-vilkår alltid er gjeldende