<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Memory Usage by process - Always the BIG ? in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628292#M378202</link>
    <description>&amp;gt; looking for some script which may really provide a consolidate memory usage status and process taking max memory...&lt;BR /&gt;&amp;gt; Expressing process using highest memory in terms of percent.&lt;BR /&gt; &lt;BR /&gt;This really won't provide any useful information. A memory leak is nothing but a programming artifact...it may be intentional (the program needs more memory) or unintentional and therefore a leak. But knowing what percentage of RAM a single process is using is like trying to fix a filesystem by looking for big files. All the big files (or processes) are running as designed, and the real problem is with dozens of smaller files (or processes) that are not supposed to be growing.&lt;BR /&gt; &lt;BR /&gt;So let's assume that the program using the largest amount of local or heap memory is Java and it has a resident set size of 2000MB. Do you know how to rewrite the Java code to not use so much memory? If not, then all you can do is apply the latest patches and buy more RAM if necessary.&lt;BR /&gt; &lt;BR /&gt;Or perhaps it is shared memory (which is not part of local memory for any process, but Oracle requested 5000MB. So it is using a lot of memory but you must talk to the DBA about this usage. You may be informed that to reduce it to 1000MB means that all Oracle transactions will take 500% longer to complete.&lt;BR /&gt; &lt;BR /&gt;The amount of memory used by each process is a function of how it was written. While you can impose a memory limit for each process, the majority of programs will simply crash with an errno 12 message (not enough core). So you will have solved the problem for programs that take more than the allowed space but no one gets any work done.&lt;BR /&gt;</description>
    <pubDate>Thu, 06 May 2010 17:45:34 GMT</pubDate>
    <dc:creator>Bill Hassell</dc:creator>
    <dc:date>2010-05-06T17:45:34Z</dc:date>
    <item>
      <title>Memory Usage by process - Always the BIG ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628279#M378189</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;I have been looking through innumerous threads regarding ddetermining the correct memory utilization of the system and the proces occuping max memory for HPUX systems&lt;BR /&gt;It is depressing to see multiple replies but none really conclusive.&lt;BR /&gt;&lt;BR /&gt;Here upon, I request all the genius to put in their expertise and make this a nobel thread.&lt;BR /&gt;I think using commands like &lt;BR /&gt;UNIX95= ps -ef -o vsz,sz.. | sort -nrk1/2 etc or swapinfo -tam are all useless since they never provide a consolidated information..&lt;BR /&gt;&lt;BR /&gt;Is there any genuine way where we can extract the % of memory occupied and process occuping max memory (in %) and ofcouse validate the results by some simple calculation.&lt;BR /&gt;&lt;BR /&gt;A generic script for HPUX platforms should be FINE</description>
      <pubDate>Tue, 04 May 2010 14:25:09 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628279#M378189</guid>
      <dc:creator>shab1207</dc:creator>
      <dc:date>2010-05-04T14:25:09Z</dc:date>
    </item>
    <item>
      <title>Re: Memory Usage by process - Always the BIG ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628280#M378190</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;Yo can use "glance" or the script "kmeminfo".&lt;BR /&gt;&lt;BR /&gt;Regards,</description>
      <pubDate>Tue, 04 May 2010 14:42:06 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628280#M378190</guid>
      <dc:creator>R.O.</dc:creator>
      <dc:date>2010-05-04T14:42:06Z</dc:date>
    </item>
    <item>
      <title>Re: Memory Usage by process - Always the BIG ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628281#M378191</link>
      <description>I think there would be infinite such threads and i am sure i have explored most of them.&lt;BR /&gt;&lt;BR /&gt;looking for some script which may really provide a consolidate memory usage status and process taking max memory</description>
      <pubDate>Tue, 04 May 2010 14:52:54 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628281#M378191</guid>
      <dc:creator>shab1207</dc:creator>
      <dc:date>2010-05-04T14:52:54Z</dc:date>
    </item>
    <item>
      <title>Re: Memory Usage by process - Always the BIG ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628282#M378192</link>
      <description>Shalom,&lt;BR /&gt;&lt;BR /&gt;&lt;A href="http://forums13.itrc.hp.com/service/forums/questionanswer.do?threadId=51050" target="_blank"&gt;http://forums13.itrc.hp.com/service/forums/questionanswer.do?threadId=51050&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;This link or the two sysadmin scripts that came first which are linked internally is a wealth of scripts that do what you need.&lt;BR /&gt;&lt;BR /&gt;What you are asking for has done, or can be done with one of the scripts in the thread, with minimal modification.&lt;BR /&gt;&lt;BR /&gt;SEP</description>
      <pubDate>Tue, 04 May 2010 15:19:11 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628282#M378192</guid>
      <dc:creator>Steven E. Protter</dc:creator>
      <dc:date>2010-05-04T15:19:11Z</dc:date>
    </item>
    <item>
      <title>Re: Memory Usage by process - Always the BIG ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628283#M378193</link>
      <description>Hi shab1207,&lt;BR /&gt;&lt;BR /&gt;    have you tried kmeminfo ?&lt;BR /&gt;&lt;BR /&gt;i am sure kmeminfo will serve your purpose. It will give you full listing of all individual processes alongwith pid and owner.I found it more than sufficient.</description>
      <pubDate>Tue, 04 May 2010 15:21:17 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628283#M378193</guid>
      <dc:creator>Pulse001</dc:creator>
      <dc:date>2010-05-04T15:21:17Z</dc:date>
    </item>
    <item>
      <title>Re: Memory Usage by process - Always the BIG ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628284#M378194</link>
      <description>Thanks...&lt;BR /&gt;&lt;BR /&gt;Can you please share your kmeminfo script.&lt;BR /&gt;I am always confused when it comes to expressing in terms of %.&lt;BR /&gt;so if you could help me with the calculation as well&lt;BR /&gt;Thanks in advance</description>
      <pubDate>Tue, 04 May 2010 15:26:40 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628284#M378194</guid>
      <dc:creator>shab1207</dc:creator>
      <dc:date>2010-05-04T15:26:40Z</dc:date>
    </item>
    <item>
      <title>Re: Memory Usage by process - Always the BIG ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628285#M378195</link>
      <description>hi shab1207,&lt;BR /&gt;&lt;BR /&gt;kmeminfo will show your total memory, free memory , memory consumed by user processes and memory consumed by system / kernel, in absolute value as well as percentage.&lt;BR /&gt;&lt;BR /&gt;A sample kmeminfo output will look like as below:-&lt;BR /&gt;&lt;BR /&gt;tool: kmeminfo 7.10 - HP CONFIDENTIAL&lt;BR /&gt;unix: /stand/current/vmunix 11.23 64bit IA64 on host &lt;BR /&gt;core: /dev/kmem live&lt;BR /&gt;link: Mon Mar 15 08:34:12 GMT 2010&lt;BR /&gt;boot: Fri Mar 19 05:07:26 2010&lt;BR /&gt;time: Wed Mar 31 07:26:56 2010&lt;BR /&gt;nbpg: 4096 bytes&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;----------------------------------------------------------------------&lt;BR /&gt;Physical memory usage summary (in page/byte/percent):&lt;BR /&gt;&lt;BR /&gt;Physical memory       =  3144280   12.0g 100%  &lt;BR /&gt;Free memory           =    95835  374.4m   3%  &lt;BR /&gt;User processes        =  2200622    8.4g  70%  details with -user&lt;BR /&gt;System                =   753301    2.9g  24%  &lt;BR /&gt;  Kernel              =   441570    1.7g  14%  kernel text and data&lt;BR /&gt;    Dynamic Arenas    =   158320  618.4m   5%  details with -arena&lt;BR /&gt;      vx_global_pool  =    34657  135.4m   1%  &lt;BR /&gt;      vx_inode_cache  =    23437   91.6m   1%  &lt;BR /&gt;      spinlock        =    22553   88.1m   1%  &lt;BR /&gt;      VFD_BT_NODE     =    14870   58.1m   0%  &lt;BR /&gt;      vm_pfn2v_arena  =    12340   48.2m   0%  &lt;BR /&gt;      Other arenas    =    50463  197.1m   2%  details with -arena&lt;BR /&gt;    Super page pool   =    22983   89.8m   1%  details with -kas&lt;BR /&gt;    DMA32 free pool   =    65464  255.7m   2%  &lt;BR /&gt;    Static Tables     =   148791  581.2m   5%  details with -static&lt;BR /&gt;      pfdat           =    73694  287.9m   2%  &lt;BR /&gt;      nbuf            =    34544  134.9m   1%  bufcache headers&lt;BR /&gt;      vhpt            =    16384   64.0m   1%  &lt;BR /&gt;      bufhash         =     8192   32.0m   0%  bufcache hash headers&lt;BR /&gt;      text            =     7414   29.0m   0%  vmunix text section&lt;BR /&gt;      Other tables    =     8562   33.4m   0%  details with -static&lt;BR /&gt;  Buffer cache        =   311731    1.2g  10%  details with -bufcache&lt;BR /&gt;  UFC file mrg        =        0     0.0   0%  &lt;BR /&gt;  UFC meta mrg        =        0     0.0   0%  &lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;If you do a kmeminfo -user, it will show you memory consumption of each process (in mb / gb) alongwith pid and ppid.&lt;BR /&gt;&lt;BR /&gt;----------------------------------------------------------------------&lt;BR /&gt;Summary of processes memory usage:&lt;BR /&gt;&lt;BR /&gt;List sorted by physical size, in pages/bytes:&lt;BR /&gt;&lt;BR /&gt;                              virtual        physical            swap &lt;BR /&gt;       pid       ppid   pages / bytes   pages / bytes   pages / bytes  command&lt;BR /&gt;     12681      12665  884774    3.4g  336345    1.3g  343144    1.3g  java_q4p&lt;BR /&gt;     29064      29048  383931    1.5g  296866    1.1g  299612    1.1g  java&lt;BR /&gt;     13127      13111  274445    1.0g  209538  818.5m  212907  831.7m  java&lt;BR /&gt;     18271          1  349614    1.3g  171990  671.8m  174315  680.9m  java&lt;BR /&gt;     27912          1   96174  375.7m   70163  274.1m   71268  278.4m  cleard&lt;BR /&gt;     16852          1  335227    1.3g   67946  265.4m   70956  277.2m  java&lt;BR /&gt;     18266          1  334350    1.3g   67019  261.8m   70076  273.7m  java&lt;BR /&gt;     17470          1  333179    1.3g   66026  257.9m   68897  269.1m  java&lt;BR /&gt;     28104          1  333179    1.3g   65962  257.7m   68897  269.1m  java&lt;BR /&gt;     28062          1  336251    1.3g   60793  237.5m   63488  248.0m  java&lt;BR /&gt;     27982          1   89194  348.4m   58767  229.6m   64253  251.0m  cleard&lt;BR /&gt;     27935      27883  113894  444.9m   48737  190.4m  106043  414.2m  WSH&lt;BR /&gt;     27888      27883   83462  326.0m   47885  187.1m   75458  294.8m  WSH&lt;BR /&gt;     23972          1   92746  362.3m   43663  170.6m   67822  264.9m  cleard&lt;BR /&gt;     27980          1   63370  247.5m   37067  144.8m   38299  149.6m  cleard&lt;BR /&gt;     27913          1   60874  237.8m   34283  133.9m   35790  139.8m  cleard&lt;BR /&gt;     27981          1   64555  252.2m   34171  133.5m   39489  154.3m  cleard&lt;BR /&gt;     27911          1   59114  230.9m   32659  127.6m   34021  132.9m  cleard&lt;BR /&gt;     27932      27883   60774  237.4m   24281   94.8m   52656  205.7m  WSH&lt;BR /&gt;     27933      27883   57030  222.8m   21513   84.0m   48893  191.0m  WSH&lt;BR /&gt;     27931      27883   61254  239.3m   20909   81.7m   53138  207.6m  WSH&lt;BR /&gt;     27901      27883   56038  218.9m   20457   79.9m   47896  187.1m  WSH&lt;BR /&gt;     27934      27883   46246  180.6m   20021   78.2m   38055  148.7m  WSH&lt;BR /&gt;      1060          1   28781  112.4m   13654   53.3m   15334   59.9m  vxsvc&lt;BR /&gt;     27963          1   35434  138.4m    8923   34.9m   10223   39.9m  cleard&lt;BR /&gt;     27955          1   33898  132.4m    7571   29.6m    8679   33.9m  cleard&lt;BR /&gt;     27961          1   32266  126.0m    6107   23.9m    7039   27.5m  cleard&lt;BR /&gt;     27962          1   32491  126.9m    6027   23.5m    7264   28.4m  cleard&lt;BR /&gt;     27964          1   32490  126.9m    5935   23.2m    7264   28.4m  cleard&lt;BR /&gt;     27968          1   31786  124.2m    5772   22.5m    6557   25.6m  cleard&lt;BR /&gt;     27970          1   31370  122.5m    5376   21.0m    6139   24.0m  cleard&lt;BR /&gt;     27969          1   31370  122.5m    5372   21.0m    6139   24.0m  cleard&lt;BR /&gt;     27967          1   31786  124.2m    5292   20.7m    6557   25.6m  cleard&lt;BR /&gt;     23909          1   31242  122.0m    5039   19.7m    6010   23.5m  cleard&lt;BR /&gt;     23929          1   31242  122.0m    5039   19.7m    6010   23.5m  cleard&lt;BR /&gt;     27956          1   31114  121.5m    4991   19.5m    5881   23.0m  cleard&lt;BR /&gt;     27984          1   30731  120.0m    4515   17.6m    5495   21.5m  cleard&lt;BR /&gt;     27983          1   30538  119.3m    4319   16.9m    5302   20.7m  cleard&lt;BR /&gt;     27928          1   30282  118.3m    4299   16.8m    5045   19.7m  cleard&lt;BR /&gt;     27899          1   30474  119.0m    4267   16.7m    5238   20.5m  cleard&lt;BR /&gt;     27927          1   30218  118.0m    4227   16.5m    4980   19.5m  cleard&lt;BR /&gt;     27926          1   30186  117.9m    4187   16.4m    4948   19.3m  cleard&lt;BR /&gt;     27941          1   29994  117.2m    4015   15.7m    4755   18.6m  cleard&lt;BR /&gt;      1019          1   30122  117.7m    3907   15.3m    4884   19.1m  cleard&lt;BR /&gt;     27917          1   29866  116.7m    3875   15.1m    4627   18.1m  cleard&lt;BR /&gt;     27918          1   29866  116.7m    3867   15.1m    4627   18.1m  cleard&lt;BR /&gt;     27925          1   29866  116.7m    3863   15.1m    4627   18.1m  cleard&lt;BR /&gt;     27919          1   29834  116.5m    3851   15.0m    4594   17.9m  cleard&lt;BR /&gt;     27898          1   29834  116.5m    3847   15.0m    4594   17.9m  cleard&lt;BR /&gt;     27946          1   29834  116.5m    3831   15.0m    4594   17.9m  cleard&lt;BR /&gt;     27951          1   29802  116.4m    3827   14.9m    4562   17.8m  cleard&lt;BR /&gt;     27945          1   29802  116.4m    3823   14.9m    4562   17.8m  cleard&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;If you have a support contract with HP, you can ask for the kmeminfo script, they will provide you, it is free but not supported by HP.</description>
      <pubDate>Wed, 05 May 2010 03:43:51 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628285#M378195</guid>
      <dc:creator>Pulse001</dc:creator>
      <dc:date>2010-05-05T03:43:51Z</dc:date>
    </item>
    <item>
      <title>Re: Memory Usage by process - Always the BIG ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628286#M378196</link>
      <description>In fact kmeminfo was very helpful for me in doing an investigation for probable memory leak in my server. You can check the memoru consumption of a single process using kmeminfo as below:-&lt;BR /&gt;&lt;BR /&gt;#kmeminfo &lt;PID&gt;&lt;BR /&gt;&lt;BR /&gt;We had a process which was crashing and throwing "out of memory" error everytime load was put on it.The application vendor as usual was pointing finger at the OS. When i checked the memory footprint of that process using kmeminfo, i found it started with 1gb and subsequently increased to 4 gb ,after which the process crashed. I presented the memory consumption of that process to my application vendor and they had to agree that there was indeed a memory leak in their process and did the resolution at their end.&lt;BR /&gt;&lt;BR /&gt;&lt;/PID&gt;</description>
      <pubDate>Wed, 05 May 2010 03:51:04 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628286#M378196</guid>
      <dc:creator>Pulse001</dc:creator>
      <dc:date>2010-05-05T03:51:04Z</dc:date>
    </item>
    <item>
      <title>Re: Memory Usage by process - Always the BIG ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628287#M378197</link>
      <description>Still dosent answer my query.&lt;BR /&gt;none of the scripts still address the query.&lt;BR /&gt;&lt;BR /&gt;Expressing process using highest memory in terms of percent.&lt;BR /&gt;seems everyone is running away from the fact since it is truely difficult to get this thing calculated due to swap,core,physical memory etc.. and this makes it truely impossible.</description>
      <pubDate>Thu, 06 May 2010 14:05:23 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628287#M378197</guid>
      <dc:creator>shab1207</dc:creator>
      <dc:date>2010-05-06T14:05:23Z</dc:date>
    </item>
    <item>
      <title>Re: Memory Usage by process - Always the BIG ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628288#M378198</link>
      <description>hi shab,&lt;BR /&gt;&lt;BR /&gt;  i think my response was clear enough and shows memory usage per process basis.&lt;BR /&gt;&lt;BR /&gt; calculating the percent when you have absolute values ( e.g 3.4gb out of 12gb ) is not rocket science.</description>
      <pubDate>Thu, 06 May 2010 15:36:51 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628288#M378198</guid>
      <dc:creator>Pulse001</dc:creator>
      <dc:date>2010-05-06T15:36:51Z</dc:date>
    </item>
    <item>
      <title>Re: Memory Usage by process - Always the BIG ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628289#M378199</link>
      <description>Hi pulse,&lt;BR /&gt;&lt;BR /&gt;How would the % be calculated since a process will occupy physical,virtual and swap memory.&lt;BR /&gt;Now while calculating the % should i do a &lt;BR /&gt;&lt;BR /&gt;(occupied physical +  occupied virtual + occupied swap ) / (total physical +  total virtual + total swap ) * 100 &lt;BR /&gt;I dont these calculations are as simple as you indicate</description>
      <pubDate>Thu, 06 May 2010 15:40:57 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628289#M378199</guid>
      <dc:creator>shab1207</dc:creator>
      <dc:date>2010-05-06T15:40:57Z</dc:date>
    </item>
    <item>
      <title>Re: Memory Usage by process - Always the BIG ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628290#M378200</link>
      <description>Well, your calculation would be less than simple -- but that's also because it is less than obvious that it would have any real meaning. A process consuming a lot of virtual memory may not be consuming any swap or any physical memory at all (mmap() a very large file without touching the mapping and you get just this). Or it could be consuming a lot of virtual+swap but no physical (large swap-backed object) or it could be consuming a lot of physical and virtual memory with no swap (touching that mapping mentioned before), etc.&lt;BR /&gt;&lt;BR /&gt;So I don't get at all what you're asking. There's no real concept of a process using a percentage of "total system resources", each resource type has some relation to the other, but a tenuous one in most cases and should be analyzed separately. &lt;BR /&gt;&lt;BR /&gt;Here's something which might get you going. If you really, really want to add up the totals for some reason, the framework is there (add a field for total_global or something and each proc_global would += (proc_phys + proc_virt + proc_swap + proc_mlock), keep a top_global -- and then you can do the comparison to (sbuf.physical_memory + dbuf.psd_vm + vbuf.psv_swapspc_max + vbuf.psv_swapmem_max + vbuf.psv_swapmem_max) [fudging a little in just calling Memory Swap maximum the maximum for Lockable memory -- it is actually a little lower, depending on OS version and tunables, etc.] I don't see the point -- but there you go.&lt;BR /&gt;&lt;BR /&gt;Sample output (and I don't write UIs, so yes, this is probably ugly):&lt;BR /&gt;&lt;BR /&gt;Memory Stat      total    used   avail   %used&lt;BR /&gt;physical        11591.2 2502.7  9088.6     22%&lt;BR /&gt;active virtual   712.6   527.4   185.2     74%&lt;BR /&gt;active real      385.9   274.1   111.8     71%&lt;BR /&gt;memory swap     11024.8 1528.6  9496.2     14%&lt;BR /&gt;device swap     8192.0   405.1  7786.9      5%&lt;BR /&gt;Activations: 0 total, 0 rate.   Deactivations: 0 total, 0 rate.&lt;BR /&gt;Reclaims from Swap: 0 total (Up 0), 0 rate.&lt;BR /&gt;Top Physical PID: [cimprovagt] 1534 Phys: 100 Mb (0.8687%) of RAM.&lt;BR /&gt;Top Virtual PID: [cimprovagt] 1534 Virt: 436 Mb (61.2214%) of Total Virt.&lt;BR /&gt;Top Swap PID: [cimprovagt] 1534 Swap: 79 Mb (0.4159%) of Total Swap.&lt;BR /&gt;Top Mlock PID: [midaemon] 1913 Mlock: 32 Mb (0.2967%) of Memory Swap.&lt;BR /&gt;&lt;BR /&gt;The numbers don't line up 100% with kmeminfo -- but pstat tries to account for shared object references more than kmeminfo does, so that isn't surprising.&lt;BR /&gt;&lt;BR /&gt;Also, the Total Virtual resource is really unknown. Since the virtual space reported includes files, we'd have to know the maximum space of any and all filesystems ever to be attached, etc. The kernel doesn't bother predicting that and as such, doesn't report it (we'd need max file space + max swap + memory swap to equal the absolute total Virtual space). So that "Total Virt" is really the current total virtual load of User space.</description>
      <pubDate>Thu, 06 May 2010 16:20:44 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628290#M378200</guid>
      <dc:creator>Don Morris_1</dc:creator>
      <dc:date>2010-05-06T16:20:44Z</dc:date>
    </item>
    <item>
      <title>Re: Memory Usage by process - Always the BIG ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628291#M378201</link>
      <description>Hi Don,&lt;BR /&gt;&lt;BR /&gt;I think I am getting a great sign of hope now.&lt;BR /&gt;&lt;BR /&gt;Even I think i am confused but I will explain -&lt;BR /&gt;A simple summarization of the % of the HPUX memory being consumed and the process occuping the highest % of memory &lt;BR /&gt;&lt;BR /&gt;Need a perl or shell script :(</description>
      <pubDate>Thu, 06 May 2010 16:30:07 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628291#M378201</guid>
      <dc:creator>shab1207</dc:creator>
      <dc:date>2010-05-06T16:30:07Z</dc:date>
    </item>
    <item>
      <title>Re: Memory Usage by process - Always the BIG ?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628292#M378202</link>
      <description>&amp;gt; looking for some script which may really provide a consolidate memory usage status and process taking max memory...&lt;BR /&gt;&amp;gt; Expressing process using highest memory in terms of percent.&lt;BR /&gt; &lt;BR /&gt;This really won't provide any useful information. A memory leak is nothing but a programming artifact...it may be intentional (the program needs more memory) or unintentional and therefore a leak. But knowing what percentage of RAM a single process is using is like trying to fix a filesystem by looking for big files. All the big files (or processes) are running as designed, and the real problem is with dozens of smaller files (or processes) that are not supposed to be growing.&lt;BR /&gt; &lt;BR /&gt;So let's assume that the program using the largest amount of local or heap memory is Java and it has a resident set size of 2000MB. Do you know how to rewrite the Java code to not use so much memory? If not, then all you can do is apply the latest patches and buy more RAM if necessary.&lt;BR /&gt; &lt;BR /&gt;Or perhaps it is shared memory (which is not part of local memory for any process, but Oracle requested 5000MB. So it is using a lot of memory but you must talk to the DBA about this usage. You may be informed that to reduce it to 1000MB means that all Oracle transactions will take 500% longer to complete.&lt;BR /&gt; &lt;BR /&gt;The amount of memory used by each process is a function of how it was written. While you can impose a memory limit for each process, the majority of programs will simply crash with an errno 12 message (not enough core). So you will have solved the problem for programs that take more than the allowed space but no one gets any work done.&lt;BR /&gt;</description>
      <pubDate>Thu, 06 May 2010 17:45:34 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/memory-usage-by-process-always-the-big/m-p/4628292#M378202</guid>
      <dc:creator>Bill Hassell</dc:creator>
      <dc:date>2010-05-06T17:45:34Z</dc:date>
    </item>
  </channel>
</rss>

