Memory Utilization and HP

[Steve Bazinet_1]

I have an N4000 with 6GB of memory and the box runs at about 80% memory utilization and peaks at 90% from time to time. The box is running HP-UX 11.00 and oracle version 8.0.6.

I have a new boss that states and I quote "80% memory utilization is total unacceptable" She states the where he/she came from, HP said that the boxes should only run at 50-60% memory utilization or you could have performace problems. So he/she is busting my balls because the box is 80% utilization.

The boxes pageout_rate < 1, there is no swaping happening, vhand is doing nothing, cache hits are > 90 for reads and > 75 for writes.

Has anyone heard of HP making such a statement about memory utilization? Sounds like something a salesperson would say.

Anyone think I am crazy allowing the box to sit at 80% utilization.

Any help/opinions/words of wisdom are appreciated.

Thanks

Steve

[Patrick Wallek · Accepted solution]

80% utilization is not bad. You won't really have any performance problems unless your RAM utilization hits 100% and you start paging.

If you really must get your RAM utilization down, you can always check and make sure your dbc_max_pct kernel parameter is not still set at the default of 50%. If it is you could reset it down to something like 7% thus freeing up a whole lot of memory.

I know of no HP document that says RAM utilization should only be 50-60%. If that is all you ever use then you might as well sell part of the RAM you have and make some money back.

I would look at the 80% and say that that is proof that for your current needs the system is sized, RAM-wise at least, almost exactly right.

Just my opinion, for what it's worth.

[harry d brown jr]

80% is good, at least you are using what you paid for!

Steve, which is it: "She states " or "he/she"?? Tell them to go back if they can't handle reality!

Damn good numbers on cache hits!

Actually you are better off having 100% memory utilization, with your current hit ratios and such.


Tell them if they want more memory to go buy it and leave you alone! (I'd toss in a few extras, like that workstation upgrade you have always wanted :-))


Try these:
http://www.interex.org/conference/iworks2001/proceedings/1034/1034.pdf
http://docs.hp.com/hpux/onlinedocs/B2355-90701/B2355-90701_top.html


live free or die
harry

[A. Clay Stephenson]

Hi:

80% memory utilization is not bad at all; the only concern is that during peak usage do you begin to see pageouts. You can measure this with Glance or vmstat or if you have it with Perfview. The only value of any real significance in vmstat is the pageout (po). As long as that is zero, you have no problem even with even higher memory utilization rates.

I do like to see the pageout rate not merely < 1 but very nearly zero. That constitutes proof-positive that you have no memory pressure.

I will add that it is possible even given your numbers to benefit from additional memory. For example, buffer cache hit rates mean little if this is a database server doing raw/io (or the Online JFS equivalent). In that case, it's possible that with a larger shared memory buffer, database performance would increase.

If your boss is concerned about this, this solution is trivially simple - have your boss sign a PO for more memory.

By the way, this is my main use for PerfView. It is a very good tool for managing managers. They understand graphs well and easily grasp the 'Red Bad; Green Good' concept. It's a very good excuse for buying Perfview and a nice color printer.

Regards, Clay

[Roger Baptiste]

<>

Bang on! on that one. I have had managers who really wanted "colour charts" to show to their bosses on how the system is performing.

Memory Usage: You can extract historical stuff from measure ware, like this:

1) cd /tmp
2) cp /var/opt/perf/reptall /tmp/reptall
3) Edit /tmp/reptall and uncomment parameters you are intrested in.
4) for eg, uncomment DATE, TIME, GBL_CPU_UTIL metrics and entries under PROCESS metrics
(examples below)

5) run extract command:

extract -xp -v -gp -r /tmp/reptall -b today
-gd
-gk
-gc

(xp -> export data to external format files)
(gp -> select types of data to extract)
(r -> specify report template file )
(b -> start date )

->> This will create two files in the current directory,
one for process and another for global.
xfrdGLOBAL.asc and xfrdPROCESS.asc containing
the metrics requested.


So, you can keep "sets" of report templates for
tracking disk, cpu. memory etc.

GBL_CPU_TOTAL_UTIL
GBL_MEM_UTIL
GBL_SWAP_SPACE_UTIL
GBL_MEM_PAGEOUT_RATE
GBL_NUM_USER
GBL_PRI_QUEUE
GBL_RUN_QUEUE
GBL_ACTIVE_PROC


GBL_CPU_SYS_MODE_UTIL
GBL_CPU_USER_MODE_UTIL
GBL_DISK_PHYS_READ_RATE
GBL_DISK_PHYS_IO_RATE
GBL_DISK_PHYS_WRITE_RATE

------

The values which would intrest you in this case would be GBL_MEM_UTIL GBL_MEM_PAGEOUT_RATE and GBL_SWAP_SPACE_UTIL. Make a spreadsheet of these three with dates and time and you can make a case of things of being ok.

HTH
raj

[Bill Hassell]

Memory utilization is NEVER a meaningful statistic without a page out rate too. I run an application server that runs 100% memory usage (and has for 7 years), has a couple of thousand users in the password file and typically runs 1000-1500 processes that consume about 2000 megs of RAM.

Oh, I only have 512 megs of RAM, and yet the users are very happy. Why? Because the applications are very interactive query programs and are used perhaps 5-20 times each day for an average of 1-2 minutes of CPU time for each copy. Or more simply stated, the 'think time' is very long between keyboard inputs and thus the programs are paged out transparently. My paging rate runs 0-10 during any 5 second period, not enough to worry about.

Memory should always be running at 100% ot you're not getting your money's worth. You monitor page out (ignore page in because it counts new programs as well as swap returns) and when it starts to consistently stay in the 20-50 page range (with peaks in the hundreds), then double your RAM (buy more more memory).

Or you can easily satisfy your manager by purchasing twice as much RAM right now.

Moral: there are NO simple answers when it comes to performance on a multitasking, multiprocessor system. (well, there is one solution that always works: stop all applications)

Also note that the biggest enhancments to performance are SELDOM found in tweaking kernel parameters but in reconfiguring or rewriting the application(s). Kernel parameters adjust the size of tables and a few behavioral features.

[Frank Slootweg]

Adding to the other responses:

80% is 'bad', but not for the reason your manager gave, but for the reason that the others gave, i.e. you are not getting your money's worth because you are not using all the memory which you have.

On the other hand, *100*% is also bad (Sorry Bill! :-)). Let me explain:

HP-UX treats main memory (RAM) like a cache. A good cache is always full. However, in order to allow small processes to be started quickly, HP-UX keeps memory 'nearly' full. 'Nearly' means that a memory utilization ("Mem Util" in Glance) of 95 to 96% is normal. Percentages of 97 and above indicate too much memory pressure and will cause paging or swapping or process deactivation and reactivation. On the other hand, percentages well below 95 indicate that you have 'too much' memory, i.e. more than is 'ever' needed.