what is the memory used by a process

[Jean-Yves Picard]

Hello,

Short version:
how are processe using my memory ?

Long story:
-There are many thread on this topic.
my understanding is that neither VSZ from UNIX95= ps -o vsz nor top's SIZE can give you precise information in case on multiple instance on same executable. (like sh, telnetd or oracle forms among many)

the question is
can i figure out memory use by multiple instance of a executable by adding
one time pst_tsize from pst_status
and sum of all pst_dsize , pst_ssize , pst_usize from all runing instances ?

Jean-Yves Picard

/* ligne de commande : cc +DA2.0W -D_PSTAT64 -o my_ps my_ps.c */
#include

#include
#include
#include


#define BURST ((size_t)10)
main() {
long gid ;
struct pst_status pst[10];
int retour ;

{

int i, count;
int idx = 0; /* index within the context */
int c = 0 ;
char *lignecomm ;
/* loop until count == 0, will occur all have been returned */
while ((count=pstat_getproc(pst, sizeof(struct pst_status),BURST,idx))>0) {
/* got count (max of BURST) this time. process them */
for (i = 0; i < count; i++) {
lignecomm=pst[i].pst_cmd ;
if ( lignecomm[0] == 10 ) lignecomm = &(pst[i].pst_cmd[1]) ;
(void)printf("%3d :pid is %d,\n",c++, pst[i].pst_pid );
(void)printf("\t ligne de commande %s \n",lignecomm);
(void)printf("\t executable est %s \n",pst[i].pst_ucomm);

printf ("! \t%d",pst[i].pst_pid);
printf ("\t%d",pst[i].pst_dsize);
printf ("\t%d",pst[i].pst_tsize);
printf ("\t%d",pst[i].pst_ssize);
printf ("\t%d",pst[i].pst_usize);
(void)printf("\t%s",pst[i].pst_ucomm);
(void)printf("\t%s\n",lignecomm);

/* (void)printf("%3d :pid is %d, command is %s\n",c++, pst[i].pst_pid, pst[i].pst_ucomm);*/
}
/*
* now go back and do it again, using the next index after
* the current 'burst'
*/
idx = pst[count-1].pst_idx + 1;
}

if (count == -1)
perror("pstat_getproc()");
}

}

[Avinash Agarkar]

Hi,

If you have installed OVPM then you can check with memory bottle neck and also check in drill tables which process is exectely using the memory.


Thanks,
Avinash

[skt_skt]

usage is "sz" for memory and not vsz(swap) on UNIX95.

Check adding this way.

[Bill Hassell · Accepted solution]

> give you precise information in case on multiple instance on same executable...

This is far, far more complicated than you might expect. There are many different ways that each process can use memory. The simple case is on process. A process will use (a very small amount of) memory for text which is the unchanging executable code. But this code is normally shareable so 100 copies of sh or telnetd, etc will use exactly the same chunk of memory for the text. Noter that the actual executable size on disk is a close approximation to the size of the text area. On PARISC 11.11, sh: 200Kb, telnetd: 100Kb (very small). The next two quadrants are unique to every process: heap or local data, and stack. These are included in top and ps calculations. You can see the basic size of a program with the size command:

size /usr/bin/sh /usr/bin/ksh /usr/bin/csh

But this only defines the program as it is loaded. Once running, the program can request additional local RAM with malloc(2) and/or it could work with memory mapped files using mmap(2) and shared memory areas using shmop(2) and friends. But here's the tricky part: 1 process + memory-map + shared-segment = total memory. But run 50 programs that share some or all of the same memory areas and now calculations are quite complex. You have to instead use ipcs to count the shared areas separately since these objects are shared.

Then there is the global memory resource called the buffer cache. This is a dynamic resource so it can vary in size but for 11.23 and earlier, the maximum size will be limited by dbc_max_pct.

And finally, memory can be dynamocally allocated by the kernel but this is very dependent on the HP-UX revision.

So given all these variables, I find that trying to look at memory usage is not nearly as useful as looking at actual page out rates. There is no meaningful effect when page out rates are 0-15 or so. From 20-75, there may be occasional noticeable delays, and from 100 and up, there will definitely be noticeable delays.

[Dennis Handly]

>Bill: Note that the actual executable size on disk is a close approximation to the size of the text area.

There is no need for approximation, the value returned by size(1) is the size of the text area. Plus the values for each shlib used.

The executable contains lots of fluff, so your mileage may vary.

>can request additional local RAM with malloc(2)

That's brk(2) or malloc(3).

[Jean-Yves Picard]

Hello,

@Bill: I am trying to figure out what memory I'll need when I'll connect more user to my application. I can't relay on swaping information.
I need to accomodate for 2500 user, while I have 200 now, I can ask for 30 Gb of Superdome memory, but if it can fit into 10 Gb, all the better.

I've already figure out that text is uniq. In fact I am watching oracle, so my second guess is all oracle instances (e.g ora_smon_XXX and oracleXXX ) share the same text (if same version) and same XXX's SGA.

thanks for reply

Jean-Yves

[Bill Hassell]

> @Bill: I am trying to figure out what memory I'll need when I'll connect more user to my application. I can't relay on swaping information. I need to accomodate for 2500 user, while I have 200 now, I can ask for 30 Gb of Superdome memory, but if it can fit into 10 Gb, all the better.

There is no simple answer. Your applications will be trivial as both the text and shared libraries for the apps will be minimal. Only the data area will be unique.

> I've already figure out that text is uniq. In fact I am watching oracle, so my second guess is all oracle instances (e.g ora_smon_XXX and oracleXXX ) share the same text (if same version) and same XXX's SGA.

Oracle changes everything. The biggest performance advantage in Oracle is a large SGA (shared memory) and a good DBA will take advantage of this, perhaps allocating 5 or 10 Gb of RAM just for SGA. And I doubt that the applications and databases will be static -- someday, someone is going to add a couple of more Oracle instances, and perhaps some Java middleware and other stuff. It would be a waste of time to count process text and data areas. Instead, look at the big picture and get a lot of RAM and CPUs up front. It will be painfully difficult to add more later. When things run slow because of lack of RAM and/or CPU, management almost always rejects the additional hardware, insisting that there is something can be done to make the OS run faster.