<?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: Who is using swap space? in Operating System - Tru64 Unix</title>
    <link>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292280#M12544</link>
    <description>&amp;gt;&amp;gt;How did You observed this? The behaviour seems absolutely rediculose, unless ubc_min_percent hit.&lt;BR /&gt;&lt;BR /&gt;I did vmstat -R 1 (or 10 instead of 1) and vmubc -tty -swap -memory (please look at the webpage mentioned in my GS1280 swap thread threadId=859125 for details). Read a big file to fill the UBC,&lt;BR /&gt;started a memory consuming testprogram and&lt;BR /&gt;swapping started before ubc_minpercent and borrowpercent was hit. I am not quite sure if&lt;BR /&gt;actu was not lowered or not lowered enough to&lt;BR /&gt;avoid swapping. I will have a look to my logfiles or repeat the experiment later, because I dont have time now and put the original data to my mentioned webpage.&lt;BR /&gt;&lt;BR /&gt;Your attachement:&lt;BR /&gt;a snapshot is not enough, do a vmstat -R 60 (or so). vmubc would be good too. &lt;BR /&gt;Have a look to the free pages of each RAD. Looks like RAD0 and RAD1 where&lt;BR /&gt;temporary out of memory (high acti and pout).&lt;BR /&gt;If so, you triggered a kernel bug or&lt;BR /&gt;however HP call that misbehaviours (see my thread). But its not for sure, not enough data from you (and HPs engineers) to find out, what exactly goes wrong.&lt;BR /&gt;</description>
    <pubDate>Fri, 13 May 2005 07:03:07 GMT</pubDate>
    <dc:creator>Joerg Schulenburg</dc:creator>
    <dc:date>2005-05-13T07:03:07Z</dc:date>
    <item>
      <title>Who is using swap space?</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292265#M12529</link>
      <description>I've got Tru64 5.1A pk3, Oracle, swpamode=lazy.&lt;BR /&gt;&lt;BR /&gt;The system configured so that Oracle fits in memory, and system does not use swap space at all.&lt;BR /&gt;&lt;BR /&gt;From time to time (~1 per 3 months) someone consumes all the swap so Kernel finally kills &lt;BR /&gt;Oracle's pmon :-(((&lt;BR /&gt;so I've got to reboot the system.&lt;BR /&gt;&lt;BR /&gt;Now I caught up the situation:&lt;BR /&gt;avrumo06&amp;gt; /sbin/swapon -s                        &lt;BR /&gt;Swap partition /dev/disk/dsk1h:                  &lt;BR /&gt;    Allocated space:      1855713 pages (14.16GB)&lt;BR /&gt;    In-use space:          522018 pages ( 28%)   &lt;BR /&gt;    Free space:           1333695 pages ( 71%)   &lt;BR /&gt;  &lt;BR /&gt;Total swap allocation:                           &lt;BR /&gt;    Allocated space:      1855713 pages (14.16GB)&lt;BR /&gt;    In-use space:          522018 pages ( 28%)   &lt;BR /&gt;    Available space:      1333695 pages ( 71%)   &lt;BR /&gt;&lt;BR /&gt;vmstat shows 261K pages (Over 1 GB) free. (I can attach output if needed)&lt;BR /&gt;&lt;BR /&gt;See ps aux output attached.  &lt;BR /&gt;&lt;BR /&gt;How can I identify which process used swap?&lt;BR /&gt;If i'll kill the process, will the swap space be released?&lt;BR /&gt;</description>
      <pubDate>Tue, 01 Jun 2004 10:15:47 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292265#M12529</guid>
      <dc:creator>Alexey Borchev</dc:creator>
      <dc:date>2004-06-01T10:15:47Z</dc:date>
    </item>
    <item>
      <title>Re: Who is using swap space?</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292266#M12530</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;root              0  0.7  3.4 20.3G 554M ??       R &amp;lt;    Mar 17  2-12:02:07 [kernel idle]&lt;BR /&gt;&lt;BR /&gt;this seems to be a lot!&lt;BR /&gt;Can you post&lt;BR /&gt;sysconfig -q proc&lt;BR /&gt;sysconfig -q vm&lt;BR /&gt;sysconfig -q ipc&lt;BR /&gt;?&lt;BR /&gt;&lt;BR /&gt;greetings,&lt;BR /&gt;&lt;BR /&gt;Michael&lt;BR /&gt;</description>
      <pubDate>Tue, 01 Jun 2004 12:04:11 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292266#M12530</guid>
      <dc:creator>Michael Schulte zur Sur</dc:creator>
      <dc:date>2004-06-01T12:04:11Z</dc:date>
    </item>
    <item>
      <title>Re: Who is using swap space?</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292267#M12531</link>
      <description>swapping is a normal system behaviour, there is no way to block oder prevent swapping! If the system is out of free pages it will swap. The ps output will also give the virtual memory information. There are also processes which always allocated swap space.&lt;BR /&gt;&lt;BR /&gt;Be sure Oracle supports lazy mode, "supports" means here the company Oracle have tested and qualified and recommended this mode. It is not a technical aspect it is an aspect of "support".&lt;BR /&gt;&lt;BR /&gt;If the system is out of virtual memory there is a process allocating and use the memory or there is a memory leak leading to such behaviour. Monitor your system to get the root cause of the problem.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Tue, 01 Jun 2004 12:08:57 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292267#M12531</guid>
      <dc:creator>Ralf Puchner</dc:creator>
      <dc:date>2004-06-01T12:08:57Z</dc:date>
    </item>
    <item>
      <title>Re: Who is using swap space?</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292268#M12532</link>
      <description>ipc:&lt;BR /&gt;msg_max = 8192&lt;BR /&gt;msg_mnb = 16384&lt;BR /&gt;msg_mni = 64&lt;BR /&gt;msg_tql = 40&lt;BR /&gt;shm_max = 16106127360&lt;BR /&gt;shm_min = 1&lt;BR /&gt;shm_mni = 128&lt;BR /&gt;shm_seg = 32&lt;BR /&gt;sem_mni = 16&lt;BR /&gt;sem_msl = 25&lt;BR /&gt;sem_opm = 10&lt;BR /&gt;sem_ume = 10&lt;BR /&gt;sem_vmx = 32767&lt;BR /&gt;sem_aem = 16384&lt;BR /&gt;sem_broadcast_wakeup = 1&lt;BR /&gt;max_kernel_ports = 93728&lt;BR /&gt;ssm_threshold = 8388608&lt;BR /&gt;ssm_enable_core_dump = 1&lt;BR /&gt;shm_allocate_striped = 1&lt;BR /&gt;shm_enable_core_dump = 1&lt;BR /&gt;&lt;BR /&gt;proc:&lt;BR /&gt;max_proc_per_user = 320&lt;BR /&gt;max_threads_per_user = 1024&lt;BR /&gt;per_proc_stack_size = 8388608&lt;BR /&gt;max_per_proc_stack_size = 33554432&lt;BR /&gt;per_proc_data_size = 17179869184&lt;BR /&gt;max_per_proc_data_size = 17179869184&lt;BR /&gt;max_per_proc_address_space = 17179869184&lt;BR /&gt;per_proc_address_space = 17179869184&lt;BR /&gt;executable_stack = 0&lt;BR /&gt;autonice = 0&lt;BR /&gt;autonice_time = 600&lt;BR /&gt;autonice_penalty = 4&lt;BR /&gt;open_max_soft = 4096&lt;BR /&gt;open_max_hard = 4096&lt;BR /&gt;ncallout_alloc_size = 8192&lt;BR /&gt;round_robin_switch_rate = 60&lt;BR /&gt;sched_min_idle = 0&lt;BR /&gt;give_boost = 1&lt;BR /&gt;maxusers = 1024&lt;BR /&gt;num_wait_queues = 1024&lt;BR /&gt;num_timeout_hash_queues = 1024&lt;BR /&gt;enhanced_core_name = 0&lt;BR /&gt;enhanced_core_max_versions = 16&lt;BR /&gt;exec_disable_arg_limit = 0&lt;BR /&gt;dump_cores = 1&lt;BR /&gt;dump_setugid_cores = 0&lt;BR /&gt;executable_data = 0&lt;BR /&gt;&lt;BR /&gt;vm:&lt;BR /&gt;ubc_minpercent = 5&lt;BR /&gt;ubc_maxpercent = 50&lt;BR /&gt;ubc_borrowpercent = 5&lt;BR /&gt;vm_max_wrpgio_kluster = 32768&lt;BR /&gt;vm_max_rdpgio_kluster = 16384&lt;BR /&gt;vm_cowfaults = 4&lt;BR /&gt;vm_segmentation = 1&lt;BR /&gt;vm_ubcpagesteal = 24&lt;BR /&gt;vm_ubcfilemaxdirtypages = 4294967295&lt;BR /&gt;vm_ubcdirtypercent = 40&lt;BR /&gt;ubc_maxdirtywrites = 5&lt;BR /&gt;ubc_maxdirtymetadata_pcnt = 70&lt;BR /&gt;ubc_kluster_cnt = 32&lt;BR /&gt;vm_ubcseqstartpercent = 50&lt;BR /&gt;vm_ubcseqpercent = 10&lt;BR /&gt;vm_csubmapsize = 1048576&lt;BR /&gt;vm_ubcbuffers = 256&lt;BR /&gt;vm_syncswapbuffers = 128&lt;BR /&gt;vm_asyncswapbuffers = 4&lt;BR /&gt;vm_clustermap = 1048576&lt;BR /&gt;vm_clustersize = 65536&lt;BR /&gt;vm_syswiredpercent = 80&lt;BR /&gt;vm_troll_percent = 4&lt;BR /&gt;vm_inswappedmin = 1&lt;BR /&gt;vm_page_free_target = 1024&lt;BR /&gt;vm_page_free_swap = 522&lt;BR /&gt;vm_page_free_hardswap = 16384&lt;BR /&gt;vm_page_free_min = 20&lt;BR /&gt;vm_page_free_reserved = 10&lt;BR /&gt;vm_page_free_optimal = 522&lt;BR /&gt;vm_swap_eager = 0&lt;BR /&gt;swapdevice = /dev/disk/dsk1h&lt;BR /&gt;vm_page_prewrite_target = 2048&lt;BR /&gt;vm_ffl = 1&lt;BR /&gt;ubc_ffl = 1&lt;BR /&gt;vm_rss_maxpercent = 100&lt;BR /&gt;anon_rss_enforce = 0&lt;BR /&gt;vm_rss_block_target = 522&lt;BR /&gt;vm_rss_wakeup_target = 522&lt;BR /&gt;kernel_stack_pages = 0&lt;BR /&gt;vm_min_kernel_address = 18446741891866165248&lt;BR /&gt;malloc_percpu_cache = 1&lt;BR /&gt;vm_aggressive_swap = 0&lt;BR /&gt;new_wire_method = 0&lt;BR /&gt;vm_segment_cache_max = 50&lt;BR /&gt;gh_chunks = 0&lt;BR /&gt;rad_gh_regions[0] = 0&lt;BR /&gt;rad_gh_regions[1] = 0&lt;BR /&gt;rad_gh_regions[2] = 0&lt;BR /&gt;rad_gh_regions[3] = 0&lt;BR /&gt;rad_gh_regions[4] = 0&lt;BR /&gt;rad_gh_regions[5] = 0&lt;BR /&gt;rad_gh_regions[6] = 0&lt;BR /&gt;rad_gh_regions[7] = 0&lt;BR /&gt;rad_gh_regions[8] = 0&lt;BR /&gt;rad_gh_regions[9] = 0&lt;BR /&gt;rad_gh_regions[10] = 0&lt;BR /&gt;rad_gh_regions[11] = 0&lt;BR /&gt;rad_gh_regions[12] = 0&lt;BR /&gt;rad_gh_regions[13] = 0&lt;BR /&gt;rad_gh_regions[14] = 0&lt;BR /&gt;rad_gh_regions[15] = 0&lt;BR /&gt;rad_gh_regions[16] = 0&lt;BR /&gt;rad_gh_regions[17] = 0&lt;BR /&gt;rad_gh_regions[18] = 0&lt;BR /&gt;rad_gh_regions[19] = 0&lt;BR /&gt;rad_gh_regions[20] = 0&lt;BR /&gt;rad_gh_regions[21] = 0&lt;BR /&gt;rad_gh_regions[22] = 0&lt;BR /&gt;rad_gh_regions[23] = 0&lt;BR /&gt;rad_gh_regions[24] = 0&lt;BR /&gt;rad_gh_regions[25] = 0&lt;BR /&gt;rad_gh_regions[26] = 0&lt;BR /&gt;rad_gh_regions[27] = 0&lt;BR /&gt;rad_gh_regions[28] = 0&lt;BR /&gt;rad_gh_regions[29] = 0&lt;BR /&gt;rad_gh_regions[30] = 0&lt;BR /&gt;rad_gh_regions[31] = 0&lt;BR /&gt;rad_gh_regions[32] = 0&lt;BR /&gt;rad_gh_regions[33] = 0&lt;BR /&gt;rad_gh_regions[34] = 0&lt;BR /&gt;rad_gh_regions[35] = 0&lt;BR /&gt;rad_gh_regions[36] = 0&lt;BR /&gt;rad_gh_regions[37] = 0&lt;BR /&gt;rad_gh_regions[38] = 0&lt;BR /&gt;rad_gh_regions[39] = 0&lt;BR /&gt;rad_gh_regions[40] = 0&lt;BR /&gt;rad_gh_regions[41] = 0&lt;BR /&gt;rad_gh_regions[42] = 0&lt;BR /&gt;rad_gh_regions[43] = 0&lt;BR /&gt;rad_gh_regions[44] = 0&lt;BR /&gt;rad_gh_regions[45] = 0&lt;BR /&gt;rad_gh_regions[46] = 0&lt;BR /&gt;rad_gh_regions[47] = 0&lt;BR /&gt;rad_gh_regions[48] = 0&lt;BR /&gt;rad_gh_regions[49] = 0&lt;BR /&gt;rad_gh_regions[50] = 0&lt;BR /&gt;rad_gh_regions[51] = 0&lt;BR /&gt;rad_gh_regions[52] = 0&lt;BR /&gt;rad_gh_regions[53] = 0&lt;BR /&gt;rad_gh_regions[54] = 0&lt;BR /&gt;rad_gh_regions[55] = 0&lt;BR /&gt;rad_gh_regions[56] = 0&lt;BR /&gt;rad_gh_regions[57] = 0&lt;BR /&gt;rad_gh_regions[58] = 0&lt;BR /&gt;rad_gh_regions[59] = 0&lt;BR /&gt;rad_gh_regions[60] = 0&lt;BR /&gt;rad_gh_regions[61] = 0&lt;BR /&gt;rad_gh_regions[62] = 0&lt;BR /&gt;rad_gh_regions[63] = 0&lt;BR /&gt;gh_min_seg_size = 4194304&lt;BR /&gt;gh_fail_if_no_mem = 1&lt;BR /&gt;private_cache_percent = 0&lt;BR /&gt;gh_keep_sorted = 0&lt;BR /&gt;gh_front_alloc = 1&lt;BR /&gt;replicate_user_text = 1&lt;BR /&gt;enable_yellow_zone = 0&lt;BR /&gt;boost_pager_priority = 0&lt;BR /&gt;kstack_free_target = 5&lt;BR /&gt;wire_audit_count = 0&lt;BR /&gt;vm_prepop_percent = 100&lt;BR /&gt;</description>
      <pubDate>Tue, 01 Jun 2004 12:28:04 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292268#M12532</guid>
      <dc:creator>Alexey Borchev</dc:creator>
      <dc:date>2004-06-01T12:28:04Z</dc:date>
    </item>
    <item>
      <title>Re: Who is using swap space?</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292269#M12533</link>
      <description>Yes, I've got 16 GB Ram, 12 is given to Oracle, it seems Oracle is happy with it so far.&lt;BR /&gt;&lt;BR /&gt;It's strange that Kernel idle maps not 16, but 20.5 GB.&lt;BR /&gt;Is it 16 GB Ram + Swap in-use space?&lt;BR /&gt;&lt;BR /&gt;Any ideas about identifying resource user?&lt;BR /&gt;Otherwice i'll have to reboot my system - opportunity will be lost.&lt;BR /&gt;&lt;BR /&gt;P.S.&lt;BR /&gt;It decreased slightly:&lt;BR /&gt; In-use space:          521399 pages ( 28%)&lt;BR /&gt;&lt;BR /&gt;Maybe, it worth try to kill swapped out processes (which has W in ps aux)?&lt;BR /&gt;</description>
      <pubDate>Tue, 01 Jun 2004 12:40:30 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292269#M12533</guid>
      <dc:creator>Alexey Borchev</dc:creator>
      <dc:date>2004-06-01T12:40:30Z</dc:date>
    </item>
    <item>
      <title>Re: Who is using swap space?</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292270#M12534</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;ubc_maxpercent = 50&lt;BR /&gt;this seems too much to me. I would reduce it to 20. You can do this online with syscongfig.&lt;BR /&gt;&lt;BR /&gt;hth,&lt;BR /&gt;&lt;BR /&gt;Michael</description>
      <pubDate>Tue, 01 Jun 2004 13:05:37 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292270#M12534</guid>
      <dc:creator>Michael Schulte zur Sur</dc:creator>
      <dc:date>2004-06-01T13:05:37Z</dc:date>
    </item>
    <item>
      <title>Re: Who is using swap space?</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292271#M12535</link>
      <description>Michael,&lt;BR /&gt;&lt;BR /&gt;come on, this parameter is not within my coffee-cup.... ;-)&lt;BR /&gt;&lt;BR /&gt;Alexey,&lt;BR /&gt;&lt;BR /&gt;are you sure you configured the machine as described within the Oracle tuning guide? The values must be calculated depending your needs and reflecting your database setup. So posting the sysconfigtab informations doesn't really help to analyze the problem without knowing your complete setup and dependencies.&lt;BR /&gt;&lt;BR /&gt;Use "collect" to monitor the system and to get a clue what is going on. But as described in my previous posting swapping is normal. With the tool you will get the time and memory usage also the dependencies (I/O etc.)&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Tue, 01 Jun 2004 15:30:33 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292271#M12535</guid>
      <dc:creator>Ralf Puchner</dc:creator>
      <dc:date>2004-06-01T15:30:33Z</dc:date>
    </item>
    <item>
      <title>Re: Who is using swap space?</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292272#M12536</link>
      <description>If this occurs after a couple of months, you might have a memory leak somewhere.&lt;BR /&gt;You can use the command&lt;BR /&gt;   # vmstat -M&lt;BR /&gt;and monitor if a particular bucketsize and memory type is growing constantly.&lt;BR /&gt;&lt;BR /&gt;Joris</description>
      <pubDate>Wed, 02 Jun 2004 01:43:35 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292272#M12536</guid>
      <dc:creator>Joris Denayer</dc:creator>
      <dc:date>2004-06-02T01:43:35Z</dc:date>
    </item>
    <item>
      <title>Re: Who is using swap space?</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292273#M12537</link>
      <description>&lt;BR /&gt;1) Michael, i'll try to&lt;BR /&gt;ubc_maxpercent = 50 -&amp;gt; 20&lt;BR /&gt;but I'll wait for less busy period.&lt;BR /&gt;As far as i understand, Trunix will not swap out filesystem cache - it will shrink it instead.&lt;BR /&gt;&lt;BR /&gt;2) I've run vmstat -M see attachment.&lt;BR /&gt;Total memory being used from buckets = 99444208 bytes&lt;BR /&gt;Total free memory in buckets = 26347376 bytes&lt;BR /&gt;- i.e. here only 100 MB, I am looking for 4.5 GB. &lt;BR /&gt;&lt;BR /&gt;3) I'll read &amp;amp; try collect, thanks.&lt;BR /&gt;&lt;BR /&gt;4) Currently I've got 187K free mem pages, &lt;BR /&gt;and 520670 pages used in swap space.&lt;BR /&gt;-Why Unix does not read it back into memory?&lt;BR /&gt;- Swap usage is slightly decreased. May be some swapped out processes was terminated?&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Wed, 02 Jun 2004 06:35:57 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292273#M12537</guid>
      <dc:creator>Alexey Borchev</dc:creator>
      <dc:date>2004-06-02T06:35:57Z</dc:date>
    </item>
    <item>
      <title>Re: Who is using swap space?</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292274#M12538</link>
      <description>Hi Alexej,&lt;BR /&gt;A leak is not yet visible, short after a reboot.&lt;BR /&gt;Try this command again each week. &lt;BR /&gt;&lt;BR /&gt;If there is a leak, you will see if one of the buckets/memory types is increasing.&lt;BR /&gt;&lt;BR /&gt;Joris&lt;BR /&gt;</description>
      <pubDate>Wed, 02 Jun 2004 06:51:44 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292274#M12538</guid>
      <dc:creator>Joris Denayer</dc:creator>
      <dc:date>2004-06-02T06:51:44Z</dc:date>
    </item>
    <item>
      <title>Re: Who is using swap space?</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292275#M12539</link>
      <description>Swap space usage decreased:&lt;BR /&gt;&lt;BR /&gt;Currently &lt;BR /&gt;In-use space  11551 pages (  0%) &lt;BR /&gt;&lt;BR /&gt;Oracle instance was re-started during weekend. (Cold backup)&lt;BR /&gt;&lt;BR /&gt;Imho, some Oracle processes where swapped-out, then loaded back into memory, but swap space was still reserved for the process.&lt;BR /&gt;Swap space was released when process terminated.&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Mon, 07 Jun 2004 06:17:59 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292275#M12539</guid>
      <dc:creator>Alexey Borchev</dc:creator>
      <dc:date>2004-06-07T06:17:59Z</dc:date>
    </item>
    <item>
      <title>Re: Who is using swap space?</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292276#M12540</link>
      <description>You can switch off swap editing /etc/sysconfigtab removing swapdevice entry.&lt;BR /&gt;You can add swap space on runtime if you need it again.&lt;BR /&gt;I thought that you can identify swapping process only indirect by looking for large&lt;BR /&gt;vsz-rss (ps aux), high syscall and idle activity.&lt;BR /&gt;I have problems using more than 16GB on &lt;BR /&gt;a 128GB GS1280 with 32 CPUs without swapping,&lt;BR /&gt;where the vm system&lt;BR /&gt;does strange things (see &lt;A href="http://www.uni-magdeburg.de/urzs/marvel/vmbug3.html)" target="_blank"&gt;http://www.uni-magdeburg.de/urzs/marvel/vmbug3.html)&lt;/A&gt;&lt;BR /&gt;</description>
      <pubDate>Mon, 18 Apr 2005 06:06:45 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292276#M12540</guid>
      <dc:creator>Joerg Schulenburg</dc:creator>
      <dc:date>2005-04-18T06:06:45Z</dc:date>
    </item>
    <item>
      <title>Re: Who is using swap space?</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292277#M12541</link>
      <description>&amp;gt;&amp;gt;As far as i understand, Trunix will not swap out filesystem cache - it will shrink it instead.&lt;BR /&gt;&lt;BR /&gt;My experiences are otherwise. Tru64 takes swap instead of shrinking UBC.&lt;BR /&gt;&lt;BR /&gt;&amp;gt;&amp;gt;Why Unix does not read it back into memory?&lt;BR /&gt;&lt;BR /&gt;Unix does, Tru64 does not :(&lt;BR /&gt;I think the philosophy behint is, that the&lt;BR /&gt;pages read from the swap are cached and if&lt;BR /&gt;memory again is low only cached pages has to&lt;BR /&gt;be released.&lt;BR /&gt;&lt;BR /&gt;&amp;gt;&amp;gt;swap usage is slightly decreased. May be some swapped out processes was terminated?&lt;BR /&gt;&lt;BR /&gt;Probably. and because of reduced ubc_maxpercent new&lt;BR /&gt;processes are not swapped out again.&lt;BR /&gt;&lt;BR /&gt;Did you mention your hardware?&lt;BR /&gt;NUMA?&lt;BR /&gt;What tells vmstat -R?</description>
      <pubDate>Wed, 11 May 2005 18:11:33 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292277#M12541</guid>
      <dc:creator>Joerg Schulenburg</dc:creator>
      <dc:date>2005-05-11T18:11:33Z</dc:date>
    </item>
    <item>
      <title>Re: Who is using swap space?</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292278#M12542</link>
      <description>GS1280, 8 CPU, 32 GB mem.&lt;BR /&gt;&lt;BR /&gt;vmstat -R see in attachment.</description>
      <pubDate>Fri, 13 May 2005 03:36:06 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292278#M12542</guid>
      <dc:creator>Alexey Borchev</dc:creator>
      <dc:date>2005-05-13T03:36:06Z</dc:date>
    </item>
    <item>
      <title>Re: Who is using swap space?</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292279#M12543</link>
      <description>&amp;gt;&amp;gt;&amp;gt;&amp;gt;As far as i understand, Trunix will not swap out filesystem cache - it will shrink it instead.&lt;BR /&gt;&amp;gt;&amp;gt;My experiences are otherwise. Tru64 takes swap instead of shrinking UBC.&lt;BR /&gt;- How did You observed this? The behaviour seems absolutely rediculose, unless ubc_min_percent hit. &lt;BR /&gt;&lt;BR /&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Why Unix does not read it back into memory?&lt;BR /&gt;&lt;BR /&gt;&amp;gt;&amp;gt;Unix does, Tru64 does not :(&lt;BR /&gt;I think the philosophy behint is, that the&lt;BR /&gt;pages read from the swap are cached and if&lt;BR /&gt;memory again is low only cached pages has to&lt;BR /&gt;be released.&lt;BR /&gt;- Yes, i see the point. So, next time instead of swapping out, kernel will just discard the pages (if they are not "dirty").&lt;BR /&gt; &lt;BR /&gt;</description>
      <pubDate>Fri, 13 May 2005 03:48:23 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292279#M12543</guid>
      <dc:creator>Alexey Borchev</dc:creator>
      <dc:date>2005-05-13T03:48:23Z</dc:date>
    </item>
    <item>
      <title>Re: Who is using swap space?</title>
      <link>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292280#M12544</link>
      <description>&amp;gt;&amp;gt;How did You observed this? The behaviour seems absolutely rediculose, unless ubc_min_percent hit.&lt;BR /&gt;&lt;BR /&gt;I did vmstat -R 1 (or 10 instead of 1) and vmubc -tty -swap -memory (please look at the webpage mentioned in my GS1280 swap thread threadId=859125 for details). Read a big file to fill the UBC,&lt;BR /&gt;started a memory consuming testprogram and&lt;BR /&gt;swapping started before ubc_minpercent and borrowpercent was hit. I am not quite sure if&lt;BR /&gt;actu was not lowered or not lowered enough to&lt;BR /&gt;avoid swapping. I will have a look to my logfiles or repeat the experiment later, because I dont have time now and put the original data to my mentioned webpage.&lt;BR /&gt;&lt;BR /&gt;Your attachement:&lt;BR /&gt;a snapshot is not enough, do a vmstat -R 60 (or so). vmubc would be good too. &lt;BR /&gt;Have a look to the free pages of each RAD. Looks like RAD0 and RAD1 where&lt;BR /&gt;temporary out of memory (high acti and pout).&lt;BR /&gt;If so, you triggered a kernel bug or&lt;BR /&gt;however HP call that misbehaviours (see my thread). But its not for sure, not enough data from you (and HPs engineers) to find out, what exactly goes wrong.&lt;BR /&gt;</description>
      <pubDate>Fri, 13 May 2005 07:03:07 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-tru64-unix/who-is-using-swap-space/m-p/3292280#M12544</guid>
      <dc:creator>Joerg Schulenburg</dc:creator>
      <dc:date>2005-05-13T07:03:07Z</dc:date>
    </item>
  </channel>
</rss>

