throttling NFS writes

[Andrew P.]

On 11/19/05, Mikhail Teterin <mi+mx at 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 compressing
> 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 not be
> bothered to compress their data...
>
> The setup works quite well, if the to-be compressed data is still in memory,
> when the compressor gets to it.
>
> "Unfortunately", those Sparc systems have rather fast I/O rates and manage to
> write their dumps faster, than the compressor can compress it. When this
> happens, the overall performance of the backup script goes down through the
> 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 keep
> up. Short of limiting NFS-bandwidth via ipfw, is there a way to control NFS
> speed dynamically?
>
> The uncompressed dumps are _huge_, although they compress very well. So we 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 compressed
> data, but even a single uncompressed full dump would not fit...
>
>         -mi
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
>

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.