Re: vxfs snapshot overhead ? (345 Views)
Reply
Honored Contributor
Leif Halvarsson_2
Posts: 6,682
Registered: ‎01-09-2002
Message 1 of 4 (345 Views)

vxfs snapshot overhead ?

Hi,

Is there any overhed when accessing files from an vxfs snapshot (compared to accessing from the "original" filesystem).

We have some strange performance problems showing a very high "wio" when running a dbcheck from a snapshot.

(rx2660, HP-UX 11.23, application is "clearcase")





Exalted Contributor
Steven E. Protter
Posts: 33,806
Registered: ‎08-15-2002
Message 2 of 4 (345 Views)

Re: vxfs snapshot overhead ?

Shalom,

If the dbcheck involves writes to the snapshot filesystem the situation is expected.

clearcase is something I work with on Linux and HP-UX and it can be quite troublesome and at times I/O intensive.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
Honored Contributor
Leif Halvarsson_2
Posts: 6,682
Registered: ‎01-09-2002
Message 3 of 4 (345 Views)

Re: vxfs snapshot overhead ?

Hi,

Thank you for your reply.

Do you run any dbcheck on the clearcase database ?

On snapshot filesystem ?

Have you checked the load on the system when dbcheck is running (using e.g. sar or glance) ?

In our case, most of the time dbcheck is running, "usr" and "sys" activity is only a few %, rest is "wio". Somtimes, almost all the load is "wio". At that time, some copy operations seems to happen.

Example:

cp -Rp /backup/wds_swt.vbs/db /tempo/db_checklog/db_copy

(/backup is a snapshot filesystem)

Know very little about clercase myself. I have only been asked to have a look at the performance issue of the server.





Acclaimed Contributor
A. Clay Stephenson
Posts: 17,825
Registered: ‎07-16-1998
Message 4 of 4 (345 Views)

Re: vxfs snapshot overhead ?

Bear in mind that a snapshot is read-only so that talking about writes on a snapshot is a non sequiter. In most cases, the snapshot overhead is small and hardly noticeable. The exception to that is a very write intensive original filesystem. Just before a given block is write()'en to (FOR ONLY THE FIRST TIME SINCE THE SNAPSHOT BEGAN), the OS must first write the original contents of the block to the snapshot buffer device and then write() to the original filesystem block. This means that each write() is often translated to two write()'s. When read()'s occur on the snapshot, the change map is consulted to see if that block has been altered, if not, it is read() from the original filesystem otherwise it is read from the snapshot buffer. One of the things that does choke down a filesystem when doing sequential reads is if the mount options mincache=direct,convosync=direct.
If it ain't broke, I can fix that.
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.