[Users] Curious about ploop performance results.
jjs - mainphrame
jjs at mainphrame.com
Sat May 3 14:32:13 PDT 2014
I did some benchmarks on newly created CTs with iozone, and the results
were probably more in line with what you'd expect.
The simfs-based CT was about 5% faster on write, and the ploop-based CT was
about 5% faster on re-write, read, and re-read. The results are repeatable.
Regards,
J J
On Sat, May 3, 2014 at 11:53 AM, jjs - mainphrame <jjs at mainphrame.com>wrote:
> I am continuing to do testing as time allows. Lat night I ran sysbench
> fileio tests, and again, the ploop CT yielded better performance then
> either then simfs CT or the vzhost. It wasn't as drastic a difference as
> the dbench results, but the difference was there. I'll continue in this
> vein with freshly created CTs. The machine was just built a few days ago,
> it's quiescent, it's doing nothing except hosting a few vanilla CTs.
>
> As for the rules of thumb, I can tell you that the results are 100%
> repeatable. But explainable, ah, that's the thing. still working on that.
>
> Regards,
>
> J J
>
>
>
> On Sat, May 3, 2014 at 11:31 AM, Kir Kolyshkin <kir at openvz.org> wrote:
>
>> On 05/02/2014 04:38 PM, jjs - mainphrame wrote:
>>
>> Thanks Kir, the /dev/zero makes sense I suppose. I tried with /dev/random
>> but that blocks pretty quickly - /dev/urandom is better, but still seems to
>> be a bottleneck.
>>
>>
>> You can use a real file on tmpfs.
>>
>> Also, in general, there are very many factors that influence test
>> results. Starting from the cron jobs and other stuff (say, network
>> activity) that runs periodically or sporadically and spoils your results,
>> to the cache state (you need to use vm_drop_caches, or yet better, reboot
>> between tests), to the physical place on disk where your data is placed
>> (rotating hdds tend to be faster at the first sectors compared to the last
>> sectors, so ideally you need to do this on a clean freshly formatted
>> filesystem). There is much more to it, can be some other factors, too. The
>> rule of thumb is results need to be reproducible and explainable.
>>
>> Kir.
>>
>>
>>
>> As for the dbench results, I'd love to hear what results others obtain
>> from the same test, and/or any other testing approaches that would give a
>> more "acceptable" answer.
>>
>> Regards,
>>
>> J J
>>
>>
>>
>> On Fri, May 2, 2014 at 4:01 PM, Kir Kolyshkin <kir at openvz.org> wrote:
>>
>>> On 05/02/2014 03:00 PM, jjs - mainphrame wrote:
>>>
>>> Just for kicks, here are the data from the tests. (these were run on a
>>> rather modest old machine)
>>>
>>>
>>>
>>> Here are the raw dbench data:
>>>
>>>
>>> #clients vzhost simfs CT ploop CT
>>> ---------------------------------------------------------------------
>>> 1 11.1297MB/sec 9.96657MB/sec 19.7214MB/sec
>>> 2 12.2936MB/sec 14.3138MB/sec 23.5628MB/sec
>>> 4 17.8909MB/sec 16.0859MB/sec 45.1936MB/sec
>>> 8 25.8332MB/sec 22.9195MB/sec 84.2607MB/sec
>>> 16 32.1436MB/sec 28.921MB/sec 155.207MB/sec
>>> 32 35.5809MB/sec 32.1429MB/sec 206.571MB/sec
>>> 64 34.3609MB/sec 29.9307MB/sec 221.119MB/sec
>>>
>>>
>>> Well, I can't explain this, but there's probably something wrong with
>>> the test.
>>>
>>>
>>>
>>> Here is the script used to invoke dbench:
>>>
>>> HOST=`uname -n`
>>> WD=/tmp
>>> FILE=/usr/share/dbench/client.txt
>>>
>>> for i in 1 2 4 8 16 32 64
>>> do
>>> dbench -D $WD -c $FILE $i &>dbench-${HOST}-${i}
>>> done
>>>
>>> Here are the dd commands and outputs:
>>>
>>> OPENVZ HOST
>>> ----------------
>>> [root at vzhost ~]# dd bs=1M count=512 if=/dev/zero of=test conv=fdatasync
>>> 512+0 records in
>>> 512+0 records out
>>> 536870912 bytes (537 MB) copied, 11.813 s, 45.4 MB/s
>>> [root at vzhost ~]# df -T
>>> Filesystem Type 1K-blocks Used Available Use% Mounted on
>>> /dev/sda2 ext4 20642428 2390620 17203232 13% /
>>> tmpfs tmpfs 952008 0 952008 0% /dev/shm
>>> /dev/sda1 ext2 482922 68436 389552 15% /boot
>>> /dev/sda4 ext4 51633780 3631524 45379332 8% /local
>>> [root at vzhost ~]#
>>>
>>>
>>> PLOOP CT
>>> ----------------
>>> root at vz101:~# dd bs=1M count=512 if=/dev/zero of=test conv=fdatasync
>>> 512+0 records in
>>> 512+0 records out
>>> 536870912 bytes (537 MB) copied, 2.50071 s, 215 MB/s
>>>
>>>
>>> This one I can explain :)
>>>
>>> This is caused by ploop optimization that was enabled in the kernel
>>> recently.
>>> If data block is all zeroes, it is not written to the disk (same thing
>>> as sparse files,
>>> just for ploop).
>>>
>>> So you need to test it with some real data (anything but not all zeroes).
>>> I am not sure how fast is /dev/urandom but this is one of the options.
>>>
>>>
>>> root at vz101:~# df -T
>>> Filesystem Type 1K-blocks Used Available Use% Mounted on
>>> /dev/ploop11054p1 ext4 4539600 1529316 2804928 36% /
>>> none devtmpfs 262144 4 262140 1% /dev
>>> none tmpfs 52432 52 52380 1% /run
>>> none tmpfs 5120 0 5120 0% /run/lock
>>> none tmpfs 262144 0 262144 0% /run/shm
>>> root at vz101:~#
>>>
>>>
>>> SIMFS CT
>>> ----------------
>>> root at vz102:~# dd bs=1M count=512 if=/dev/zero of=test conv=fdatasync
>>> 512+0 records in
>>> 512+0 records out
>>> 536870912 bytes (537 MB) copied, 12.6913 s, 42.3 MB/s
>>> root at vz102:~# df -T
>>> Filesystem Type 1K-blocks Used Available Use% Mounted on
>>> /dev/simfs simfs 4194304 1365500 2828804 33% /
>>> none devtmpfs 262144 4 262140 1% /dev
>>> none tmpfs 52432 52 52380 1% /run
>>> none tmpfs 5120 0 5120 0% /run/lock
>>> none tmpfs 262144 0 262144 0% /run/shm
>>> root at vz102:~#
>>>
>>> Regards,
>>>
>>> J J
>>>
>>>
>>>
>>>
>>> On Fri, May 2, 2014 at 2:10 PM, jjs - mainphrame <jjs at mainphrame.com>wrote:
>>>
>>>> You know the saying, "when something seems too good to be true"...
>>>>
>>>> I just installed centos 6.5 and openvz on an older machine, and when
>>>> I built an ubuntu 12.04 CT I noticed that ploop is now the default layout.
>>>> Cool. So I built another ubuntu12.04 CT, identical in every way except that
>>>> I specified smifs, so I could do a quick performance comparison.
>>>>
>>>> First I did a quick timed dd run, then I ran dbench with varying
>>>> numbers of clients.
>>>>
>>>> The simfs CT showed performance roughly similar to the host, which
>>>> was not too surprising.
>>>> What did surprise me was that the ploop CT showed performance which was
>>>> significantly better than the host, in both the dd test and the dbench
>>>> tests.
>>>>
>>>> I know someone will tell me "dbench is a terrible benchmark" but it's
>>>> also a standard. Of course, if anyone knows a "better" benchmark, I'd love
>>>> to try it.
>>>>
>>>> Regards,
>>>>
>>>> J J
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing listUsers at openvz.orghttps://lists.openvz.org/mailman/listinfo/users
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at openvz.org
>>> https://lists.openvz.org/mailman/listinfo/users
>>>
>>>
>>
>>
>> _______________________________________________
>> Users mailing listUsers at openvz.orghttps://lists.openvz.org/mailman/listinfo/users
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20140503/384e3156/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 13158 bytes
Desc: not available
URL: <http://lists.openvz.org/pipermail/users/attachments/20140503/384e3156/attachment-0001.png>
More information about the Users
mailing list