Search String: Display: Description: Sort:

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)


This search system is powered by Namazu