Real Memory--I Need To Know How Much, But I'm Not the Superuser

[Bill Perez]

I don't have the superuser password--they tend not to give them to DBA's doing remote support. I've hunted thru the FAQ's and they only tell you how to find the amount of RAM on the system when you are superuser. Is there really *no* way to tell how much memory is installed on the machine without being "su"? I've gone into "top", but I can't really interpret it--the "real memory" figure keeps fluctuating, which tells me it's not really "real". At any rate, "top" is a rickety solution--ultimately I need a way to get the amount real memory into a shell variable for scripting purposes, and "top" isn't too amenable to that.

[Patrick Wallek]

Check out this thread. Some of these will work from your non-superuser id and some won't. You'll just have to experiment and see what works for you.

http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0x52e7f841489fd4118fef0090279cd0f9,00.html

[James R. Ferguson · Accepted solution]

Bill:

The easist solution given that you're not root, is to use the C program suggested by Curtis in the thread below. This will work nicely for a non-root user:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0xb0a2854994d9d4118fef0090279cd0f9,00.html

...JRF...

[Patrick Wallek]

I compiled and ran the C program, and in my environment at least, it did not return the number that I expected.

The number it returned, when calculated down to number of MB, was 256 MB less that what I actually have.

You can use this program, just beware the results.

[Maureen Gunkel]

Bill,
I think Top would work, I get an output like this:
Memory: 2526664K (884948K) real, 6562608K (1453696K) virtual, 5811804K free
Maybe not, just a thought.
Mo

[James R. Ferguson]

Bill & Patrick:

I too compiled the program (on a 10.20 server). When I executed it I got 1,073,729,536 which when divided by 1024 yields 1,048,564 -- exactly the value I get when I do:

# grep -i physical /var/adm/syslog/syslog.log

I don't find any descrepency.

BTW, a grep of syslog (or /var/adm/syslog/OLDsyslog.log if the current one has been trimmed or switched) is something any user can do.

Regards!

...JRF...

[Curtis Larson]

I've never had any problems with the c code either. Patrick should be able to easily verify the results via, dmesg, syslog, /usr/sam/lbin/getmem, kernel probing, etc. and check weather his calcuations are correct. maybe he has had some memory deallocated that he doesn't know about yet.

[Alan Riggs]

grep Physical /var/adm/syslog/syslog.log

[melvyn burnard]

A simple way to look would be in /var/adm/syslog/syslog.log or OLDsyslog.log
The system logs the Physical memory on boot up into syslog.log, and also copies the previous syslog.log to OLDsyslog.log.

grep Physical /var/adm/syslog/syslog.log should reveal what you are after:

$ grep Physical /var/adm/syslog/syslog.log
Nov 21 09:57:15 hpwin025 vmunix: Physical: 1048576 Kbytes, lockable: 808408
Kbytes, available: 929852 Kbytes
$

[Patrick Wallek]

OK Guys and Gals,

I figured out the problem I had. I assumed, which always get us in trouble, right?, that the links that James and I had posted were links to the same thread. They weren't. There was a C program in the thread I posted that I compiled and ran, and it came up 256 MB short. I compiled and ran the C program in the thread that James posted and the results came up to be what I expected. I haven't looked at the C code closely for the program in the thread I posted to figure out where it is going wrong, but it apparently is going wrong somewhere.

Just for grins, here are the results from the two programs:

# ./phys_mem_bad
Physical Memory is -2013265920 bytes - I assumed the '-' was just a separator, but maybe the program is not looking at something correctly and returning a negative result?

[scrooge:root] 344 /home/wallek
# ./phys_mem
2281701376 ----> This value is correct and is from the program in the thread that James posted.
[scrooge:root] 345 /home/wallek
#

[Bill Perez]

Thanks, everybody.

It is amazing to me that such a simple question has such complicated and controversial answers on HP-UX. AIX and SunOS must be advanced technology--getting this (rather elementary) piece of info from them does not require you to compile your own C program (oh, how I pine for "prtdiag" or even "lsattr"!).

There are problems with the answers I'm getting, however:

- "grep Physical /var/adm/syslog/syslog.log" -- doesn't work. At least on the system I'm looking at (B.11.00), syslog.log has no such text even remotely like "physical" or "memory" in it.

