im playing around with a home raidz2 install and i can see this pulsing as well.
The only difference is i have 6 ext usb drives with activity lights on them so
i can see whats actually being written to the disk and when :)
What i see is about 8 second pauses while data is being sent over the
True, this setup is not designed for high random I/O, but rather lots of
storage with fair performance. This box is for our dev/test backend storage.
Our production VI runs in the 500-700 IOPS (80+ VMs, production plus dev/test)
on average, so for our development VI, we are expecting half of
100% random writes produce around 200 IOPS with a 4-6 second pause
around every 10 seconds.
This indicates that the bandwidth you're able to transfer
through the protocol is about 50% greater than the bandwidth
the pool can offer to ZFS. Since, this is is not sustainable, you
Roch Bourbonnais Wrote:
100% random writes produce around 200 IOPS with a 4-6 second pause
around every 10 seconds.
This indicates that the bandwidth you're able to transfer
through the protocol is about 50% greater than the bandwidth
the pool can offer to ZFS. Since, this is is not sustainable,
On 09/04/09 09:54, Scott Meilicke wrote:
Roch Bourbonnais Wrote:
100% random writes produce around 200 IOPS with a 4-6 second pause
around every 10 seconds.
This indicates that the bandwidth you're able to transfer
through the protocol is about 50% greater than the bandwidth
the pool
Scott Meilicke wrote:
So what happens during the txg commit?
For example, if the ZIL is a separate device, SSD for this example, does it
not work like:
1. A sync operation commits the data to the SSD
2. A txg commit happens, and the data from the SSD are written to the
spinning disk
So what happens during the txg commit?
For example, if the ZIL is a separate device, SSD for this example, does it not
work like:
1. A sync operation commits the data to the SSD
2. A txg commit happens, and the data from the SSD are written to the spinning
disk
So this is two writes, correct?
Doh! I knew that, but then forgot...
So, for the case of no separate device for the ZIL, the ZIL lives on the disk
pool. In which case, the data are written to the pool twice during a sync:
1. To the ZIL (on disk)
2. From RAM to disk during tgx
If this is correct (and my history in this
On Fri, 4 Sep 2009, Scott Meilicke wrote:
So what happens during the txg commit?
For example, if the ZIL is a separate device, SSD for this example, does it not
work like:
1. A sync operation commits the data to the SSD
2. A txg commit happens, and the data from the SSD are written to the
So, I just re-read the thread, and you can forget my last post. I had thought
the argument was that the data were not being written to disk twice (assuming
no separate device for the ZIL), but it was just explaining to me that the data
are not read from the ZIL to disk, but rather from memory
Scott Meilicke wrote:
I am still not buying it :) I need to research this to satisfy myself.
I can understand that the writes come from memory to disk during a txg write
for async, and that is the behavior I see in testing.
But for sync, data must be committed, and a SSD/ZIL makes that faster
On Sep 4, 2009, at 2:22 PM, Scott Meilicke scott.meili...@craneaerospace.com
wrote:
So, I just re-read the thread, and you can forget my last post. I
had thought the argument was that the data were not being written to
disk twice (assuming no separate device for the ZIL), but it was
just
Yes, I was getting confused. Thanks to you (and everyone else) for clarifying.
Sync or async, I see the txg flushing to disk starve read IO.
Scott
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
On Sep 4, 2009, at 4:33 PM, Scott Meilicke scott.meili...@craneaerospace.com
wrote:
Yes, I was getting confused. Thanks to you (and everyone else) for
clarifying.
Sync or async, I see the txg flushing to disk starve read IO.
Well try the kernel setting and see how it helps.
Honestly
I only see the blocking while load testing, not during regular usage, so I am
not so worried. I will try the kernel settings to see if that helps if/when I
see the issue in production.
For what it is worth, here is the pattern I see when load testing NFS (iometer,
60% random, 65% read, 8k
On Fri, 4 Sep 2009, Scott Meilicke wrote:
I only see the blocking while load testing, not during regular
usage, so I am not so worried. I will try the kernel settings to see
if that helps if/when I see the issue in production.
The flipside of the pulsing is that the deferred writes dimish
On Sep 4, 2009, at 6:33 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us
wrote:
On Fri, 4 Sep 2009, Scott Meilicke wrote:
I only see the blocking while load testing, not during regular
usage, so I am not so worried. I will try the kernel settings to
see if that helps if/when I see the
On Sep 4, 2009, at 5:25 PM, Scott Meilicke scott.meili...@craneaerospace.com
wrote:
I only see the blocking while load testing, not during regular
usage, so I am not so worried. I will try the kernel settings to see
if that helps if/when I see the issue in production.
For what it is
On Fri, 4 Sep 2009, Ross Walker wrote:
I guess one can find a silver lining in any grey cloud, but for myself I'd
just rather see a more linear approach to writes. Anyway I have never seen
any reads happen during these write flushes.
I have yet to see a read happen during the write flush
On Sep 4, 2009, at 8:59 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us
wrote:
On Fri, 4 Sep 2009, Ross Walker wrote:
I guess one can find a silver lining in any grey cloud, but for
myself I'd just rather see a more linear approach to writes. Anyway
I have never seen any reads happen
On Fri, 4 Sep 2009, Ross Walker wrote:
I have yet to see a read happen during the write flush either. That
impacts my application since it needs to read in order to proceed, and it
does a similar amount of writes as it does reads.
The ARC makes it hard to tell if they are satisfied from
On Sep 4, 2009, at 21:44, Ross Walker wrote:
Though I have only heard good comments from my ESX admins since
moving the VMs off iSCSI and on to ZFS over NFS, so it can't be that
bad.
What's your pool configuration? Striped mirrors? RAID-Z with SSDs?
Other?
On Sep 4, 2009, at 10:02 PM, David Magda dma...@ee.ryerson.ca wrote:
On Sep 4, 2009, at 21:44, Ross Walker wrote:
Though I have only heard good comments from my ESX admins since
moving the VMs off iSCSI and on to ZFS over NFS, so it can't be
that bad.
What's your pool configuration?
Hi,
happens on opensolaris build 101b and 111b.
Arc cache max set to 6GB, joined to a windows 2003 r2 ad domain. With a pool of
4 15Krpm drives in a 2 way mirror.
The bnx driver has been changed to have offloading enabled.
Not much else has been changed.
Ok, so when the chache fills and needs
Ok,
so by limiting the write cache to that of the controller you were able to
remove the pauses?
How id that affect your overall write performance, if at all?
thanks I will give that ago.
David
--
This message posted from opensolaris.org
___
I dont have any windows machine connected to it over iscsi (yet).
My reference to the windows servers was, having the same hapdware running
windows and its read writes not having these problems, so it isnt hardware
causing it.
But when I do eventually get iscsi going I will send a message if i
On Sat, 29 Aug 2009, David Bond wrote:
Ok, so when the chache fills and needs to be flushed, when the flush
occurs it locks access to it, so no read? or writes can occur from
cache, and as everything will go through the arc, nothing can happen
until the arc has finished its flush.
It has
Hi,
I was directed here after posting in CIFS discuss (as i first thought that it
could be a CIFS problem).
I posted the following in CIFS:
When using iometer from windows to the file share on opensolaris svn101 and
svn111 I get pauses every 5 seconds of around 5 seconds (maybe a little less)
On Aug 27, 2009, at 4:30 AM, David Bond david.b...@tag.no wrote:
Hi,
I was directed here after posting in CIFS discuss (as i first
thought that it could be a CIFS problem).
I posted the following in CIFS:
When using iometer from windows to the file share on opensolaris
svn101 and svn111
On Thu, 27 Aug 2009, David Bond wrote:
I just noticed that if the server hasnt hit its target arc size, the
pauses are for maybe .5 seconds, but as soon as it hits its arc
target, the iops drop to around 50% of what it was and then there
are the longer pauses around 4-5 seconds. and then
Hi David,
Just wanted to ask you, how your windows server behaves during these pauses?
Are there any clients, connected to it?
The issue you've described might be related to one I saw on my server, see here:
http://www.opensolaris.org/jive/thread.jspa?threadID=110013tstart=0
I just wonder how
Ross Walker wrote:
On Aug 27, 2009, at 4:30 AM, David Bond david.b...@tag.no wrote:
Hi,
I was directed here after posting in CIFS discuss (as i first
thought that it could be a CIFS problem).
I posted the following in CIFS:
When using iometer from windows to the file share on
I saw similar behavior when I was running under the kernel debugger (-k
switch the the kernel). It largely went away when I went back to normal.
T
David Bond wrote:
Hi,
I was directed here after posting in CIFS discuss (as i first thought that it
could be a CIFS problem).
I posted the
On Aug 27, 2009, at 11:29 AM, Bob Friesenhahn bfrie...@simple.dallas.tx.us
wrote:
On Thu, 27 Aug 2009, David Bond wrote:
I just noticed that if the server hasnt hit its target arc size,
the pauses are for maybe .5 seconds, but as soon as it hits its arc
target, the iops drop to around
34 matches
Mail list logo
