vhand process

[Phil Rowen]

Hi,
Have an issue with vhand daemon using high % of CPU at this time geeting occassional system hangs.
Running OS version 11.11
System in question has 4096mb RAM and 20971mb swap space.

Read that it is worth looking at dbc_min_pct and dbc_max_pct kernel parameters. These are currently set at 5 and 8 accordingly.

Also ran vmstat and found that intermittantly pi value being quite high( between 100 and 400) although po value is always 0.

Any advise as to the cause of these system hangs?
Cheers.

[Pete Randall]

Well that's certainly a puzzle. The high vhand usage sounds like paging but your vmstat po value says you're not. Your dynamic buffer cache settings look OK, too. What are you running on this system?


Pete

[harry d brown jr]

read http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=666500

basically check your patches.

Additionally, have you increase load (users and applications) on this server?

also read:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=494011

do a forums serach on vhand

live free or die
harry d brown jr

[Phil Rowen]

The application running on this system is SAP CRM(customer relationship management) running over an oracle database.

[Rita C Workman]

By all means check your patches, but...

vhand may simply be doing it's job. This daemon works to ensure that there is enough free memory on the system at all times. If it's running alot AND you see syncer running it's fool head off that tells you that you have memory pressure. Syncer's job is to move things off buffer cache and force it out to disk.
But remember, your system may actually just be working hard. The fact that you are NOT paging out tells you memory is handling it, as Pete wrote. Albeit busy, but handling it.

If you see vhand and syncer beating themselves to death....then your working a little too hard and need to address memory pressure.

Regards,
Rita

[Phil Rowen]

Thanks you all for your prompt replies.
I have checked our patch levels and have patches PHKL_30796 and PHKL_28410 but not PHKL_28695.
I will install this patch tonight and monitor to see if the problem reoccurs.

With regards to dbc_min_pct and max_pct I believe they set quite low already. Would it be worth lowering these further?

[Kent Ostby]

Phil --

I wouldn't lower them (at least in regards to this problem).

At 8% of 4 gig, you're only using a maximum of 320 meg and I wouldn't worry about that affecting vhand until that number approached 750 meg of DBC.

Best regards,

Oz

[Fred Ruffet]

SAP ? Isn't there an Oracle DB behind ?
Even if you use only 8% as dbc_max_pct, with an intensive IO application, it won't be long to reach this. What RAM is using the rest of your apps ? If you have configured Oracle/SAP to use the whole 4GB, it will swap, and SGA in swap is bad. Very bad.
Note that I find a little bit surprising having 20GB of swap for 4GB of RAM. Such a think may just proove you don't have enough RAM. Could you post output from "swapinfo -tam". If your system is swapping more than its RAM, you may encounter problems and vhand have a hard day...

Regards,

Fred

[Phil Rowen]

Yes SAP does use oracle database.
With regards to swap size of 20Gb, this size was recommended by SAP/HP when the box was originally sized.

swapinfo output

# swapinfo -tam
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 20480 2944 17536 14% 0 - 1 /dev/vg00/lvol2
reserve - 12783 -12783
memory 3085 475 2610 15%
total 23565 16202 7363 69% - 0 -

[Steve Lewis · Accepted solution]

The moment I saw your RAM to SWAP ratio I knew you were running SAP...

This is a common problem in SAP because of the configuration of SAP extended memory.

The SAP extended memory can be many times physical RAM, SAP simply relies on the o/s to page in bits of SAP extended memory as required. I don't like it one bit because SAP systems constantly run from swap and have no room to 'breathe', to perform optimally. They are slow to start new processes, having to wait for pageouts or even process suspensions. Your po value may be zero for the most part, but I bet that you had large pageouts when the application first started.

To reduce the vhand usage your choices are either buy more memory or drastically reduce the SAP extended memory parameter.

You also need to ensure that your database has its shared memory segments (SGA etc) locked in memory using shmctl(...SHM_LOCK...). ipcs won't indicate whether this has been done, you need to go into the database config itself.

If you have several SAP/DB instances on this box then you need to move some of them off to another box.

Search for other threads on SAP extended memory. This is a good one:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=455588