Messages in this thread | | | From | Bryan -TheBS- Smith <> | Subject | Re: Kernel 2.2.14, dirty buffers, stalls in interactivity of system/NFS-clients ... | Date | Wed, 29 Mar 2000 10:38:51 -0500 |
| |
On Tue, 28 Mar 2000, Daniel J Blueman wrote: > When init loads the update (bdflush) daemon, it simply exists at the first > flush (5s later?), since the kflushd kernel thread is doing the work. That's > why you cannot see the updated/bdflush process. I think the version of > bdflush you have doesn't matter, in this case.
Okay. I was just a concerned newbie. Some document I hit mentioned that bdflush was no longer used in the latest 2.2 kernels.
> You'll need to get some parameters tuned though to see better performance. > If you can tune the I/O subsystem such that it flushes dirty data every 5s > (.'. in a much smaller bursts), since the RAID controller will deal with it > asyncoronsouly, it shouldn't cause your system to grind to a halt.
Tune the I/O subsystem? I think that is _exactly_ what I am looking for, but have absolutely _no_idea_ where to begin. I've hit the source (apparently not enough ;-), but would like to hear any suggestions anyone has.
And I _do_ concur that I need to flush regularly instead of less frequenty. When I get a big write, it seems that Linux will just let the memory fill up and then write when its full. While this is fine for a workstation, it's killer on a server with NFS clients (the SMB clients are not affected).
> This large flush every 30s
Actually, these large "flushes" happen only occassionally (every 30 minutes), but for 15-60s. That's the problem.
> may be larger than the write-back buffers in your RAID controller
Yes, that is exactly it.
My GDT controller has 64MB of RAM, but it is flushing 200MB+ to disk. Hence why the RAID controller reports 30-50% full and it seems to go up and down (as the controller is feed data to write by the OS). The second the controller just starts steadily going down, the "stall" ends because the controller is no longer being feed data (still writing to disk, but not the PCI bus).
> such that the whole process becomes disk I/O bound, not PCI > bus I/O bound.
Yep. When the controller is just flushing its own cache, it's no problem. It's when it's being feed over the PCI bus, that's the problem.
> As said, try reducing the time interval to 5s - you want a > quiescent flow of data onto your disks, not too bursty.
Er, I have not figured out how to do that exactly. And I've read quite a bit. Do I do it with ./update? Do I have to reboot for the changes to take effect (I hope not)?
Sorry for such a newbie question.
-- TheBS
-- Bryan "TheBS" Smith -- Engineer, IT Professional and Hacker E-mail: mailto:thebs@theseus.com,b.j.smith@ieee.org Disclaimer: http://www.SmithConcepts.com/legal.html ************************************************************* TheBS ... Serving E-mail filters to /dev/null since 1989
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |