Messages in this thread | | | Subject | Re: Linux BUG: Memory Leak | From | Disconnect <> | Date | 12 Mar 2003 11:49:12 -0500 |
| |
For starters, read (and apply!) everyone else's comments re politeness, proper information to include, etc.
But to add some info in a "Me too":
System has 1G lowmem (the AA vm patches) and showed almost the same symptoms last night after 1wk of uptime. Its now been up for about 14 hours with several large processes, agp, etc all going and is - yet again - running out of memory. (After booting and logging in, 130 megs was used.. and that was it.)
Kernel: 2.4.20 + patches (see list below) Memory: PC133 @ 133 - 1024M lowmem, 0M highmem, 2048M swap Disk: AIC7xxx + LVM1 (raid0) CPU: Tbird 1.2G non-overclocked Added modules: lm-sensors, alsa, gatos radeon hardware-gl for X 4.2.0 (X ver 4.2.1) Config: Attached
I showed up last night to find it was 900 megs into swap and (relatively slowly) climbing, but nothing in ps showed a particularly large memory usage (largest was X, which was - AFAIU - likely to be a mix of "X leaks" and agp/vidram buffers.. and it was 200M total). Killed off X and the other largish apps (apache at 30M, etc..) such that ps showed well under 300 megs of total VM accounted for. But free still showed 950 megs of ram and 100 megs of swap in use. /proc/meminfo showed some of it (300 megs or so) as buffers, only 16M in cache.
Its been rebooted to the same workload and the same kernel, and happened again. That info is attached below.
Basically the patches come from the debian kernel-patch-ck package:
O(1) and batch scheduler (ck) Author: Ingo Molnar URL: http://people.redhat.com/mingo/O(1)-scheduler/
Fix for a locking bug in wait_on_page, wait_on_buffer, get_request_wait (ck) See the URL below for information on what this patch fixes. Author: Andrea Arcangeli URL: http://marc.theaimsgroup.com/?l=linux-kernel&m=103707362523414&w=2 Preemptible kernel (ck) This patch must be enabled via the kernel configuration. Author: Robert M. Love URL: http://www.tech9.net/rml/linux/
Low-latency (ck) This patch must be enabled via the kernel configuration. The "control low latency with sysctl" configuration option is not needed and will only disable low latency unless you manually enable it after bootup (using "echo 1 > /proc/sys/kernel/lowlatency"). Author: Andrew Morton URL: http://www.zip.com.au/~akpm/linux/schedlat.html
Andrea Arcangeli's VM patches (aa) Recommended by Con Kolivas for SMP machines. Author: Andrea Arcangeli URL: http://www.kernel.org/pub/linux/kernel/people/andrea/
Desktop tuning (tune) Minor changes to magic numbers benchmarked to improve desktop responsiveness, and lower disk latency more at the expense of a small amount of disk throughput.
This patch depends on the (aa) patch, and cannot be used with the (rmap) patch.
1000Hz timer with autoregulated timeslice duration (vartimeslice) This patch will adjust the time a process can run for according to the stress the system is under. If there are many running processes or any writing to disk the timeslice duration will be decreased. It is decreased proportionately less in SMP machines. You can see the current value for timeslice_multiplier by doing 'cat /proc/stat'.
Vairable HZ (varhz) This patch allows you to configure the frequency the system timer interrupt pops. Higher tick values provide improved granularity of timers, improved select() and poll() performance, and lower scheduling latency. Higher values, however, increase interrupt overhead and will allow jiffie wraparound sooner. The default value, which was the value for all of eternity, is 100. If you are looking to provide better timer granularity or increased desktop performance, try 500 or 1000. If unsure, go with the default of 100.
Disk read latency update (read_latency) See the URL below for more information. URL: http://marc.theaimsgroup.com/?l=linux-kernel&m=101355715821610&w=2
Evidently there is a website about this patcheset: http://kernel.kolivas.net/
On Wed, 2003-03-12 at 01:49, M. Soltysiak wrote: > I sent this here because i don't know which author screwed up. > > Basically, it's a massive kernel memory leak or a VM problem. > > System specs: > 1 GBytes RAM > duel CPU system; 1 Ghz each. > IDE disk system, 133 Mhz bus speed, DMA. > USB mouse. > PS/2 Keyboard. > Creative Labs emu10k1-based sound card. (LIVE!) > Asus Motherboard. > > Problem: > > When I boot the system, run X11 with KDE--totalling 100 M at most--things > are fine. -- Disconnect <lkml@sigkill.net> [unhandled content-type:application/x-gzip][unhandled content-type:application/x-gzip][unhandled content-type:application/x-gzip][unhandled content-type:application/x-gzip] | |