DIFFERENCES IN MEMORY UTILIZATION REPORTED BY

ITEM: RTA000034247



QUESTION:                                                                       
The environment is AIX 3.2.3 E.                                                 
                                                                                
Please help me understand the differences between the way 'svmon -G'            
and 'ps aux' reports memory utilization.   Also, some explanation on            
how to read and understand what is reported by 'svmon -Pa pid#' would           
be greatly appreciated.   We are trying to understand why a numerically         
intensive application shows hardly any memory utilization with 'ps aus'         
but 'svmon -G' shows almost all the real memory inuse.                          
                                                                                
What are we really looking at?                                                  
                                                                                
---------- ---------- ---------- --------- ---------- ----------                
A:  In the output of the 'ps aux' command, the percent MEM column is            
the percentage of real memory currently used by the process.                   
Specifically, MEM is the total size of the memory resident             
portions of the code and data segments of the process, divided by the           
size of real memory and multiplied by 100.  Because multiple processes          
can share segments, the sum of MEM values over all processes           
may exceed 100.                                                                 
                                                                                
    The "inuse" column of the svmon -G report is a little confusing.  The       
reason that the inuse column shows almost all the real memory in use, is        
that the Virtual Memory Manager will keep pages in memory that have             
been accessed recently.  Thus, frequently accessed pages will tend to           
stay in memory longer, and logical file accesses to the corresponding           
blocks can be satisfied without physical disk access.  Then the numbers         
in the inuse column may not represent how much memory is in use at that         
specific time, but how much memory contains pages.  If you wish to              
determine how much memory is in use for a given workload, you can              
simulate a small memory size using the rmss -c command.  Then the pages         
in memory that are not presently in use, but have been recently accessed        
so are still in memory, will be forced to the free list.  Then you can          
reset the memory size to the physical size using rmss, and run a normal         
workload to see how much memory the system will typically use.  For             
more information on this, please reference item CHQRH in ASKQ.                  
                                                                                
   The output of the svmon -Pa pid command is interpreted as follows:           
                                                                                
   segid:       The segment id of the process                                   
   Type:        Either works, pers or clnt, meaning the segment is a            
                working, persistent or client segment.                          
   Description: A description of the segment.                                   
   Inuse:       The total number of pages in real memory from segments          
                that are used by the process.                                  
                                                                                
       NOTE:  A segment may be used by multiple processes.  Each page in        
              Real memory from such a segment is accounted for in the           
              Inuse field for each process that uses the segment.  Thus,        
              the total of the Inuse fields over all active processes           
              may exceed the total number of pages in real memory.              
                                                                                
   Pin:         Total number of pages pinned from segments that are used        
                by the process.                                                 
                                                                                
       NOTE:  A segment may be used by multiple processes.  Each page           
              pinned from such a segment is accounted for in the Pin            
              field for each process that uses the segment.  Thus, the          
              total of the Pin fields over all active processes may             
              exceed the total number of pages pinned.                         
                                                                                
   Pgspace:     Total number of pages on paging space by segments that          
                are used by the process.                                        
                                                                                
       NOTE:  A segment may be used by multiple processes.  Each page on        
              paging space from such a segment is accounted for in the          
              Pgspace field for each process that uses the segment. Thus,       
              the total of the Pgspace fields over all active processes         
              may exceed the total number of pages on paging space.             
                                                                                
   Address                                                                      
   Range:       The address range of the segment.                               
                                                                                
   There is a hardcopy  documentation entitled "Performance  Monitoring         
   and Tuning Guide" (SC23-2365-01) that  you may wish to receive.  The        
   above  information was  taken from this guide and it is very helpful         
   in understanding performance issues and using the performance tools.         
                                                                                
---------- ---------- ---------- --------- ---------- ----------                
QUESTION:                                                                       
What is the difference between  MEM and RSS as reported by the 'ps aux' comman  
                                                                                
We are running large NASTRAN jobs, and are surprised by the  MEM being          
so small, leading us to suspect that the NASTRAN jobs are paging more           
than normal.  Any guidance here?                                                
                                                                                
---------- ---------- ---------- --------- ---------- ----------                
A: The RSS output reported from the ps aux command is the resident              
set size of the process.  Specifically, RSS is the total size of the            
memory resident portions of the code and data segments of the process          
expressed in KB.  Because processes can share segments, the sum of RSS          
over all processes may exceed the size of real memory.                          
                                                                                
   The difference between RSS and percent MEM is that percent MEM reports       
the percentage of the memory used by the process, and RSS is the number         
of kilobytes of memory the process uses.                                        
                                                                                
   If you are worried about paging, I would use the vmstat command to           
determine if the NASTRAN jobs are indeed paging.  You will not be able          
to determine the extent of paging through the output of the ps command.         
                                                                                
---------- ---------- ---------- --------- ---------- ----------                
QUESTION:                                                                       
We are still trying to understand why when NASTRAN is running, the              
entries in the process table (as reported by ps aux) show virtually            
nothing for both  MEM and RSS, where other large numerically intensive          
jobs such as DYNA3D, ABAQUS, etc., show significant resource usage              
in the  MEM and RSS column.  Is 'ps' getting fooled?  How do I                  
accurately determine how much real memory (RAM, not virtual) an                 
application is using during run time?  We have a 256 MB RAM Model 580.          
NASTRAN gives us the capability to allocate real memory to a job.               
We are specifying 50,000,000 words x 4 MB/word (RS/6K arch) = 200 MB            
real memory.  There are no other applications running that would be             
competing for memory, but we cannot confirm that we are using that              
memory, but instead it looks like we are paging?  This just doesn't             
make sense.  How do I get to the bottom of this?                                
                                                                                
---------- ---------- ---------- --------- ---------- ----------                
A:  The command you need to view memory segments is svmon.                      
    There are several forms:                                                   
      svmon -P   with show memory segments for a process.           
      svmon -Pau             will list memory segments for the 10               
                               biggest  memory users.                           
      svmon -Pag             will list memory segments for the 10               
                               biggest paging space users.                      
                                                                                
    I left you a phone mail message.  I'd rather continue this                  
    by phone.                                                                   
                                                                                
---------- ---------- ---------- --------- ---------- ----------                
                                                                                
                                                                                
This item was created from library item Q640605      CKNRV                      
                                                                                
Additional search words:                                                       
AUX AUXILIARY CKNRV DEC94 DIFFERENCES IX MAIN MEASURE MEMORY OP                 
OZIBM OZNEW PERFORMANCE PS REPORTED RISCPERF RISCSYSTEM SOFTWARE                
STORAGE SVMON SYS TUNE UTILIZATION VS                                           
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                               


WWQA: ITEM: RTA000034247 ITEM: RTA000034247
Dated: 03/1996 Category: RISCPERF
This HTML file was generated 99/06/24~12:43:12
Comments or suggestions? Contact us