[email protected]
[Top] [All Lists]

Re: [zfs-discuss] fdsync(5, FSYNC) problem and ZFS

Subject: Re: [zfs-discuss] fdsync(5, FSYNC) problem and ZFS
From: Neil Perrin
Date: Tue, 20 Jun 2006 14:05:22 -0600

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.


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

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.


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.)

zfs-discuss mailing list
[email protected]

<http://www.sun.com>      * Sean Meighan *
Mgr ITSM Engineering

*Sun Microsystems, Inc.*
Phone x32329 / +1 408 850-9537
Mobile 303-520-2024
Fax 408 850-9537
Email [email protected]

[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
[email protected]


zfs-discuss mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>