- Going into "SAM" is not a solution for me, unfortunately--it needs to be scriptable.

- Don't have "glance".

- "echo physmem/D | adb ..." tells me I have 0MB. I know this is wrong.

- "/usr/sam/lbin/getmem" returns nothing.

- "dmesg", of course, will not work.

- "top". What can I say about "top", except that no combination of the numbers it reports comes close to what Curtis' program tells me is there?

- Curtis' program. Well, it seems that's the best I can do. Unfortunately, I'll have to port it to each machine that I might need to support. Since they are all over the place, HP-UX-version-wise, I'll have to compile it everywhere as well, to be safe. I can do this--it just seems amazing that one has to go to such arcane lengths. And can I always trust it?

[Bill Perez]

I guess I should read *all* the replies before I respond:

grepping OLDsyslog.log worked. I guess the answer should be:

grep Physical /var/adm/syslog/*syslog.log

But how reliable is this? If the "Physical" memory message was archived to "OLDsyslog.log" at one point, what's to keep it from getting lost altogether when the system copies to "OLDsyslog" once again? What determines the break between the two syslogs? Or will there be a "REALLYOLDsyslog.log"?

Also:

Curtis' program looks a lot better than the one I found in a recent HP-UX FAQ that goes like this:

#include
#include
#include
main()
{
struct pst_static buf;
pstat_getstatic(&buf, sizeof(buf), 0, 0);
printf("Physical RAM = %ldMB\n", buf.physical_memory/256);
}

I just don't trust that hardcoded "256", even though it happens to come up with the same answer in my case...

[Curtis Larson]

reliability of syslog) usually this works just fine, but as you seen, it doesn't always for these reasons:
security: some sites don't give read permission
maintainence: some sites trim their log files others roll them to new files every so often.
Whenever /sbin/init.d/syslogd is run syslog.log is rolled over to OLDsyslog.log. If that is done a few time your information is gone again.

The c code will work on every version except pre 10.x. So unless your working on a non y2k compliant 9.X system, you won't need to compile it but once. of course you'll need to uses the appropriate archicture compatiblity options at compile time for this.

So, you need to look at how up to the minute information do you need (the amount of memory usually doesn't change without rebooting the system).

1) you can give your root user a script to run periodically,maybe daily, which writes your information to a file where you can read. But be ready to answer questions about why you need the information. A sysadmin isn't going to want to start maintaining new scripts any more then you want to copy two files to each system.

2) you can put something in your database startup to check syslog for the amount of memory. Usually the databases are started up soon after the system is and the information will be in syslog most definitely at this time.

Now, your database might be restarted a few more times then the system is, so if the memory value is no longer in syslog just use the last value you were able to read.

The amount of memory isn't going to change while the system is running. If there is performance problems because of memory, you'd think a dba would have some knowledge of this and would be told when memory was going to added.

i agree with you hpux isn't the most user friendly os out there.

[Bill Perez]

Curtis:

On "syslog.log": I was afraid you would say that. "Usually reliable" is (by Murphy's Law) equivalent to "unreliable when really needed". Call me a dreamer, but I'm going to want that "always reliable" solution. Of course, "always" is a big, unattainable concept, but given the various caveats you cite for "syslog.log", it falls too far short.

Idea #1: Ingenious, especially if crontabbed, and thus staying out of the sysadmin's hair. But still, as you point out, kind of klunky and suspicious. The whole point is to *not* have to bother the sysadmin.

Idea #2: Even more ingenious, susceptible to easy scripting, and I like it. It takes advantage of the one time "syslog.log" can be relied on. It should work for every version of HP-UX I might stumble upon. It needs no attention to "architecture compatibility options". Of course, it only works for those (like me) who have access to some script that runs at boot time.

You would *think* the DBA is aware of how much memory his machine has, wouldn't you? However, we are supporting multiple clients, on multiple platforms (AIX, Sun, HP-UX, Linux, and--ack!--even NT), who have many sysadmins that come and go. Since we are remote, they don't always think to tell us what they are doing (I love getting paged at 3 AM with a "DB Down!" msg, only to call in and invariably find out the machine was brought down on purpose--"Oh, sorry, I guess we should have told you guys..."). Whine, whine, whine...

Anyway--thanks.

As usual with Unix (even HP-UX), where there's a will there's way...