Gaëtan Lehmann wrote:
Le 7 juil. 09 à 15:21, Darren J Moffat a écrit :
Gaëtan Lehmann wrote:
There will be two kinds of transfer protocol, once in production -
CIFS and one specific to the application.
But for a quick test, the test was made with scp.
CIFS and scp are very different protocols with very different
performance characteristics.
Also really important is what the data access pattern is ? Is it
read mostly or write mostly ? Are the files that are written
accessed for read soon ? Is it sequential or random reads ?
It is read mostly. Files are usually rarely accessed, but are likely
to be accessed several times when they begin to be accessed. This is
sequential read.
The data set is transfered on the server, and the files are not
modified after that (or very rarely). The whole data set is
transfered at once.
What is "good" by your definition ?
The data set is transfered in a little less than 3 minutes without
compression - that's good!
With compression, the data set is transfered in 15 minutes. I was
hopping that a disk write cache can keep the transfer speed close to
the 3 minutes obtained without compression.
That is a big difference and without seeing data my initial thought is
that the system appears to be CPU bound, particularly if the only
difference really was a compressed ZFS dataset versus an uncompressed
one.
Is "transfer" in this case a read from the server or a write to it ?
It is a write to the server. The server is cpu bound, because of the
compression.
My workload is very simple: the user copy approximately 10GB of data
on the server, and then only read it from time to time.
During the copy on the server, the transfer is cpu bounded, and there
is a lot of cpu time available when there is no copy to the server.
Are you talking here about the server's CPU or the clients ?
I'm talking about the server's cpu. Client is not cpu bounded by scp.
> Using a
disk to store the uncompressed data, as I guess it is done by the
memory cache, may have helped.
I thought the ZIL may have played this role.
I think you are maybe confusing the ZIL and the L2ARC.
I think L2ARC is for reading data - I'd like an L2ARC for writing data.
Correct the L2ARC is for reads.
I think actually what you want is not a cache at all but not to be CPU
bound by gzip-6.
What compression algorithm are you using ? The default "on" value of
lzjb or are you doing something like gzip-9 ?
gzip-6. There is no speed problem with lzjb, but also not the same
compression ratio :-)
What build of OpenSolaris are you running ?
The fix for "6812655 need larger kmem caches for newer workloads" might
help but you need to be running build 114 or higher which means you need
to be using the pkg.opensolaris.org/dev repository not the /release one.
It could also be "6586537 async zio taskqs can block out userland
commands" which is fixed in 115 and was the "real" fix.
This is guess work though since I haven't seen perf data from your
particular system.
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
