glance system table results

[TMcB]

Hi everyone

I'm looking at glance, and the system table shows me the result below.

System Table Available Used Utilization High(%)
--------------------------------------------------------------------------------
Proc Table (nproc) 4768 321 7 7
File Table (nfile) 10296 2304 22 23
Shared Mem Table (shmmni) 768 144 19 19
Message Table (msgmni) 255 102 40 40
Semaphore Table (semmni) 1024 105 10 10
File Locks (nflocks) 1200 70 6 6
Pseudo Terminals (npty) 300 0 0 0
Buffer Headers (nbuf) na 102918 na na

Should the msgmni go as high as 40%. It never goes above 10% on any of our servers (all running informix databases).

Also, when I look at the system table graph, the nproc, nfile and msgmni all look like they have reached their high water mark.

Any advice of what this is telling me is greatly appreciated

[Steven E. Protter · Accepted solution]

Shalom,

This depends totally on the applications you are running. Recent patches to OS applications like web servers and such may effect this number.

Changes in utilization of the informix application can also effect this.

Its one of those questions where you try and ask yourself what changed to figure out why this number changed.

Could you have lowered the value for msgmni in the kernel?

It is not terribly worrisome. You have 60% to spare. Apparently when you were taking this information, your system was at a higher level than normal usage.

SEP

[TMcB]

thanks Stephen

this is a new server, so we set the kernel params to be the same as our other informix server.

[Pete Randall]

The fact that the current and high utilization marks are almost all identical indicates to me that this must be a relatively short sample period, which makes it difficult to draw any meaningful conclusions.

I would also suggest that I don't believe Informix utilizes the message table. If that is true, then you have some other application driving your msgmni usage.


Pete

[Steven E. Protter]

Hi,

I know Pete knows a lot about Informix.

I would definitely urge a longer sample period for meaningful results.

An example from my past: We measured performance from 7-8 p.m. Some days it was awful, some days it was great. The real issue there was when the operator got around to doing the nightly batch processing. A longer sample time smoothed out the results and took the human factor out of the situation.

SEP

[TMcB]

thanks guys -
we've just kicked off an "update statistcs" on this new server, and while the time reduced from 1 hour, down to 12 minures, glance was throwing up "disk bottleneck" messages.

disk BOTTLENECK PROBABILTY IS 97%
Our informix logical volumes are all on one SAN disk.

Does this mean I will need to spread the raw volumes over multiple disks?

[Pete Randall]

>> Does this mean I will need to spread the raw volumes over multiple disks?

Only if you're having performance issues. With todays large disk (and large LUN) sizes, it is difficult to spread the I/O load sufficiently to avoid triggering Glance alerts. We have disk bottleneck alerts almost constantly, yet have no significant performance issues. I've worked with my DBA in the past to try to move some tables in order to relieve the bottleneck with little success and no change in performance.


Pete

[TMcB]

Hi Pete

were not having performance issues at all - the performance has improved enormously since moving to this new server and san disks.

We were just concerned because we have glance, reporting a bottleneck. What happens if it gets to 100%

Thanks
Terry

[Pete Randall]

If it gets to 100%, you may actually see some performance degradation. In our case, we hit 100% routinely without any adverse effects.


Pete