Date: Sat, 19 Nov 2005 15:31:57 +0300 From: "Andrew P." <infofarmer@gmail.com> To: Mikhail Teterin <mi+mx@aldan.algebra.com> Cc: questions@freebsd.org Subject: Re: throttling NFS writes Message-ID: <cb5206420511190431i3ec19c0fw3371001be623f61c@mail.gmail.com> In-Reply-To: <200511181924.17282.mi%2Bmx@aldan.algebra.com> References: <200511181924.17282.mi%2Bmx@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/19/05, Mikhail Teterin <mi+mx@aldan.algebra.com> wrote: > Hi! > > We have an unusual problem with NFS writes being _too fast_ for our good. > > The system is accepting database dumps from NFS-clients and begins compre= ssing > each dump as soon, as it begins arriving (waiting for more via kevent, if > needed). > > The NFS-clients (database servers) run on slow Sparc processors and can n= ot be > bothered to compress their data... > > The setup works quite well, if the to-be compressed data is still in memo= ry, > when the compressor gets to it. > > "Unfortunately", those Sparc systems have rather fast I/O rates and manag= e to > write their dumps faster, than the compressor can compress it. When this > happens, the overall performance of the backup script goes down through t= he > floor :-(, because it forces the disk to read the middle of a file (for > compression), while data keeps arriving (from the NFS-client) at the end = of > it... > > So we'd like to stall the client's dumping, so that the compressor can ke= ep > up. Short of limiting NFS-bandwidth via ipfw, is there a way to control N= FS > speed dynamically? > > The uncompressed dumps are _huge_, although they compress very well. So w= e can > not just accept all of them first and then start compressing -- we don't = have > enough room. There is enough to keep about 3 full-dumps worth of compress= ed > data, but even a single uncompressed full dump would not fit... > > -mi > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.o= rg" > Well, what's wrong with traffic shaping? It's as good a solution as anything else. NFS clients will just block on writes, and it won't cause any trouble. Other solutions include sending lockfiles with dumps and checking for their number before sending a new dump (and deleting them as soon as a dump is compressed). It's also not really hard to write a client-sever system (Perl is good for that), where server watches hardware resources on the host and clients query them before any activity. Sort of traffic lights. About 50-100 lines of Perl code.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cb5206420511190431i3ec19c0fw3371001be623f61c>