[lkml]   [2001]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectWhat version of the kernel fixes these VM issues?
Hi -

We have big system (8 processors, 8GB ram), running Oracle and this other ETL tool. Oracle is up and running all the time, and the ETL tool runs once a day. But everytime the ETL tool runs (along with Oracle), the system seems to run out of memory, and the server comes to a crawl, often with keyborad response in 10 to 15 minute intervals. We are currently using the 2.4.3-6 kernel that comes with Redhat 7.1.

We know that Oracle comsumes no more than 2GB of memory at peak usage, and the ETL tool itself consumes less than 1GB. But the ETL tool does process a whole bunch of text files (total about 6GB worth of), and it runs for about 2 hours. What happens is that while they are both running, the filesystem cache size increases progressively, and some time later, it begins swapping. We do have 16GB (2x RAM) of swap. And when it starts to swap, the server responds to keystrokes/commands randomly and appears dead for 10s of minutes. We know that together our applications do not need more than 4GB of RAM on this 8GB box, so it is the VM that is causing this unnecessary swapping by trying to use too much memory for filesystem cache.

So the first question is, is there any way I can limit the amount of memory used for FS cache ?

And the next one is, are there any (later) versions of the kernel that are more sane about what the maximum FS cache it should use is ? It is strange that the FS caching does not take into account the amount of physical RAM on the box. What is the point in doing FS caching when the end result is thrashing and the machine becomes unusable ?



FREE Personalized E-mail at

Talk More, Pay Less with Net2Phone Direct(R), up to 1500 minutes free!

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:58    [W:0.069 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site