Sybase disk performance problem with "tempdb" devs

[John Tevik_1]

One of our Superdome clients has a large Sybase ASE 12.5 database running on a HP-UX 11iv1 Superdome and an EMC Symmetrix DMX. They are experiencing high (up to 200ms) avwait times and slightly high (up to 16ms) avserv times according to sar -d but only for the tempdb filesystem LUNs. Sar also shows low I/O volume (r+w/s in 0-80 range and blk/s in 0-2000). All other LUNs have great numbers (<6ms avwaits &
System info: An 18 CPU, 49GB memory Superdome partition with 10GB buffer cache and six 2gb HBAs split between two McData Director switches each having five 2gb connections to the DMX. All LUNs on the system have dual PV Links paths split between the two fiber switches with the simple "every other" method of load balancing. There are many other customers on this DMX but I've tried moving the tempdbs to other LUNs on other HBAs with no change in behavior. The tempdb filesystems are vxfs (version 4 according to fstyp) and are mounted with options "largefiles,nodatainlog,nolog,mincache=tmpcache".

Has anyone else seen this behavior? I'm looking for ideas or threories regarding the source of the problem and/or experiences with Sybase tempdbs on filesystem vs. raw partitions.

Attached are two listings of sar data for the tempdb LUNs and all other LUNs.

[ed volpe]

We are having performance problems with Sybase 12.51 running on DMX also. Have you resolved your issue. Thanks

[RAC_1]

I have not worked much on Sybase.

If you have online JFS, you can emulate raw file system like behavior with convsync=direct, mincache=direct

Try putting these mount options and monitor the behavior.

[John Tevik_1]

Ed,
Unfortunately, this has been an ongoing problem for several months. No resolution yet but I will post if/when that happens.

[John Tevik_1]

All

FYI, after much work and trying many filesystem mount options, the solution to our problem was to convert all Sybase tempdb devices from filesystem to raw device (with asyncdsk). This improved performance DRAMATICALLY.

Hope this helps.

John