Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Latencies\s+writing\s+to\s+memory\s+mapped\s+files\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Latencies\s+writing\s+to\s+memory\s+mapped\s+files\s*$/: 10 ]

Total 10 documents matching your query.

1. Latencies writing to memory mapped files (score: 1): Author: Shawn Bohrer <shawn.bohrer@xxxxxxxxx>; Date: Wed, 15 Sep 2010 10:26:33 -0500; Hello, A little while ago I asked about ways to solve the occasional spikes in latency that I see when writing to a shared memory mapped file. http://oss.sgi.com/pipermail/xfs/2010-July/046311.html W; /archives/xfs/2010-09/msg00296.html (41,548 bytes)
2. Re: Latencies writing to memory mapped files (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 16 Sep 2010 10:18:37 +1000; You really should add logbsize=262144 there - it won't prevent the latencies, but with less log writes the incidence should decrease significantly. Ok, so now you are doing unwritten extent conversio; /archives/xfs/2010-09/msg00304.html (27,835 bytes)
3. Re: Latencies writing to memory mapped files (score: 1): Author: Shawn Bohrer <shawn.bohrer@xxxxxxxxx>; Date: Fri, 17 Sep 2010 10:45:23 -0500; Hi Dave, Thanks again for your replies. I initially tested with logbsize=256k but did not notice any difference. I then later realized that I had been doing a: mount -o remount,logbsize=256k /home Yo; /archives/xfs/2010-09/msg00326.html (15,134 bytes)
4. Re: Latencies writing to memory mapped files (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Mon, 20 Sep 2010 10:05:35 +1000; You may not notice any difference if the log is not the latency you are tripping over. However, doing up to 8x less log IO is definitely good for reducing overall IO latency... yes. Not exactly. When; /archives/xfs/2010-09/msg00336.html (16,596 bytes)
5. Re: Latencies writing to memory mapped files (score: 1): Author: Shawn Bohrer <shawn.bohrer@xxxxxxxxx>; Date: Mon, 20 Sep 2010 17:17:26 -0500; Thanks Dave for your explanations. I'm working on a dev box right now so I just added a trace_printk() to print out the bp->b_bn field when the xfs_buf_lock blocks for more than 300ms. Here are some; /archives/xfs/2010-09/msg00344.html (11,380 bytes)
6. Re: Latencies writing to memory mapped files (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Tue, 21 Sep 2010 08:48:33 +1000; Hmmm - it would be good to know which one produced the latency, given there does not appear to be a pattern in the block numbers. xfs_db -r -c "daddr 812730376" -c "print" <dev> Will dump the sector; /archives/xfs/2010-09/msg00345.html (11,171 bytes)
7. Re: Latencies writing to memory mapped files (score: 1): Author: Shawn Bohrer <shawn.bohrer@xxxxxxxxx>; Date: Tue, 21 Sep 2010 13:05:41 -0500; OK here is a little more information which may be relevant. I've currently got 12 processes that read data from a socket and each write to a different memory mapped file. The apps are only appending; /archives/xfs/2010-09/msg00351.html (24,037 bytes)
8. Re: Latencies writing to memory mapped files (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Wed, 22 Sep 2010 09:15:31 +1000; ..... ^^^^^^^^ B M A P So these are inode extent btree blocks your application is getting stuck on. These only get written back as a result of either log pressure (i.e. tail pushing) or by the xfsbuf; /archives/xfs/2010-09/msg00354.html (13,564 bytes)
9. Re: Latencies writing to memory mapped files (score: 1): Author: Shawn Bohrer <shawn.bohrer@xxxxxxxxx>; Date: Wed, 29 Sep 2010 10:31:22 -0500; So setting fs.xfs.age_buffer_centisecs to 720000 does seem to help, but what are the consequences (if any) of doing this? I've considered this and some other elaborate schemes. We'll see if I need to; /archives/xfs/2010-09/msg00575.html (16,066 bytes)
10. Re: Latencies writing to memory mapped files (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 30 Sep 2010 09:19:08 +1000; It means that metadata will stay active in the log for longer. That means it is likely that recovery will take longer if your system crashes. It also means that there may be more latency on transacti; /archives/xfs/2010-09/msg00581.html (11,781 bytes)

Current List: 1 - 10
Page: [1]