xfs
[Top] [All Lists]

Re: I/O hang, possibly XFS, possibly general

To: xfs@xxxxxxxxxxx
Subject: Re: I/O hang, possibly XFS, possibly general
From: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Date: Mon, 6 Jun 2011 09:29:01 +0200
Cc: Peter Grandi <pg_xf2@xxxxxxxxxxxxxxxxxx>
In-reply-to: <19945.24042.711472.158523@xxxxxxxxxxxxxxxxxx>
Organization: it-management http://it-management.at
References: <BANLkTim_BCiKeqi5gY_gXAcmg7JgrgJCxQ@xxxxxxxxxxxxxx> <BANLkTim978GhfamN=TEFULP5GdfMu02-7w@xxxxxxxxxxxxxx> <19945.24042.711472.158523@xxxxxxxxxxxxxxxxxx>
User-agent: KMail/1.13.6 (Linux/2.6.38.6-zmi; KDE/4.6.0; x86_64; ; )
On Samstag, 4. Juni 2011 Peter Grandi wrote:
>   vm/dirty_ratio=2
>   vm/dirty_bytes=400000000
> 
>   vm/dirty_background_ratio=60
>   vm/dirty_background_bytes=0
> 
>   vm/dirty_expire_centisecs=200
>   vm/dirty_writeback_centisecs=400

Why dirty_background_ratio=60? This would mean you start to write dirty 
pages only after it reaches 60% of total system memory... Setting it to 
=1 would be the thing you want I guess.
Also, setting both dirty_background_(ratio|bytes) is not supported. The 
latter wins, according to sysctl/vm.txt

Similarly, dirty_ratio and dirty_bytes belong together and exclude each 
other. Maybe you specified both to fit older and newer kernels in one 
example?

dirty_expire_centisecs to 200 means a sync every 2s, which might be good 
in this specific setup mentioned here, but not for a generic server. 
That would defeat XFS's in-memory grouping of blocks before writeout, 
and in case of many parallel (slow|ftp) uploads could lead to much more 
data fragmentation, or no?


-- 
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc

it-management Internet Services: Protéger
http://proteger.at [gesprochen: Prot-e-schee]
Tel: +43 660 / 415 6531

// Haus zu verkaufen: http://zmi.at/langegg/

Attachment: signature.asc
Description: This is a digitally signed message part.

<Prev in Thread] Current Thread [Next in Thread>