Security Notification
#2 — parallel bandwidth
| State | Postponed |
|---|---|
| Version: | 0.6.0 |
| Area | Functionality |
| Issue type | Bug |
| Severity | Low |
| Submitted by | (anonymous) |
| Submitted on | Oct 27, 2009 |
| Responsible | Seth Heeren |
| Target release: | 0.6.9 |
Last modified on
May 22, 2010
by
Seth Heeren
Se details below.
Benchmarking different filesystems like below. ZFS0.6b comes out on top (!), with XFS as second, when n=10. When n=40, as below, data is streamed from RAIDset at around 160MB/s (using iostat) which is great (XFS=140MB/s), but the reads "never" finish or are very slow. CPU peaks at 100% at times which could be a reason.
Benchmarking different filesystems like below. ZFS0.6b comes out on top (!), with XFS as second, when n=10. When n=40, as below, data is streamed from RAIDset at around 160MB/s (using iostat) which is great (XFS=140MB/s), but the reads "never" finish or are very slow. CPU peaks at 100% at times which could be a reason.
- Steps to reproduce:
- #Create files
n=40
while [ $n -gt 0 ]; do
echo $n
dd if=/dev/zero of=/mnt/data/$n bs=1M count=100
n=$((n-1))
done
#Run simple benchmark
echo 3 > /proc/sys/vm/drop_caches
n=40
while [ $n -gt 0 ]; do
echo $n
dd of=/dev/null if=/mnt/data/$n bs=3M &
n=$((n-1))
done
wait
Added by
(anonymous)
on
Dec 06, 2009 05:47 PM
How does the write bandwidth compare with XFS while initially creating the files with n=10?
Added by
(anonymous)
on
Dec 06, 2009 05:51 PM
Creating the files in the benchmark above is done sequentially, not in parallel, so n doesn't really matter. Didn't do any parallel write benchmarks and the configuration has been taken down since so sorry, can't say.
Added by
Emmanuel Anne
on
Dec 10, 2009 07:56 AM
The read finish correctly for me, master branch :
http://rainemu.swishparty.co.uk/[…]/gitweb.cgi?p=zfs;a=summary
I just created 40 files of 10 Mb instead of 100 Mb because I did it on a 1Gb test partition (created for another test with :
zpool create -f vmstg mirror /dev/sda9 /dev/sda10 cache /dev/sda4
then creation :
n=40; while [ $n -gt 0 ]; do echo $n; dd if=/dev/zero of=$n bs=1M count=10; n=$((n-1)); done
echo 3 > /proc/sys/vm/drop_caches
reads :
n=40; while [ $n -gt 0 ]; do echo $n; dd of=/dev/null if=$n bs=3M & n=$((n-1)); done; wait
no problem. Notice : a parrallel benchmark would give interesting results only if using a controller which can handle at least 2 disks in parrallel and having 2 cores at least. I tested on a single core cpu, not very interesting, but it works.
http://rainemu.swishparty.co.uk/[…]/gitweb.cgi?p=zfs;a=summary
I just created 40 files of 10 Mb instead of 100 Mb because I did it on a 1Gb test partition (created for another test with :
zpool create -f vmstg mirror /dev/sda9 /dev/sda10 cache /dev/sda4
then creation :
n=40; while [ $n -gt 0 ]; do echo $n; dd if=/dev/zero of=$n bs=1M count=10; n=$((n-1)); done
echo 3 > /proc/sys/vm/drop_caches
reads :
n=40; while [ $n -gt 0 ]; do echo $n; dd of=/dev/null if=$n bs=3M & n=$((n-1)); done; wait
no problem. Notice : a parrallel benchmark would give interesting results only if using a controller which can handle at least 2 disks in parrallel and having 2 cores at least. I tested on a single core cpu, not very interesting, but it works.
Added by
Seth Heeren
on
Jan 25, 2010 06:19 PM
The statement "never completes" triggers the idea that you may have hit a locking problem. You might be interested in the fixes available for issue #22 (branch available)
This is especially recommended, since
* in my experience, read speeds in zfs-fuse are very good (write speeds are the sad factor)
* you explicitely mention _parallel_ reads which matches the problem description (failing under load).
YMMV,let me know if there is any progress/questions
This is especially recommended, since
* in my experience, read speeds in zfs-fuse are very good (write speeds are the sad factor)
* you explicitely mention _parallel_ reads which matches the problem description (failing under load).
YMMV,let me know if there is any progress/questions
Added by
Seth Heeren
on
May 22, 2010 01:54 PM
Issue state:
unconfirmed → postponed
Severity:
Medium → Low
Target release:
None → 0.6.9
Responsible manager:
(UNASSIGNED) → sgheeren
we might re-assess performance in general for 0.6.9
sent out a request on the list
sent out a request on the list
