Ok, I've uploaded v0.4.

Changes:

# v0.4 - 2009-04-23 - ntang
#   Added ability to specify color, sleep time, and servers on command
line.
#   Also added checks for Getopt::Long and Term::ANSIColor.
#   Added $default_port = "11211" and padding for short server names.
Server
#     names over 23 characters inc. port will break the column lineups
for now.


When I have a little more time, I'll change it so it grabs all of the
data before refreshing and printing (v0.5).  It'll make refreshes a
little cleaner looking, and will allow me to space the columns based
on server name length, which'll help for those of you with especially
long server names.

If you've got Getopt::Long installed, it'll allow for these flags:

#   If Getopt::Long is installed:
#     - Specify servers w/ --servers (multiple times or comma
separated)
#     - Specify default port w/ --port (defaults to 11211)
#     - Specify sleep time w/ --sleep (default 3)
#     - Specify color output w/ --color (default) or --nocolor

The nice thing is that you can mix and match servers... for instance:

--servers 10.0.0.1,10.0.0.2,10.0.0.3,10.0.0.3:11213 --port 11212

will work and use these servers:

10.0.0.1:11212
10.0.0.2:11212
10.0.0.3:11212
10.0.0.3:11213

Of course, you can still define servers by setting the @servers config
variable within the script.  Enjoy!

http://memcache-top.googlecode.com/files/memcache-top-v0.4

Thanks,
Nicholas

On Apr 22, 5:50 pm, ntang <[email protected]> wrote:
> Whoops!  The print "\033[2J"; statement actually clears the screens on
> most terminal types... but I always use it with $usecolor turned on,
> so I didn't realize I had accidentally disabled that when it's turned
> off.  :)  Just removing the "if $usecolor" from the end of that
> statement will have it clear the screen without having to spawn the
> clear command.  Try that, let me know if it works for you - if not, we
> could probably make that configurable.
>
> I actually prefer to pre-specify the servers in the script, but I can
> take your mod and tweak it so that if they're specified on the command
> line it'll override what's defined in the script (similar to the
> sleep/ refresh time).  If I'm going to do that I'll probably use
> Getopt to deal with the flags... my goal is just to keep it as "clean"
> as possible so it won't require finding and installing perl mods to
> run, one of my minor pet peeves with a lot of (admittedly very good!)
> perl tools.  I'll try to get around to posting a tweaked version
> tomorrow with those changes.
>
> How big a deal is it to grab all of the stats first before
> refreshing?  If it's causing problems I can just push all of the
> output into a variable and then print it all out at the end of each
> iteration.  Just seemed a lot simpler to do it this way.  :)
>
> Thanks,
> Nicholas
>
> On Apr 22, 5:23 pm, Paul Lindner <[email protected]> wrote:
>
> > Just what I needed.
>
> > Here's a simple patch to clear the screen and allow servers on the  
> > command line.  When you have dozens of memcache servers it might be  
> > nice to gather the  output first and then redraw.
>
> >   diff -u memcache-top-0.3.orig memcache-top
> > --- memcache-top-0.3.orig       2009-04-22 12:44:22.993210000 -0700
> > +++ memcache-top        2009-04-22 13:02:10.579094000 -0700
> > @@ -49,30 +49,26 @@
> >   );
> >   #
> >   # Default time to sleep in-between refreshes.
> > -$sleep = 3;
> > +my $default_sleep = 3;
> >   #
> >   # List of servers/ ports to query.
> >   @servers = (
> > -  '1.2.3.4:11211',
> > -  '1.2.3.5:11211',
> > -  '1.2.3.5:11212',
> >   );
> >   # END CONFIGURATION
>
> > ##################################################################################
> > -
> > -if (defined(@ARGV)) {
> > -  if ( $ARGV[0] =~ /^\d+$/ ) {
> > -    $sleep = $ARGV[0];
> > -  }
> > -  else {
> > -    die "USAGE: memcache-top.pl <optional number of seconds to sleep>
> > \n";
> > -  }
> > +$sleep = shift @ARGV;
> > +if (!($sleep && $sleep =~ /^\d+$/)) {
> > +   $sleep = $default_sleep;
> >   }
> > +
> > +push(@servers, @ARGV);
>
> >   my $i = 1;
>
> > -while ($i) {
> > +my $CLEAR = `clear`;
>
> > +while ($i) {
> > +  print $CLEAR;
> >     print "\033[2J" if $usecolor;
> >     print color 'bold' if $usecolor;
> >     print "\nMEMCACHE STATS\t\t\t\t\t\t   (refresh: $sleep seconds)\n
> > \n";
>
> > On Apr 22, 2009, at 2:16 PM, Mat Williams wrote:
>
> > > hi,
>
> > > i like the idea for this project, nice work nicholas. i have looked at
> > > the output and it seems like it will be a useful tool for me too.
>
> > > gf, can you please tell me why this code is not good - should i be
> > > worried about running it against production servers?
>
> > > thanks,
> > > m...@.
>
> > > On Wed, 2009-04-22 at 13:00 -0700, gf wrote:
> > >> Hi. It's really good idea, but your code is not good, IMHO.
> > >> I've started the same project now..
> > >> It will be released soon.
>
> > >> On 22 апр, 23:34, ntang <[email protected]> wrote:
> > >>> Hey all.  First post...
>
> > >>> We've been using memcached for a while, but we've never really done
> > >>> much to monitor it past making sure the servers were up and running.
> > >>> Anyways, we recently had some issues that looked like they might  
> > >>> have
> > >>> been related to memcached performance/ usage, and I figured it was
> > >>> about time that we started taking a look at it.  We've added graphs
> > >>> for various stats so we can track them over time, and added nagios
> > >>> checks for the stats as well, but I also wanted a quick way to see  
> > >>> the
> > >>> immediate state of the cluster.
>
> > >>> So I wrote a little tool.  Hopefully people will find it useful.  
> > >>> It's
> > >>> mostly configured by editing a config block up top, sue me.  It's
> > >>> cheesy but works.  The first time you run it, you'll need (at a
> > >>> minimum) to populate @servers.
>
> > >>> It's here:http://code.google.com/p/memcache-top/
>
> > >>> (In retrospect I should've named it memcached-top, but such is life.
> > >>> I think people will be able to figure it out, and maybe if I put out
> > >>> another 'release' (*cough*) I'll rename it.  ;)  )
>
> > >>> Thanks,
> > >>> Nicholas

Reply via email to