From: Erik Slagter <erik@slagter.name>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: linux-nfs@vger.kernel.org
Subject: Re: NFS client large rsize/wsize (tcp?) problems
Date: Wed, 02 Jan 2013 19:37:55 +0100 [thread overview]
Message-ID: <50E47E83.1030208@slagter.name> (raw)
In-Reply-To: <20130102182147.GA25450@fieldses.org>
On 02-01-13 19:21, J. Bruce Fields wrote:
>> The OOM-killer reports it needs blocks of 128k (probably for NFS,
>> but it doesn't say it), but can't find them.
>
> Details? (Could you show us the log messages?) Anything else
> interesting in the logs before then? (E.g. any "order-n allocation
> failed" messages?)
Hmmm, that will be tricky. The one box that produces OOM-messages has
this after about a week of usage, and they only log in memory :-(
Ah, I've found one!
> enigma2 invoked oom-killer: gfp_mask=0xd0, order=0, oom_adj=0, oom_score_adj=0
> Call Trace:
> [<80485708>] dump_stack+0x8/0x34
> [<80081f60>] dump_header.isra.9+0x88/0x1a4
> [<80082268>] oom_kill_process.constprop.16+0xc4/0x2b8
> [<800828c4>] out_of_memory+0x2a8/0x3a8
> [<80085e78>] __alloc_pages_nodemask+0x640/0x654
> [<8048683c>] cache_alloc_refill+0x350/0x668
> [<800b1f10>] kmem_cache_alloc+0xe0/0x104
> [<80185360>] nfs_create_request+0x40/0x178
> [<80187544>] readpage_async_filler+0x9c/0x1bc
> [<80089b98>] read_cache_pages+0xe4/0x144
> [<801886ac>] nfs_readpages+0xd4/0x1cc
> [<80089928>] __do_page_cache_readahead+0x218/0x2e4
> [<80089d58>] ra_submit+0x28/0x34
> [<8008a138>] page_cache_sync_readahead+0x48/0x70
> [<80080ae0>] generic_file_aio_read+0x55c/0x858
> [<80179560>] nfs_file_read+0xac/0x194
> [<800b5004>] do_sync_read+0xb8/0x120
> [<800b5ca0>] vfs_read+0xa0/0x180
> [<800b5dcc>] sys_read+0x4c/0x90
> [<8000c61c>] stack_done+0x20/0x40
>
> Mem-Info:
> Normal per-cpu:
> CPU 0: hi: 90, btch: 15 usd: 14
> CPU 1: hi: 90, btch: 15 usd: 0
> active_anon:22459 inactive_anon:57 isolated_anon:0
> active_file:972 inactive_file:1968 isolated_file:0
> unevictable:0 dirty:0 writeback:144 unstable:0
> free:501 slab_reclaimable:526 slab_unreclaimable:2701
> mapped:686 shmem:142 pagetables:137 bounce:0
> Normal free:2004kB min:2036kB low:2544kB high:3052kB active_anon:89836kB inactive_anon:228kB active_file:3888kB inactive_file:7872kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:260096kB mlocked:0kB dirty:0kB writeback:576kB mapped:2744kB shmem:568kB slab_reclaimable:2104kB slab_unreclaimable:10804kB kernel_stack:792kB pagetables:548kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:14594 all_unreclaimable? yes
> lowmem_reserve[]: 0 0
> Normal: 317*4kB 90*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2004kB
> 3101 total pagecache pages
> 0 pages in swap cache
> Swap cache stats: add 0, delete 0, find 0/0
> Free swap = 0kB
> Total swap = 0kB
> 65536 pages RAM
> 28149 pages reserved
> 3039 pages shared
> 33680 pages non-shared
> [ pid ] uid tgid total_vm rss cpu oom_adj oom_score_adj name
> [ 254] 0 254 474 16 1 0 0 wdog
> [ 263] 0 263 1225 88 0 0 0 tpmd
> [ 327] 0 327 1026 255 1 0 0 nmbd
> [ 329] 0 329 1803 175 1 0 0 smbd
> [ 349] 0 349 1803 175 0 0 0 smbd
> [ 372] 1 372 499 19 1 0 0 portmap
> [ 383] 998 383 762 37 1 0 0 dbus-daemon
> [ 387] 0 387 666 24 1 0 0 dropbear
> [ 392] 0 392 664 48 0 0 0 crond
> [ 398] 0 398 758 22 1 0 0 inetd
> [ 401] 0 401 664 35 1 0 0 syslogd
> [ 403] 0 403 664 52 0 0 0 klogd
> [ 410] 997 410 922 95 1 0 0 avahi-daemon
> [ 411] 997 411 922 42 0 0 0 avahi-daemon
> [ 7811] 65534 7811 7424 187 1 0 0 msgd
> [ 7819] 0 7819 1266 45 0 0 0 oscam
> [ 7820] 0 7820 6733 2491 1 0 0 oscam
> [ 7821] 0 7821 664 16 1 0 0 enigma2.sh
> [ 7828] 0 7828 44920 19651 1 0 0 enigma2
> Out of memory: Kill process 7828 (enigma2) score 496 or sacrifice child
> Killed process 7828 (enigma2) total-vm:179680kB, anon-rss:77180kB, file-rss:1424kB
The other boxes simply lock up.
This does NOT happen with NFS mounted using smaller buffers!
>> I've "discovered" a few interesting things:
>> - adding swap to the dm8000 makes the problem almost go away,
>> although without NFS it definitely doesn't need swap, ever.
>> - when I ran my laptop (x86_64!) with a slightly older kernel
>> (2.6.35 iirc) from a rescue cd, at a certain point I also got nasty
>> dmesg reports and the "dd" proces got stuck in D state, this was
>> reproducable over reboots.
>
> Why do you believe that's the same problem?
Because all are solved with smaller nfs mount buffers. That is as much
as I understand.
> OK, thanks for the reports, let us know i you're able to narrow it down
> farther. It's not familiar off the top of my head.
Okay, at least it's good to know it's not a known problem with a known
solution / workaround. I hope the kernel message helps.
As a temporary workaround (for "dumb users" that don't know what a mount
option is, yes it's awful!) I'd like to modify the kernel of the clients
to negotiate a smaller buffer size, 32k would probably suffice. I've had
a few shots but have not been successful yet, can you give me a pointer
please?
Thanks!
next prev parent reply other threads:[~2013-01-02 18:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-30 12:53 NFS client large rsize/wsize (tcp?) problems Erik Slagter
2013-01-02 18:21 ` J. Bruce Fields
2013-01-02 18:37 ` Erik Slagter [this message]
2013-01-02 18:47 ` Myklebust, Trond
2013-01-02 19:21 ` Erik Slagter
2013-01-02 21:43 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50E47E83.1030208@slagter.name \
--to=erik@slagter.name \
--cc=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.