- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Memory usage code
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-30-2009 11:58 AM
тАО04-30-2009 11:58 AM
Memory usage code
This process on loads several shared libraries on demand.
The system call is being made in one of the shared libraries that is meant for logging purpose. It is here that the below code is leveraged to get the memory statitiscs. Unfortunately the output coming out of it is too large in terms of the number of bytes. This does not equate to the current size of process memory .
Could it be
1) wrong usage of format specifiers and variables which could lead to overflow or something else
struct pst_vm_status pst;
int idx, count;
size_t sys_page_size;
sys_page_size = sysconf(_SC_PAGE_SIZE);
long long shared_vm = 0;
long long shared_ram = 0;
long long private_vm = 0;
long long private_ram = 0;
idx=0;
count = pstat_getprocvm(&pst, sizeof(pst), getpid(), idx);
while (count > 0)
{
switch ((long)pst.pst_type) {
case PS_IO: break;
/* Don't count IO space. It really is not RAM or swap. */
default:
if (pst.pst_flags & PS_SHARED) {
shared_vm += (long long) pst.pst_length;
shared_ram += (long long)pst.pst_phys_pages;
} else {
private_vm += (long long) pst.pst_length;
private_ram += (long long)pst.pst_phys_pages;
}
break;
}
idx++;
count = pstat_getprocvm(&pst, sizeof(pst), getpid(), idx);
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-30-2009 12:29 PM
тАО04-30-2009 12:29 PM
Re: Memory usage code
So... you don't really say what's considered the output. Is this returning private_vm? private_ram? Are these globals read elsewhere (and if so -- what happens if more than one client is using the library at a time)?
Certainly since the length and number of pages are both in pages and HP-UX platforms currently max out at 44-bit physical addressing / 50-bit virtual addressing, the variables you've shown should be no worse than 32-bits physical and 38 bits virtual.
uname -a ? (i.e. what version of the OS are you running this on?)
Do you get any difference if the library and application are compiled with -D_PSTAT64 assuming they are 32-bit? That would probably do it, by the way -- without -D_PSTAT64, these fields are _T_LONG_T which becomes just int32_t. Casting to long long would sign extend a full 32-bit value.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-01-2009 08:39 AM
тАО05-01-2009 08:39 AM
Re: Memory usage code
[]- while loop is ok . I m issed the terminating }
So... you don't really say what's considered the output. Is this returning private_vm? private_ram? Are these globals read elsewhere (and if so -- what happens if more than one client is using the library at a time)?
[]I'm concerned about the memory leak. So I guess I should be concerned about shared ram and private ram.
Also the the library is used by this process only.
These figures comes out to be good when I use this code in a samll application. Our enterprise app is one that loads the sl files one by one and this code is part of one of those sl files. My first questions is whether is it possible at all to use the above code in such an environment.
Certainly since the length and number of pages are both in pages and HP-UX platforms currently max out at 44-bit physical addressing / 50-bit virtual addressing, the variables you've shown should be no worse than 32-bits physical and 38 bits virtual.
uname -a ? (i.e. what version of the OS are you running this on?)
HP-UX irhp11a B.11.11 U 9000/800 999245507 unlimited-user license
Do you get any difference if the library and application are compiled with -D_PSTAT64 assuming they are 32-bit? That would probably do it, by the way -- without -D_PSTAT64, these fields are _T_LONG_T which becomes just int32_t. Casting to long long would sign extend a full 32-bit value.
[]# if defined(_PSTAT64)
# define _T_ULONG_T uint64_t
# define _T_LONG_T int64_t
# else
# define _T_ULONG_T uint32_t
# define _T_LONG_T int32_t
# endif
Aboveb is the conditional macro defination. I would like to know that on a 32 bit platform what is the equivalent of long long as in above. Should the usage os long long cause an overflow. Note that the value that comes for phsical memory by top command is about 30 MB when the above program o/p shows the below figures.
[1745818832][1745818784][1745818736][1745818688.
I'm assuning that the page size is 4 KB.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-01-2009 08:58 AM
тАО05-01-2009 08:58 AM
Re: Memory usage code
Probably all you need is to call sbrk(0). Or use mallinfo(3).
If you want to track a memory leak, you should use gdb's leak detection commands.
>what is the equivalent of long long as in above
int64_t is the base type long long.
>should the usage of long long cause an overflow.
Nor sure how, if you are talking about bytes used.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-01-2009 09:13 AM
тАО05-01-2009 09:13 AM
Re: Memory usage code
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-01-2009 09:36 AM
тАО05-01-2009 09:36 AM
Re: Memory usage code
The simplest thing to do is to not try to guess and cast things. You obviously include the pstat header -- use _T_LONG_T as the type for your summation variables and lose the casts.