Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

The resource hash table is sparse ...

SOLVED
Go to solution
Art Wiens
Respected Contributor

The resource hash table is sparse ...

And what's worse than having sparse hash ;-)

But seriously ... I am seeing this message occasionaly being displayed in HP Operations Manager (OVO) on our ES47's eg:

The resource hash table is sparse (19702 resources found while SYSGEN parameter RESHASHTBL=65536)

The message doesn't get reset by whatever resource coming back above a threshold. The message is typically generated while the Data Protector backups are running.

The only reference to this error text I can find is in the Availability Manager manual where it lists it in a "lock contention" group of messages.

Is this something to be concerned about? Something that can be tuned up?

VMS v8.3 - relatively current on patches.

Cheers,
Art
11 REPLIES
Wim Van den Wyngaert
Honored Contributor

Re: The resource hash table is sparse ...

DP backups :

Files being backed up or restored are always locked regardless of whether the Lock files during backup (-lock) option
is enabled or disabled. With the -lock option enabled any file opened for write is not backed up. With the -lock option disabled
any open file is backed up as well. No message is issued when an open file is saved.

May be a lot of very small or empty files that are locked in bulk ?
Or may be the process quotas allow too much files to be backuped in paralel ?

Wim (no knowledge of DP)
Wim
Shilpa K
Valued Contributor

Re: The resource hash table is sparse ...

Hi,

In the following "Availability manager User's Guide" link, it says:

http://h71000.www7.hp.com/openvms/products/availman/6552pro_004.html#ap_b

Event:
RESPRS - Resource hash table sparse

Description:
The percentage of occupied entries in the hash table is less than the threshold.

Explanation:
A sparsely populated table wastes memory resources.

Recommended action:
Use the system parameter RESHASHTBL to adjust the total number of entries.

I think this indicates that the percentage of resource hash table entries actually used by your system is less compared to the value that is set for the SYSGEN parameter RESHASHTBL. So, I think this message is indicating that you may reduce the RESHASHTBL value so that memory resources may not be wasted.

Regards,
Shilpa
Hoff
Honored Contributor

Re: The resource hash table is sparse ...

The OpenView Operations Manager (OVO) tool is here offering a way for you to save a fraction of thirty-two pages of physical memory. You might well get a dozen pages back by following the recommendation. Maybe two, if you push it.

Are you short on free physical memory here? If so? toss a few gigabytes into the box and move on to the next problem.

