Sean,
I'm not sure yet that the bugs below are responsible for this,
but I don't know what is either.
15 minutes to do a fdsync is way outside the slowdown usually seen.
The footprint for 6413510 is that when a huge amount of
data is being written non synchronously and a fsync comes in for the
same filesystem then all the non-synchronous data is also forced out
synchronously. So is there a lot of data being written during the vi?
Also you say "Everything has been working perfectly until two days ago,
now it can take 10 minutes to exit from vi". So what happened two days ago?
Finally I would not recommend disabling logging. That switch was only intended
for internal use. Applications that rely on POSIX synchronous semantics will
not get what they asked for.
Neil.
Sean Meighan wrote On 06/19/06 17:48,:
ZFS engineering got back to us today and said the following:
In addition to 6404018 there are couple of other performance bottle necks :
6413510 zfs: writing to ZFS filesystem slows down fsync() on other files
in the same FS
6429205 each zpool needs to monitor it's throughput and throttle heavy
writers
joining together and causing the slowdown in this system itsm-mpk-2.sfbay.
6404018/6413510 is caused because of the way the ZFS logging records are
handled. Disabling ZFS logging (add 'set zfs:zil_disable=1' to
/etc/system) might give you a relief from the 'vi' slowdown problem.
6429205 is more lively to hit hard machines with lots of memory, CPUs
and a weak storage. Which is true in this case. One disk is not able to
handle the IO load generated by the 32 virtual CPUs. As a workaround can
you try adding one or two disks to distribute the load.
Yes. There is no fix/patch for these BUGs yet. We would recommend to try
the workarounds till there is a fix available for these BUGs.
what is the downside of disabling loggin records? this is a production
machine and we are now affecting a fairly large population.
thanks
sean
Daniel Rock wrote:
Sean Meighan schrieb:
The box runs less than 20% load. Everything has been working
perfectly until two days ago, now it can take 10 minutes to exit from
vi. The following truss shows that the 3 line file that is sitting on
the ZFS volume (/archives) took almost 15 minutes in fdsync.
/me have similar observations. With virtual no other activity on the
box exiting from vi (:wq) sometimes takes 10-60 seconds. Trussing the
process always shows vi is waiting in fdsync(). This happened on at
least two different machines:
- Sun E3500 with ZFS on A5200 disks (snv_37, almost all of the time large
delay (10-60 secs.) when exiting from vi)
- Solaris/amd64 with ZFS on SATA disks (snv_39, but only few delays,
usually
not longer than 10 secs.)
Daniel
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
--
<http://www.sun.com> * Sean Meighan *
Mgr ITSM Engineering
*Sun Microsystems, Inc.*
US
Phone x32329 / +1 408 850-9537
Mobile 303-520-2024
Fax 408 850-9537
Email [EMAIL PROTECTED]
------------------------------------------------------------------------
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
--
Neil
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
