blocked on cache

[G. Vrijhoeven]

Admins!

On one server N4000 6* 360 Mhz CPU, 6 Gb mem, connected to XP1024 max_dbc_pct 7 en min_dbc_pct 5 HPUX 11.00 a sas job takes 8 minutes.

On the second server N4000 6* 550 Mhz CPU, 6 Gb mem, connected to XP1024 max_dbc_pct 7 en min_dbc_pct 5 HPUX 11.11 the same sas job takes 16 minutes. equal data set.

When use glance to monitor the process and view the Process Wait States i see it is >95% blocked on cache. This indicates the process is waiting for the filesystem cache to be updated. I know about mount options like minfree=direct,convosync=direct,nodatainlog, or raw lvols. but i like to know why there is a difference between 11.00 (qpk march 2004) and 11.11 (gldqpk dec 2003)

Regards,

Gideon

[G. Vrijhoeven]

TOP

[A. Clay Stephenson · Accepted solution]

The first thing to determine if you are doing
apples to apples comparisons on the XP1024 LUN's. Are they both at the same RAID level? Distributed over the same number of physical disks?

Next, unless you are bypassing buffer cache with convosync=direct,mincache=direct; 11.11 tends to do better with larger caches -- 800 to 1600MB or so whereas 11.0 typically peaked out at about 800MB.

Take a look at the release notes for PHKL_30516; this seems to fit you.

[G. Vrijhoeven]

The XP1024 is the same one, and there are more luns available to the new env, spead over more raid groups. ( All is raid 5 )
We are looking at the patch you suggested, and looking at the sas version / setting differences on the two servers ( 32 bits vs 64 bits new env).

Thanks for your reply.

[Kathy Shelledy]

Gideon,

I'm having a similar problem where a job takes twice as long on an 11.11 system as on an 11.0 system. Did you resolve your issue?

Thanks,

Kathy

[G. Vrijhoeven]

Hi Kathy,

We create lvols using extend based striping, this way the server uses an other controller ( 2 FC controllers) to access an other ldev ( xp) every 4 MB. We have this configured for all our production servers connected to the XP. But for this vg we recreated the biggest lvols to be non ditributed. And this was a lot faster (jobs that took 20 mins only take 5 minutes now). We still have a call open with HP, and we still do not know the answer. But leaving extend based striping gave a giant performance boost.

commands for analysing our problem
read actions ( 2 GB) from
1 raw disk
timex dd if=/dev/rdsk/c?t?d? of=/dev/null bs=1024k count=2048
2 disk
timex dd if=/dev/rdsk/c?t?d? of=/dev/null bs=1024k count=2048
3 lvol
timex dd if=/dev/vg/lvol of=/dev/null bs=1024k count=2048
4 rlvol
timex dd if=/dev/vg/rlvol of=/dev/null bs=1024k count=2048
5 filesystem:
create 2 GB file ( make sure you have the space)
timex dd if=/dev/null of=/mountpoint/zeros bs=1024k count=2048
timex dd if=/mountpoint/zeros of=/dev/null bs=1024k

Do the mesurements several times, to make sure you have repesentable times.
compaire that to the 11.00 server and you will see if you have the same problem and i would suggest open a call at HP.

HTH,

Gideon


will copy 2 GB from the ldev to /dev/null so