As I posted to the HL web site earlier today, keep your eye on the prize. The rules and the assumptions and the environments change. Memory prices have dropped since the days of VAX, and configurations (with the exception of that fellow with the overloaded AlphaServer 800 box that's been around here recently) are vastly larger and more capable.
Art Wiens
Respected Contributor

Re: The resource hash table is sparse ...

So it's sort of a reverse warning ... not that it's running out of anything but rather wasting something? That's a bit odd.

There's lots of memory in these systems - either 4GB or 8GB depending on which one.

Thanks,
Art
Shilpa K
Valued Contributor
Solution

Re: The resource hash table is sparse ...

Hi,

"So it's sort of a reverse warning ... not that it's running out of anything but rather wasting something?"

From the explanation provided for "RESPRS" by the "Availability Manager User's Guide", I think it only indicates that its not utilizing the resource optimally and thus wasting. I think it is more of a informational message than a warning.

Reagrds,
Shilpa
Hoff
Honored Contributor

Re: The resource hash table is sparse ...

It's all a matter of perspective and of priorities and of appropriate use of resources.

The fellow that created this rule obviously thought that a savings of around 16 pages might be significant. It could be, too.

But outside of an aggregate recommendation arising from a memory starvation crisis or cases when the system manager has specifically requested memory optimizations, sixteen pages of memory seems to be noise.

Locally, I'd rather not bother the system manager for a potential savings of sixteen pages. Paralleling what Shilpa mentions around use of resources, the time and thought and consideration of a system manager is itself an important resource.

In my preferred and admittedly skewed view, OVO (or whatever the monitoring and tuning tool might be) would detect and would offer the memory upgrade part number and a URL for the reseller(s) or HP itself for a server memory upgrade, if that's something OVO suspects is warranted. (Or better, a "OVO can contact HP services and schedule an upgrade (for US$whatever) if you want to upgrade your server memory hardware. Is an installation on Thursday at 4pm OK? Enter your PO-number or credit card number into this HP secure web form to confirm." dialog box. Ok, so I can dream.) And as an alternative to the proffered memory upgrade, OVO can suggest RESHASHTBL here when memory was found tight, or as part of a specific "do you want me to find ways to free memory?" offered to the system manager.

As for why I don't find OVO should be reporting this? Even back in the VAX days, "buy more memory" was a common recommendation. These days, tossing 131,072 pages at a problem (or more) is usually a pretty easy solution for what ails your server. My current laptop operates with the equivalent of 524,288 Alpha pages, after all. If sixteen pages is the "low-hanging fruit" here for OVO, there's something wrong.

It'd be interesting to know when the rule was created, and the vintage of the rules engine, but that's fodder for another discussion.

And how much time have we wasted here for maybe sixteen pages?

This reply will probably turn into a blog entry here soon, too.
marsh_1
Honored Contributor

Re: The resource hash table is sparse ...

this sort of thing is only liable to become more commonplace too, all of these major toolsets (OV, TIVOLI, PATROL etc) all offer a vast range of 'management' modules from infrastructure monitoring, configuration, user, change and performance management, service desk and business level views ad infinitum... all designed to operate alone or in concert.
putting in these things in the past was a bit of an art form as a lot of metrics tended to be configurable but not set, these days as with most everything else plug and play is what the customer wants, having paid a small fortune for one of these products another small fortune on tuning it with a small army of specialists is'nt what anybody wants to hear anymore.
so most of these products now come with more and more predefined default values based on 'best practise' and experience.
i think arts experience is typical of this one size fits all attempt at setting values which can range hugely from one site to the next. although now some of the above mentioned products are offering self-learning features in their software where they sample normal usage levels and set thresholds accordingly.
that does'nt leave much room for your system manager to apply their hard gained experience.

fwiw



Art Wiens
Respected Contributor

Re: The resource hash table is sparse ...

Got the CVP running again (midas doesn't seem to be the most resilient piece of software!) so that I could actually go look what the rule "really" meant. There are two rules that can come into play here:

VMSSPI_ReshashtblSparse

Condition No.1 - The resource hash table is sparse (The percentage of resources found to the size of the resource hash table is below threshold) (match)
Match
Threshold 30
Reset 30

and

VMSSPI_ReshashtblDense

Condition No.1 - The resource hash table is dense (The percentage of resources found to the size of the resource hash table is above threshold) (match)
Match
Threshold 110
Reset 110

I do have lots of memory on these systems so I will simply increase the threshold for the sparse condition.

The dense threshold seems a bit "dense" (or maybe I just am) but 110% ?!

Cheers,
Art
Art Wiens
Respected Contributor

Re: The resource hash table is sparse ...

No wait ... I want to reduce the threshold value for sparse. I'm ok with it finding only a very small amount of hash being consumed ... leaving lots of hash for the pool ;-) And I guess the same thinking for the dense value ... I want to be notified if more hash is being consumed than I have :-(

Cheers,
Art
Oswald Knoppers_1
Valued Contributor

Re: The resource hash table is sparse ...

Or disable the message:

$ ovpolicy -disable -polname "VMSSPI_ReshashtblSparse"

Oswald
Richard Brodie_1
Honored Contributor

Re: The resource hash table is sparse ...

Since nobody has posted, a quick overview of the resource hash table structure.

When the system needs to look up a resource, it computes a hash function, and uses it to index into a table.

Each table entry is the head of a queue.

A -> Andrew->Arthur
B ->
C -> Cathy
D -> Dan->Derek

When the table is sparse, lookups take a constant time. When it is very dense, you have essentially linear search time.

The above table is 125% full: 5 resources, 4 hashtable entries. 60% of lookups aren't going to have to walk the queue.

Nothing particularly bad happens at 100%. As a rule of thumb, one generally aims for 50%-75% full though. Noting the potential memory cost is small, of course.