From owner-freebsd-questions@FreeBSD.ORG Sat Nov 19 12:32:00 2005 Return-Path: X-Original-To: questions@freebsd.org Delivered-To: freebsd-questions@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0534F16A423 for ; Sat, 19 Nov 2005 12:32:00 +0000 (GMT) (envelope-from infofarmer@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6FF343D6A for ; Sat, 19 Nov 2005 12:31:57 +0000 (GMT) (envelope-from infofarmer@gmail.com) Received: by zproxy.gmail.com with SMTP id 8so356422nzo for ; Sat, 19 Nov 2005 04:31:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HPBE8oXmkwXr/EqticW3C3RlMtB9HzWcT5WvPA9780miZJuzIXarO8umbzP710WL5wzF07y1SwdXFfQkIGuzec0TyDROJSw9SBjwk1IwYV8RWEpgwErv7d11ND4eAYv/pGEshAfaVGObZUhMgRLBzcORUP3iOi0WDftJ7ZeF5aU= Received: by 10.37.20.27 with SMTP id x27mr893779nzi; Sat, 19 Nov 2005 04:31:57 -0800 (PST) Received: by 10.37.20.33 with HTTP; Sat, 19 Nov 2005 04:31:57 -0800 (PST) Message-ID: Date: Sat, 19 Nov 2005 15:31:57 +0300 From: "Andrew P." To: Mikhail Teterin In-Reply-To: <200511181924.17282.mi+mx@aldan.algebra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200511181924.17282.mi+mx@aldan.algebra.com> Cc: questions@freebsd.org Subject: Re: throttling NFS writes X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2005 12:32:00 -0000 On 11/19/05, Mikhail Teterin 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.