Search code examples
javajakarta-eesolaris

high swap memory utilization

Server Configuration:

  1. Physical Ram - 16Gb
  2. Swap Memory - 27Gb
  3. OS - Solaris 10
  4. Physical Memory Free - 598 Mb
  5. Swap Memory Used - ~26Gb
  6. Java Version - Java HotSpot(TM) Server VM - 1.6.0_17-b04

My Task is to reduce used swap memory:- Solutions i have though of

  1. Stop all java applications and wait till physical memory is sufficiently freed. then execute command "swapoff -a"(Yet to find out Solaris equivalent of this command) ...wait till swap memory used goes down to zero. then execute command "swapon -a"
  2. Increase Physical Memory

I need help on following points:-

  1. Whats the solaris equivalent of swapoff and swapon?
  2. Will option 1 work to clear used swap?

Thanks a Million!!!

Solution

  • First, Java and swap don't mix. If your java app is swapping, you're simply doomed. Few things murder a machine like a swapped java process. GC and swap is just a nightmare.

    So, given that, if you machine with the java process is swapping -- that machine is too small. Get more memory, or reduce the load on the machine (including the heap of the java process if possible).

    The fact that your machine has no physical memory (600ish Mb), and no free swap space (1ish Gb) is another indicator that the machine is way overloaded.

    All manner of things could be faulting your Java process when resources are exhausted.

    Killing the Java process will "take it out of swap", since the process doesn't exist, it can't be in swap. Same for all of the other processes. "Swap memory" may not instantly go down, but if a process doesn't exist -- it can't swap (barring the use of persistent shared memory buffers that have the misfortune of being swapped out, and Java doesn't typically use those.)

    There isn't really a good way that I know of to tell the OS to lock a specific program in to physical RAM and prevent it from being paged out. And, frankly, you don't want to.

    Whatever is taking all of your RAM, you need to seriously consider reducing its footprint(s), or moving the Java process off of this machine. You're simply running in to hard limits, and there's no more blood in this stone.