changing swap size (fwd)

[Zbigniew Szalbot]

Hello,

On Tue, 21 Nov 2006, Chuck Swiger wrote:

> The added RAM will certainly help to minimize or reduce swapping, if it is 
> occurring.  But you might want to post the output of "vmstat -s" after the 
> system has been under normal load for us to evaluate how much benefit you're 
> likely to see.

Thanks a lot. The output is below. I have a curious observation though I 
understand that this might be just a normal thing... When I booted today 
after adding some RAM, the free memory stood at roughly 300MB RAM. 
However, at present after a few hours work it is at about 220MB. I think 
the same thing happened previously with less RAM and growing percentage of 
swap use. I am keeping a log of free RAM snapshots to see it in the longer 
run.

As for the vmstat it was taken when the system was about to finish 
delivering a batch of 800 messages to various domains. The messages are 
passed to an MTA in batches of 10 emails every 14 seconds. The load stood 
at about 0.70, though I know that at certain times (especially early in 
the morning when there are about 12K emails to be sent) it is a bit higher 
(I think it may be between 1.5-3).

  $ vmstat -s
  20067169 cpu context switches
  47298341 device interrupts
    463804 software interrupts
   4658824 traps
  20972806 system calls
        38 kernel threads created
     28968  fork() calls
       334 vfork() calls
         0 rfork() calls
         0 swap pager pageins
         0 swap pager pages paged in
         0 swap pager pageouts
         0 swap pager pages paged out
      1071 vnode pager pageins
      9335 vnode pager pages paged in
      1160 vnode pager pageouts
      3429 vnode pager pages paged out
         0 page daemon wakeups
         0 pages examined by the page daemon
       279 pages reactivated
   1301875 copy-on-write faults
      4119 copy-on-write optimized faults
   1304531 zero fill pages zeroed
   1261002 zero fill pages prezeroed
       125 intransit blocking page faults
   3396054 total VM faults taken
         0 pages affected by kernel thread creation
   2071675 pages affected by  fork()
     23259 pages affected by vfork()
         0 pages affected by rfork()
   3068343 pages freed
         0 pages freed by daemon
   2008851 pages freed by exiting processes
     36223 pages active
     16745 pages inactive
       319 pages in VM cache
     16736 pages wired down
     56091 pages free
      4096 bytes per page
   8319135 total name lookups
           cache hits (90% pos + 7% neg) system 0% per-directory
           deletions 0%, falsehits 0%, toolong 0%


Thanks again for your advice!

-- 
Zbigniew Szalbot