I/O performance dip following Solaris/VxFS/VxVm upgrade to 9/4.1MP1

Hi,



I've recently upgraded VxVM / VxFS in my environment from 3.2 / 3.4 to
4.1 MP1.

We also necessarily upgraded Solaris 8 to Solaris 9 in the same
exercise. I did

both through brand new installation rather than upgrading old software
and both are

fully patched from last month's Sun Gold CD.



root@ myhost # pkginfo -l VRTSvxfs

PKGINST: VRTSvxfs

NAME: VERITAS File System

CATEGORY: system,utilities

ARCH: sparc

VERSION: 4.1,REV=4.1B18_sol_GA_s10b74L2a

BASEDIR: /

VENDOR: VERITAS Software

DESC: Commercial File System

PSTAMP: VERITAS-FS-4.1.1.0-2005-09-30-4.1MP1=119301-02

INSTDATE: Sep 18 2006 20:36

HOTLINE: (800) 342-0652

EMAIL: support@xxxxxxxxxxx

STATUS: completely installed

FILES: 234 installed pathnames

32 shared pathnames

6 linked files

47 directories

76 executables

5 setuid/setgid executables

58086 blocks used (approx)



root@ myhost # pkginfo -l VRTSvxvm

PKGINST: VRTSvxvm

NAME: VERITAS Volume Manager, Binaries

CATEGORY: system

ARCH: sparc

VERSION: 4.1,REV=02.17.2005.21.28

BASEDIR: /

VENDOR: VERITAS Software

DESC: Virtual Disk Subsystem

PSTAMP: VERITAS-4.1_p3.1:2005-10-24

INSTDATE: Sep 18 2006 20:23

HOTLINE: 800-342-0652

EMAIL: support@xxxxxxxxxxx

STATUS: completely installed

FILES: 828 installed pathnames

23 shared pathnames

18 linked files

98 directories

413 executables

294561 blocks used (approx)



root@myhost #



root@ myhost # uname -a

SunOS myhost 5.9 Generic_118558-28 sun4u sparc SUNW,Sun-Fire

root@myhost #



We have found severe performance degradation when copying large amounts
of data

between VxVM controlled VXFS filesystems: Formerly copying 90Gb took
about 1

hour but it now takes about 3 hours between the same filesystems. I
have also proven

that I can copy outwith Vx control between UFS filesystems in about one
half of the

time taken to copy between VxVM controlled VXFS filesystems. I have not
upgraded

the disk groups from their original version (90) to the latest version
(120?) or disks from

version 2.2, and I suspect that may have _something to do with our
problem.



root@myhost # vxdg list mydg

Group: mydg

dgid: 1022708368.1258.myhost

import-id: 1024.104

flags:

version: 90

alignment: 512 (bytes)

ssb: off

detach-policy: global

dg-fail-policy: invalid

copies: nconfig=default nlog=default

config: seqno=0.4714 permlen=1486 free=1442 templen=29 loglen=225

[snip]



root@myhost # vxdisk list Disk_13

Device: Disk_13

devicetag: Disk_13

type: auto

hostid: myhost

disk: name= id=1068375953.1534.gla1c102

group: name=movextest id=1068375404.1528.gla1c102

info: format=sliced,privoffset=1,pubslice=4,privslice=3

flags: online ready private autoconfig autoimport

pubpaths: block=/dev/vx/dmp/Disk_13s4 char=/dev/vx/rdmp/Disk_13s4

privpaths: block=/dev/vx/dmp/Disk_13s3 char=/dev/vx/rdmp/Disk_13s3

version: 2.2

iosize: min=512 (bytes) max=2048 (blocks)

public: slice=4 offset=0 len=75489280 disk_offset=4096

private: slice=3 offset=1 len=2047 disk_offset=0

update: time=1159263160 seqno=0.467

ssb: actual_seqno=0.0

headers: 0 248

configs: count=1 len=1486

logs: count=1 len=225

Defined regions:

config priv 000017-000247[000231]: copy=01 offset=000000 enabled

config priv 000249-001503[001255]: copy=01 offset=000231 enabled

log priv 001504-001728[000225]: copy=01 offset=000000 enabled

Multipathing information:

numpaths: 1

c6t2900006022mypath30303135d0s2 state=enabled

root@myhost #



Veritas Support are on the case and I'm testing everything I can think
of, but I would

appreciate any information that anyone can provide in terms of
experience or advice on

this upgrade and, most importantly, the potential root cause of our
problem.



I already understand that root causing performance problems can be a
tricky business

and many factors can play a part is a problem like this, but my test
results give a strong

indication that the Veritas upgrade software/method are a contributor to
the root cause.



I will summarise any responses asap.



Thanks,

Barry


Visit us at http://www.aggreko.com

Confidentiality Notice: This communication and any accompanying attachments
contain confidential information intended for a specific individual and
purpose. This communication is private and protected by law. If you are not
the intended recipient, you are hereby respectfully notified that any
disclosures, copying, forwarding or distribution, or the taking of any action
based on the contents of this communication is strictly prohibited.

_____________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
_______________________________________________
sunmanagers mailing list
sunmanagers@xxxxxxxxxxxxxxx
http://www.sunmanagers.org/mailman/listinfo/sunmanagers

Relevant Pages