Roger Oberholtzer wrote:
I have seen suggestions of using allocsize=64m when writing streaming media like I have. I will be trying this.
In your situation, if your entire data file is always 2GB, (i.e. you write data until you hit the 2GB mark, then close and open a new file), and if it is the only thing you are putting on that disk, you might try making allocsize=1g (the max). Then the allocator will get called twice/file, and on a clean disk, it should have no problem finding space. If it is to a raid disk and assuming you set it up stripe aligned, you'd want to to use largeio and swalloc, but I doubt either of those would be at fault. It sounds more like things build up in memory for 30 minutes, then something is flushing and/or having to work hard for 5 seconds -- like you've written to memory buffers for 30 minutes then some routine calls to empty buffers because it is out of space. This is where I think you'll benefit most by using O_DIRECT in your open call and either a 2nd thread to handle I/O, or async I/O. You shouldn't have a 5 second pause like that unless your app is doing lots of little writes and it takes 30 minutes to fill up memory to the point that it has to empty the buffer, but that sounds like a long time. Do you know if your disc is writing continuously while you execute, or do you get disk-i/o only ever 30 minutes? ;-) The extra cpu's. If you run iostat, does your output disk see continuous I/O, or only periodically? (i.e. "iostat 5 /dev/sdX", where X is the disk you are writing to). By writing to /dev/null instead of a disk you are avoiding the kernel's disk-io routines as well as the xfs-io routines. I.e. it could be either one. That's why trying O_DIRECT can help eliminate the kernel's I/O buffering routines. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org