On 2009-07-09 21:28, Duncan wrote:
Ron Johnson <ron.l.john...@cox.net> posted
4a561f52.1090...@cox.net, excerpted below, on Thu, 09 Jul 2009 11:48:18
-0500:
After reading this:
http://www.westnet.com/~gsmith/content/linux-pdflush.htm
and especially this thread:
http://lkml.org/lkml/2009/1/7/303
I boosted dirty_ratio from 10 to 30 and dirty_background_ratio from 5 to
10.
Now tasks.nzb.tmp seems to get written 3x faster.
Thanks!!!
Cool! =:^)
The problem now is that the nntp pipes are so fat that, "because" of
multi-threading, the tasks.nzb.tmp flush starts again only 3-5
seconds after the previous flush completed.
This is why I was pushing for on-disk structures instead of having
to flush memory structures to disk.
If SQLite is bad, then maybe Berkeley DB. It's got rollbacks, fine
grained locking. KLibido, a KDE newsreader, uses it for a similar
purpose.
*Something* so that a 10KB change in tasks does not require a 300MB
file to be written to disk.
BTW, I don't know what kernel you are on, but on the leading edge,
A home-rolled 2.6.28.
uncovered and stop-gap fixed in kernel 2.6.29, fixed more correctly in
2.6.30, and possibly settle-in fixes to in-development 2.6.31 (I'm not
I'll have to upgrade soon.
sure on that), there have been a number of some would say way too late
changes to the way ext3 handles such things. This was in large part
rooted in a MAJOR kerflukle with ext4 development, that uncovered a
number of badly chosen defaults and policy decisions and implementations
in existing ext3 and the under development ext4.
I lost a WHOLE LOT of downloads from an ext4-over-lvm2 mishap. Must
have been an unclean (or non-existent) umount on shutdown.
--
Scooty Puff, Sr
The Doom-Bringer
_______________________________________________
Pan-users mailing list
Pan-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/pan-users
