SUMMARY+UPDATE: V4.0F kernel/paging problems?

From: Narendra Ra\[a\]vi <narendra_at_spiff.hr.att.com>
Date: Thu, 12 Oct 2000 09:40:34 -0400

Managers,

The following folks pointed out that the memory is being used by UBC.

alan_at_nabeth.cxo.dec.com
John Speno
James Sainsbury
Brenden Phillips
Eric Sven Ristad (message forwarded by Brenden Phillips)
Nikola Milutnovic

Thank you very much.


The experiment was motivated by the fact that we had the application
crash because the system ran out of swap space. The system had tried to
swap out application level processes because some of the processes owned
huge files (a few GB); and ubc-maxpercent was set to 100. At some point
the application (also one of the application processes leaked memory at a
rate of 156 * 16 bytes per second) was being swapped out because the data
and log files ran to the tune of 12.9 GB.

Question:

  Is there a way to select the data files and log files that should
  use UBC, and those that should NOT?

-- 
 -- Narendra Ravi     Email : narendra_at_spiff.hr.att.com
    MT  A4-4B27       Phone : 732-420-7792
On Mon, Oct 09, 2000 at 07:21:51PM -0400, Narendra Raavi wrote:
> 
> Hi Managers,
> 
> We seem to have a problem with processes freeing up space. It appears to be
> a OS level problem as we seem to run out of memory and swap. We have a ES40
> with 3 GB memory and 6GB swap, V4.0F PK#3. To verify that we have a problem,
> we ran the following experiment.
> 
> I would appreciate any thoughts you may have regarding what is happening.
> Do we have a patch missing, or is this because of something else?
> 
> 
> We used a large compressed file (> 380MB). Say AM.log.gz
> 
> Running
> 
>  vmstat -w 5 12
> 
> produced the following output
> 
> Virtual Memory Statistics: (pagesize = 8192)
>   procs      memory         pages                intr        cpu
>   r   w   u  act  free wire fault cow  pin pout  in  sy  cs  us  sy  id iowait
>   4 251  40   31K 333K  20K 1344  182  185    0 229  3K  3K   2   3  95  0
> 
> 
> We ran gunzip on this large compressed file. After gunzip completed, it
> gave us a huge file (3.2 GB). After gunzip exited, we ran vmstat again and
> got the following output
> 
> Virtual Memory Statistics: (pagesize = 8192)
>   procs      memory         pages                intr        cpu
>   r   w   u  act  free wire fault cow  pin pout  in  sy  cs  us  sy  id iowait
>   5 248  43  190K 174K  44K 1539  212  236    0  6K  2K  7K   6  11  83  0
> 
> 
> Next we ran the command
> 
>   cat AM.log  > /var/tmp/tmp1
> 
> After this completed, we ran vmstat again and got the following output:
> 
> Virtual Memory Statistics: (pagesize = 8192)
>   procs      memory         pages                intr        cpu
>   r   w   u  act  free wire fault cow  pin pout  in  sy  cs  us  sy  id iowait
>   5 243  40  339K  232  44K 1302  181  191    0  34  2K  2K   1   2  97  0
> 
> 
> Now the system reached the same state it was in before we started to
> gunzip and cat large files. But the amount of free memory was down to 278
> pages (and we started to use swap, swap is configured in lazy mode).
> 
> Next all we did is /bin/rm /var/tmp/tmp1
> 
> The vmstat output after this is:
> 
> Virtual Memory Statistics: (pagesize = 8192)
>   procs      memory         pages                intr        cpu
>   r   w   u  act  free wire fault cow  pin pout  in  sy  cs  us  sy  id iowait
>   4 244  40  192K 171K  20K 1274  166  176   10  55  2K  2K   1   6  93  0
> 
> Next we removed the large file (AM.log) that we got as a result of gunzip,
> and ran vmstat to get
> 
> Virtual Memory Statistics: (pagesize = 8192)
>   procs      memory         pages                intr        cpu
>   r   w   u  act  free wire fault cow  pin pout  in  sy  cs  us  sy  id iowait
>   4 244  40   35K 328K  20K 1279  165  176    0  47  2K  2K   1   5  95  0
> 
> - 

Received on Thu Oct 12 2000 - 13:42:14 NZDT