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 net
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 tha
On Sep 4, 2009, at 10:02 PM, David Magda 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? Striped mirrors? RAID-Z w
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 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 cac
On Sep 4, 2009, at 8:59 PM, Bob Friesenhahn > 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 during these write flushes.
I
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 eit
On Sep 4, 2009, at 5:25 PM, 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.
For what it is worth, here is the pattern I see when l
On Sep 4, 2009, at 6:33 PM, Bob Friesenhahn > 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 issue in production.
The flips
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
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 chun
On Sep 4, 2009, at 4:33 PM, Scott Meilicke > 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 though if you can say it's all sync wr
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
http
On Sep 4, 2009, at 2:22 PM, Scott Meilicke > 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 explaining to me that the data are
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
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 to
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 thread
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
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 because
you are writing
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 spi
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?
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 po
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 sustainabl
"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
s
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 no
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
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
___
zfs-dis
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 t
On Aug 27, 2009, at 11:29 AM, Bob Friesenhahn > 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 50% of what it was and then the
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 fol
Ross Walker wrote:
On Aug 27, 2009, at 4:30 AM, 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 following in CIFS:
When using iometer from windows to the file share on opensolaris
svn101 and svn
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=110013&tstart=0
I just wonder how
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 afte
On Aug 27, 2009, at 4:30 AM, 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 following in CIFS:
When using iometer from windows to the file share on opensolaris
svn101 and svn111 I get pauses ever
34 matches
Mail list logo