I/O performance dip following Solaris/VxFS/VxVm upgrade to 9/4.1MP1
- From: "Barry Tait" <Barry.Tait@xxxxxxxxxxxxx>
- Date: Tue, 26 Sep 2006 19:14:59 +0100
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
- Prev by Date: Jose Thomas/US/ABNAMRO/NL has a new e-mail account.
- Next by Date: sol10 & pfil with aggr interfaces?
- Previous by thread: Jose Thomas/US/ABNAMRO/NL has a new e-mail account.
- Next by thread: sol10 & pfil with aggr interfaces?
- Index(es):
Relevant Pages
|
