On Tuesday 20 November 2007 11:59, Ian Kumlien wrote:
> Hi,
>
> I have had this before and sent a mail about it.
>
> It seems like the diskcache is still in use and is never shrunk. This
> happened with a odd load though, trackerd started indexing a bit late
> and the other workload which is a large bittorrent seed/download.
>
> The bittorrent app is the one that drives up the diskcache.
>
> I don't think that trackerd was triggering it, i actually upgraded
> kernel since it kept happening on 2.6.23...
>
> I really don't know what other information i can provide.
>
> free from now (some hours later)
> vmstat from now ^
>
> and the dmesg log.
>
> Ideas? Comments?
>
> free:
> total used free shared buffers cached
> Mem: 2056484 2039736 16748 0 20776 1585408
> -/+ buffers/cache: 433552 1622932
> Swap: 2530180 426020 2104160
> ---
>
> vmstat:
> procs -----------memory---------- ---swap-- -----io---- -system--
> ----cpu---- r b swpd free buff cache si so bi bo in
> cs us sy id wa 0 0 426020 16612 20580 1585848 26 21 684 56 34
> 51 5 3 88 4 ---
>
> --- 8<--- 8<---
> ntpd invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
>
> Call Trace:
> [<ffffffff80270fd6>] oom_kill_process+0xf6/0x110
> [<ffffffff80271476>] out_of_memory+0x1b6/0x200
> [<ffffffff80273a07>] __alloc_pages+0x387/0x3c0
> [<ffffffff80275b03>] __do_page_cache_readahead+0x103/0x260
> [<ffffffff802703f1>] filemap_fault+0x2f1/0x420
> [<ffffffff8027bcbb>] __do_fault+0x6b/0x410
> [<ffffffff802499de>] recalc_sigpending+0xe/0x40
> [<ffffffff8027d9dd>] handle_mm_fault+0x1bd/0x7a0
> [<ffffffff80212cda>] save_i387+0x9a/0xe0
> [<ffffffff80227e76>] do_page_fault+0x176/0x790
> [<ffffffff8020bacf>] sys_rt_sigreturn+0x35f/0x400
> [<ffffffff806acbf9>] error_exit+0x0/0x51
>
> Mem-info:
> DMA per-cpu:
> CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1
> usd: 0 CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0,
> btch: 1 usd: 0 DMA32 per-cpu:
> CPU 0: Hot: hi: 186, btch: 31 usd: 148 Cold: hi: 62, btch: 15
> usd: 60 CPU 1: Hot: hi: 186, btch: 31 usd: 116 Cold: hi: 62,
> btch: 15 usd: 18 Active:241172 inactive:241825 dirty:0 writeback:0
> unstable:0
> free:3388 slab:8095 mapped:149 pagetables:6263 bounce:0
> DMA free:7908kB min:20kB low:24kB high:28kB active:0kB inactive:0kB
> present:7436kB pages_scanned:0 all_unreclaimable? yes lowmem_reserve[]: 0
> 2003 2003 2003
> DMA32 free:5644kB min:5716kB low:7144kB high:8572kB active:964688kB
> inactive:967188kB present:2052008kB pages_scanned:5519125
> all_unreclaimable? yes lowmem_reserve[]: 0 0 0 0
> DMA: 5*4kB 4*8kB 3*16kB 4*32kB 6*64kB 5*128kB 4*256kB 3*512kB 0*1024kB
> 0*2048kB 1*4096kB = 7908kB DMA32: 95*4kB 2*8kB 0*16kB 0*32kB 0*64kB 1*128kB
> 0*256kB 2*512kB 0*1024kB 0*2048kB 1*4096kB = 5644kB Swap cache: add
> 1979600, delete 1979592, find 144656/307405, race 1+17 Free swap = 0kB
> Total swap = 2530180kB
> Free swap: 0kB
> 524208 pages of RAM
> 10149 reserved pages
> 5059 pages shared
> 8 pages swap cached
> Out of memory: kill process 8421 (trackerd) score 1016524 or a child
> Killed process 8421 (trackerd)
It's also used up all your 2.5GB of swap. The output of your `free` shows
a fair bit of disk cache there, but it also shows a lot of swap free, which
isn't the case at oom-time.
Unfortunately, we don't show NR_ANON_PAGES in these stats, but at a guess,
I'd say that the file cache is mostly shrunk and you still don't have
enough memory. trackerd probably has a memory leak in it, or else is just
trying to allocate more memory than you have. Is this a regression?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
