[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: a data rate threshold tool?



Zhang Weiwu wrote:

> > Hello. I found my application, which was supposed to run 10 hours,
> > either run and starve every other service on it, or doesn't run at all.
> > Even with nice and ionice, I cannot avoid other web services starved by
> > this application. And it has to run on the production server.
> >
> > One trick that comes to my mind is to use a data rate threshold tool to
> > limit the data rate input is fed to the application.
> >
> > $ threshold --rate 20KB/s < data_source | my_greedy_application
> >
> > Is there such a tool in Debian?


I don't know about a tool, but assuming it's not important that the rate
is precise as long as it's somewhere about right, a simple perl script
will do it. You can probably do similar things with python etc.

The following takes a rate in bytes a second and optionally a block size
in bytes, and writes a block of data at the appropriate interval (no
--rate - so if you save it as "threshold" invoke it as threshold 20480
  - for 20kB/s). Default block size is 1k. Note that I only just wrote
it, so YMMV and take it as an example for experimentation ;) Should be
fairly obvious how it works; note it'll do silly things if you give it
silly arguments, in particular very large block sizes.

-- start of script

#!/usr/bin/perl

use strict;
use warnings;

use Time::HiRes qw(sleep);

my $rate=$ARGV[0];
if(!$rate) {
   print STDERR "No rate given\n";
   exit 1;
}

my $block_sz=$ARGV[1];
$block_sz=1024 unless $block_sz;

my $delay=$block_sz/$rate;

my $bytes;
my $nbytes;
while($nbytes=sysread STDIN, $bytes, $block_sz) {
   while($nbytes) {
     my $wbytes=syswrite STDOUT, $bytes, $nbytes;
     if(!defined($wbytes)) {
       print STDERR "error writing: $!\n";
       exit 1;
     }
     $nbytes-=$wbytes;
   }
   sleep($delay);
}

if(!defined($nbytes)) {
   print STDERR "error reading: $!\n";
   exit 1;
}

exit 0;

-- end of script

--
Chris Jackson
Shadowcat Systems Ltd.


Reply to: