innotop-discuss — General innotop discussion, help, feedback, feature requests and so on.

[Innotop-discuss] Fwd: innotop committer ?

[Besam K. <bkh...@gm...>]

hi,

please see forwarded request below !

thanks,
besam

Begin forwarded message:

> From: Baron Schwartz <bar...@gm...>
> Date: January 20, 2014 at 12:20:23 PM EST
> To: Besam Khidhir <bkh...@gm...>
> Subject: Re: innotop committer ?
> 
> Sure! Ask on the mailing list, and leFred or Kenny should add you.
> 
> - Baron
> 
> 
>> On Mon, Jan 20, 2014 at 11:51 AM, Besam Khidhir <bkh...@gm...> wrote:
>> hi Baron,
>> 
>> i was wondering if i could join the innotop project: i would like to make a small addition to the code to allow innotop to run in "read-only" mode without the ability to kill a connection etc...
>> 
>> thanks,
>> besam
> 

[Innotop-discuss] innotop

[Kaushal S. <kau...@gm...>]

Hi

while configuring innotop on my linux (gentoo) host

Typical DSN strings look like
DBI:mysql:;host=hostname;port=port
The db and port are optional and can usually be omitted.
If you specify 'mysql_read_default_group=mysql' many options can be read
from your mysql options files (~/.my.cnf, /etc/my.cnf).

Enter a DSN string:host=localhost

I am stuck with this step when i give host=localhost above, I get

*"MySQL INNODB_STATUS: Can't connect to data source 'localhost' because I
can't work out what driver to use (it doesn't seem to contain a
'dbi:driver:' prefix and the DBI_DRIVER env var is not set) at
/usr/bin/innotop line 5409"
*
Am i missing something

Thanks and Regards

Kaushal

[Innotop-discuss] Version 1.5.2 of the innotop MySQL monitor released

[Baron S. <ba...@xa...>]

This release adds significant new features to make it possible to debug 
which transaction holds the locks for which another transaction is waiting.

This release is part of the unstable 1.5 branch. Its features will 
ultimately go into the stable 1.6 branch. You can download it from the 
innotop-devel package at the following URL:

http://sourceforge.net/project/showfiles.php?group_id=186074

Changelog:

* Added the ability to monitor InnoDB status from a file.
* Changed W mode to L mode; it monitors all locks, not just lock waits.

[Innotop-discuss] innotop 1.5.1 released

[Baron S. <ba...@xa...>]

This release is part of the unstable 1.5 branch. Its features will 
ultimately go into the stable 1.6 branch. You can download it from the 
innotop-devel package at the following URL:

http://sourceforge.net/project/showfiles.php?group_id=186074

Changelog:

2007-09-16: version 1.5.1

    * Added C (Command Summary) mode.
    * Fixed a bug in the 'avg' aggregate function.

[Innotop-discuss] innotop 1.5.0 released

[Baron S. <ba...@xa...>]

This release is part of the unstable 1.5 branch. Its features will 
ultimately go into the stable 1.6 branch. You can download it from the 
innotop-devel package.

Download:

http://sourceforge.net/project/showfiles.php?group_id=186074

Changelog for innotop and InnoDBParser:

2007-09-10: version 1.5.0

Changes:
* Added plugin functionality.
* Added group-by functionality.
* Moved the configuration file to a directory.
* Enhanced filtering and sorting on pivoted tables.
* Many small bug fixes.

[Innotop-discuss] innotop 1.4.2 released

[Baron S. <ba...@xa...>]

This release is a major upgrade, with new functionality, an improved interface, 
lots better error handling, and many bug fixes.

You can download it from http://sourceforge.net/projects/innotop.

A summary of the changes follows:

2007-05-03: version 1.4.2

    This version contains all changes to the trunk until revision 239; some
    changes in revisions 240:250 are included.

    MAJOR CHANGES:

    * Quick-filters to easily filter any column in any display
    * Compatibility with MySQL 3.23 through 6.0
    * Improved error handling when a server is down, permissions denied, etc
    * Use additional SHOW INNODB STATUS information in 5.1.x
    * Make all modes use tables consistently, so they can all be edited,
      filtered, colored and sorted consistently
    * Combine V, G and S modes into S mode, with v, g, and s hot-keys
    * Let DBD driver read MySQL option files; permit connections without
      user/pass/etc
    * Compile SQL-like expressions into Perl subroutines; eliminate need to
      know Perl
    * Do not save all config data to config file, only save user's customizations
    * Rewritten and improved command-line option handling
    * Added --count, --delay, and other command-line options to support
      run-and-exit operation
    * Improve built-in variable sets
    * Improve help screen with three-part balanced-column layout
    * Simplify table-editor and improve hotkey support
    * Require Perl to have high-resolution time support (Time::HiRes)
    * Help the user choose a query to analyze or kill
    * Enable EXPLAIN, show-full-query in T mode just like Q mode
    * Let data-extraction access current, previous and incremental data sets
      all at once

    MINOR CHANGES:

    * Column stabilizing for Q mode
    * New color rules for T, Q, W modes
    * Apply slave I/O filter to Q mode
    * Improve detection of server version and other meta-data
    * Make connection timeout a config variable
    * Improve cross-version-compatible SQL syntax
    * Get some information from the DBD driver instead of asking MySQL for it
    * Improved error messages
    * Improve server group creation/editing
    * Improve connection/thread killing
    * Fix broken key bindings and restore previously mapped hot-keys for
      choosing columns
    * Some documentation updates (but not nearly enough)
    * Allow the user to specify graphing char in S mode (formerly G mode)
    * Allow easy switching between variable sets in S mode
    * Bind 'n' key globally to choose the 'next' server connection
    * Bind '%' key globally to filter displayed tables
    * Allow aligning columns on the decimal place for easy readability
    * Add hide_hdr config variable to hide column headers in tables
    * Add a feature to smartly run PURGE MASTER LOGS in Replication mode
    * Enable debug mode as a globally configurable variable
    * Improve error messages when an expression or filter doesn't compile or has
      a run-time error; die on error when debug is enabled
    * Allow user-configurable delays after executing SQL (to let the server
      settle down before taking another measurement)
    * Add an expression to show how long until a transaction is finished
    * Add skip_innodb as a global config variable
    * Add '%' after percentages to help disambiguate (user-configurable)
    * Add column to M mode to help see how fast slave is catching up to master

    BUG FIXES:

    * T and W modes had wrong value for wait_status column
    * Error tracking on connections didn't reset when the connection recovered
    * wait_timeout on connections couldn't be set before MySQL 4.0.3
    * There was a crash on 3.23 when wiping deadlocks
    * Lettercase changes in some result sets (SHOW MASTER/SLAVE STATUS) between
      MySQL versions crashed innotop
    * Inactive connections crashed innotop upon access to DBD driver
    * set_precision did not respect user defaults for number of digits
    * --inc command-line option could not be negated
    * InnoDB status parsing was not always parsing all needed information
    * S mode (formerly G mode) could crash trying to divide non-numeric data
    * M table didn't show Slave_open_temp_tables variable; incorrect lettercase
    * DBD drivers with broken AutoCommit would crash innotop
    * Some key bindings had incorrect labels
    * Some config-file loading routines could load data for things that didn't
      exist
    * Headers printed too often in S mode
    * High-resolution time was not used even when the user had it
    * Non-interactive mode printed blank lines sometimes
    * Q-mode header and statusbar showed different QPS numbers
    * Formulas for key-cache and query-cache hit ratios were wrong
    * Mac OS "Darwin" machines were mis-identified as Microsoft Windows
    * Some multiplications crashed when given undefined input
    * The commify transformation did not check its input and could crash
    * Specifying an invalid mode on the command line or config file could crash
      innotop

Re: [Innotop-discuss] QCacheHit calculation

[Baron S. <ba...@xa...>]

Dane Miller wrote:
> Baron Schwartz wrote:
>>           q_cache_hit    => { src => 'Qcache_hits/Com_select', 
>>               trans => [qw(percent)] },
>>
>> Do you see anomalies with it?
> 
> I'm far from an expert, but my notes from Kristian Kohntopp's
> presentation "Monitoring MySQL" show a different calculation:
>   Hit-Ratio:
> qcache_hits*100 / ( qcache_hits + com_select )
> 
> (page 18 of slides):
> http://mysqldump.azundris.com/uploads/monitoring_mysql_slides_en.pdf
> 
> Dane
> 

Yes, I think that's the right formula.

By the way, you can edit these formulas through this admittedly 
circuitous route:

^ to open the table editor
? to see what the key bindings are
j/k to select the desired column
e to edit the column

... and so on.  FYI, you have to specify the variable names in the right 
lettercase (Qcache_hits, not qcache_hits) because Perl's hashes are 
case-sensitive.

I'll make this fix to the innotop code now.

Thanks,
Baron

Re: [Innotop-discuss] QCacheHit calculation

[Baron S. <ba...@xa...>]

Hi,

Dane Miller wrote:
> Baron Schwartz wrote:
>> Dane Miller wrote:
>>> How is QCacheHit calculated in innotop's Q output?
>> In 1.4.1, it is on line 956, in the expression
>>
>>           q_cache_hit    => { src => 'Qcache_hits/Com_select', 
>>               trans => [qw(percent)] },
>>
>> Do you see anomalies with it?
> 
> Maybe.  Is it a percentage? It's often over 100 on my boxes.

It's supposed to be, but it doesn't look right now that I look at it. 
It must be wrong.  I'm just looking at your next message and I think 
you've found the problem.

Re: [Innotop-discuss] innotop S shows zeroes

[Baron S. <ba...@xa...>]

Dane Miller wrote:
> Baron Schwartz wrote:
>> Okay, here's what's happening.  Even though skip-innodb isn't really 
>> defined, you can't call SHOW INNODB STATUS for some reason.  This can 
>> happen for many reasons.  I wrote about some of them here:
>>
>> http://www.xaprb.com/blog/2007/03/08/what-to-do-when-mysql-says-skip-innodb-is-defined/
> 
> Thanks Baron.  This is helpful and informative.
> 
>> The real problem with this is you only want data from SHOW STATUS and 
>> SHOW VARIABLES.  (Probably just SHOW STATUS, in fact).  It shouldn't be 
>> trying to call SHOW INNODB STATUS unless it needs data from it.  This is 
>> on the list of things to do.  It requires that innotop keeps track of 
>> the source for each bit of data and only fetch the ones it needs.  I'm 
>> not sure how much work this will be.
>>
>> As a workaround, I just added a skip_innodb config variable, and this 
>> will prevent SHOW INNODB STATUS being called and throwing an error if 
>> you set it.
>>
>> Would you mind getting the latest trunk source again, setting that 
>> variable and trying again?
> 
> Using innotop revision 236 with skip_innodb set to 1 ($ -> g ->
> skip_innodb) works well.  Thanks for the quick turnaround!
> 
> Here's the (correct!) output of S mode, with a 2sec delay interval:
>   Uptime
>   37946
>   37948
>   37950
>   37952
> 
> Dane
> 

Great, I'm glad that works OK now.  Only fetching from needed sources is 
  one of the top things I want to work on next.

Baron

Re: [Innotop-discuss] QCacheHit calculation

[Dane M. <da...@gr...>]

Baron Schwartz wrote:
>           q_cache_hit    => { src => 'Qcache_hits/Com_select', 
>               trans => [qw(percent)] },
> 
> Do you see anomalies with it?

I'm far from an expert, but my notes from Kristian Kohntopp's
presentation "Monitoring MySQL" show a different calculation:
  Hit-Ratio:
qcache_hits*100 / ( qcache_hits + com_select )

(page 18 of slides):
http://mysqldump.azundris.com/uploads/monitoring_mysql_slides_en.pdf

Dane

Re: [Innotop-discuss] QCacheHit calculation

[Dane M. <da...@gr...>]

Baron Schwartz wrote:
> Dane Miller wrote:
> > How is QCacheHit calculated in innotop's Q output?
> In 1.4.1, it is on line 956, in the expression
> 
>           q_cache_hit    => { src => 'Qcache_hits/Com_select', 
>               trans => [qw(percent)] },
> 
> Do you see anomalies with it?

Maybe.  Is it a percentage? It's often over 100 on my boxes.

Dane

Re: [Innotop-discuss] innotop S shows zeroes

[Dane M. <da...@gr...>]

Baron Schwartz wrote:
> Okay, here's what's happening.  Even though skip-innodb isn't really 
> defined, you can't call SHOW INNODB STATUS for some reason.  This can 
> happen for many reasons.  I wrote about some of them here:
> 
> http://www.xaprb.com/blog/2007/03/08/what-to-do-when-mysql-says-skip-innodb-is-defined/

Thanks Baron.  This is helpful and informative.

> The real problem with this is you only want data from SHOW STATUS and 
> SHOW VARIABLES.  (Probably just SHOW STATUS, in fact).  It shouldn't be 
> trying to call SHOW INNODB STATUS unless it needs data from it.  This is 
> on the list of things to do.  It requires that innotop keeps track of 
> the source for each bit of data and only fetch the ones it needs.  I'm 
> not sure how much work this will be.
> 
> As a workaround, I just added a skip_innodb config variable, and this 
> will prevent SHOW INNODB STATUS being called and throwing an error if 
> you set it.
> 
> Would you mind getting the latest trunk source again, setting that 
> variable and trying again?

Using innotop revision 236 with skip_innodb set to 1 ($ -> g ->
skip_innodb) works well.  Thanks for the quick turnaround!

Here's the (correct!) output of S mode, with a 2sec delay interval:
  Uptime
  37946
  37948
  37950
  37952

Dane

Re: [Innotop-discuss] innotop S shows zeroes

[Baron S. <ba...@xa...>]

Dane Miller wrote:
> ----- "Baron Schwartz" <ba...@xa...> wrote:
>> Dane Miller wrote:
>>> Sounds plausible.  I'm not using the hi-res time patch (btw, is that
>>> now included in 5.0.37 ?)
>> Actually, I refer to Perl's Time::HiRes, which I made non-optional 
>> recently.
> 
> oops.  I misunderstood... was thinking about a hi-res time patch for mysql.  I can confirm that my Perl has Time::HiRes

Good.  Then the only trouble with that was the way I used it in 1.4.1, 
which was buggy :-)

>>>> Are you willing to run the latest trunk code in Subversion?  That
>>>> might help debug it.
>>> Yeah, you bet.  I imagine I can http download the sources from
>>> http://innotop.svn.sourceforge.net/viewvc/innotop/trunk/
>> Yes, that's it.
>>
>> If you press $, then g and set 'debug' to 1, the latest trunk code
>> will throw a meaningful error message in the kinds of cases I think you
>> might be hitting.
> 
> Ok.  Here are fresh results with revision 235 (latest trunk code).  The zeros are gone, but I don't get output every interval.  It's hard to see below, but for an interval of 2, the data is refreshed at uptime 1443, 1469, 1537.  Also worth noting I have all myisam tables, but my.cnf does not contain 'skip-innodb' (although it did when I started this experiment).
> 
> ## innotop output:
> 
> Enter a new value for 'interval' (The interval at which the display will be refreshed.  Fractional values allowed.).
> Enter a value: 2
>      Uptime Qc_fr_blcks  Qch_fr_mry Qcache_hits  Qch_insrts Qc_lwm_prns  Qch_nt_chd  Qch_qrs_ch Qc_tl_blcks
> Error at tick 8 localhost Cannot call SHOW INNODB STATUS because skip-innodb is definedError at tick 8 localhost Cannot call SHOW INNODB STATUS because skip-innodb is defined       1443           1    16768448           0           0           0          22           0           1
> Error at tick 21 localhost Cannot call SHOW INNODB STATUS because skip-innodb is definedError at tick 21 localhost Cannot call SHOW INNODB STATUS because skip-innodb is defined       1469           1    16768448           0           0           0          24           0           1
> Error at tick 55 localhost Cannot call SHOW INNODB STATUS because skip-innodb is definedError at tick 55 localhost Cannot call SHOW INNODB STATUS because skip-innodb is defined       1537           1    16768448           0           0           0          29           0           1
> 

Okay, here's what's happening.  Even though skip-innodb isn't really 
defined, you can't call SHOW INNODB STATUS for some reason.  This can 
happen for many reasons.  I wrote about some of them here:

http://www.xaprb.com/blog/2007/03/08/what-to-do-when-mysql-says-skip-innodb-is-defined/

In any case, innotop sees the error and says "oh, it looks like 
localhost has a problem.  I'll just try later."  It avoids that 
connection for a while to avoid repeatedly erroring out (it waits for 
the Fibonacci series in fact), and retries.

The real problem with this is you only want data from SHOW STATUS and 
SHOW VARIABLES.  (Probably just SHOW STATUS, in fact).  It shouldn't be 
trying to call SHOW INNODB STATUS unless it needs data from it.  This is 
on the list of things to do.  It requires that innotop keeps track of 
the source for each bit of data and only fetch the ones it needs.  I'm 
not sure how much work this will be.

As a workaround, I just added a skip_innodb config variable, and this 
will prevent SHOW INNODB STATUS being called and throwing an error if 
you set it.

Would you mind getting the latest trunk source again, setting that 
variable and trying again?

Thanks
Baron

Re: [Innotop-discuss] innotop S shows zeroes

[Dane M. <da...@gr...>]

----- "Baron Schwartz" <ba...@xa...> wrote:
> Dane Miller wrote:
> > Sounds plausible.  I'm not using the hi-res time patch (btw, is that
> > now included in 5.0.37 ?)
> 
> Actually, I refer to Perl's Time::HiRes, which I made non-optional 
> recently.

oops.  I misunderstood... was thinking about a hi-res time patch for mysql.  I can confirm that my Perl has Time::HiRes

> >> Are you willing to run the latest trunk code in Subversion?  That
> >> might help debug it.
> > 
> > Yeah, you bet.  I imagine I can http download the sources from
> > http://innotop.svn.sourceforge.net/viewvc/innotop/trunk/
> 
> Yes, that's it.
> 
> If you press $, then g and set 'debug' to 1, the latest trunk code
> will throw a meaningful error message in the kinds of cases I think you
> might be hitting.

Ok.  Here are fresh results with revision 235 (latest trunk code).  The zeros are gone, but I don't get output every interval.  It's hard to see below, but for an interval of 2, the data is refreshed at uptime 1443, 1469, 1537.  Also worth noting I have all myisam tables, but my.cnf does not contain 'skip-innodb' (although it did when I started this experiment).

## innotop output:

Enter a new value for 'interval' (The interval at which the display will be refreshed.  Fractional values allowed.).
Enter a value: 2
     Uptime Qc_fr_blcks  Qch_fr_mry Qcache_hits  Qch_insrts Qc_lwm_prns  Qch_nt_chd  Qch_qrs_ch Qc_tl_blcks
Error at tick 8 localhost Cannot call SHOW INNODB STATUS because skip-innodb is definedError at tick 8 localhost Cannot call SHOW INNODB STATUS because skip-innodb is defined       1443           1    16768448           0           0           0          22           0           1
Error at tick 21 localhost Cannot call SHOW INNODB STATUS because skip-innodb is definedError at tick 21 localhost Cannot call SHOW INNODB STATUS because skip-innodb is defined       1469           1    16768448           0           0           0          24           0           1
Error at tick 55 localhost Cannot call SHOW INNODB STATUS because skip-innodb is definedError at tick 55 localhost Cannot call SHOW INNODB STATUS because skip-innodb is defined       1537           1    16768448           0           0           0          29           0           1


Dane

Re: [Innotop-discuss] innotop S shows zeroes

[Baron S. <ba...@xa...>]

Dane Miller wrote:
> ----- "Baron Schwartz" <ba...@xa...> wrote:
>> It might happen if you don't have high-resolution time 
>> support -- oh wait, there's actually  a bug with that in 
>> 1.4.1 that might be the cause!
> 
> Sounds plausible.  I'm not using the hi-res time patch (btw, is that now included in 5.0.37 ?)

Actually, I refer to Perl's Time::HiRes, which I made non-optional 
recently.  I had made it optional before, and thought it was therefore 
replacing Perl's built-in time() function with a high-resolution version 
of the same, but I discovered it wasn't after all.  So many things won't 
work well without it that I decided to just make it mandatory in 1.4.2 
anyway.  It's part of Perl's core modules so it shouldn't be a big deal, 
except perhaps in weird third-party Perl distributions or something.

>> Are you willing to run the latest trunk code in Subversion?  That
>> might help debug it.
> 
> Yeah, you bet.  I imagine I can http download the sources from http://innotop.svn.sourceforge.net/viewvc/innotop/trunk/
> 
> I'll report back tonight or tomorrow.

Yes, that's it.

If you press $, then g and set 'debug' to 1, the latest trunk code will 
throw a meaningful error message in the kinds of cases I think you might 
be hitting.

Baron

Re: [Innotop-discuss] innotop S shows zeroes

[Dane M. <da...@gr...>]

----- "Baron Schwartz" <ba...@xa...> wrote:
> It might happen if you don't have high-resolution time 
> support -- oh wait, there's actually  a bug with that in 
> 1.4.1 that might be the cause!

Sounds plausible.  I'm not using the hi-res time patch (btw, is that now included in 5.0.37 ?)

> Are you willing to run the latest trunk code in Subversion?  That
> might help debug it.

Yeah, you bet.  I imagine I can http download the sources from http://innotop.svn.sourceforge.net/viewvc/innotop/trunk/

I'll report back tonight or tomorrow.

Dane

Re: [Innotop-discuss] innotop S shows zeroes

[Baron S. <ba...@xa...>]

Hi,

Dane Miller wrote:
> Dane Miller wrote:
>> Uptime  Questions Com_delete Cm_dlt_mlt Com_insert Cm_in_slct    Cm_rplc
>> Cm_rp_slct Com_select Com_update C_updt_mlt
>>          0          0          0          0          0          0
>> 0          0          0          0          0
>>          0          0          0          0          0          0
>> 0          0          0          0          0
> 
> more info...
> Sometimes I get correct values.  When I first launch innotop I get this
> (truncated output): 
> 
> Uptime Questions
> 3718472 1338392876
> 0 0
> 3718482 1338395787
> 0 0
> 0 0

Almost certainly a bug involving an undefined value or division by zero 
in the extract_values() subroutine:

       eval {
          $result->{$key} = $info->{func}->($set)
       };
       if ( $EVAL_ERROR ) {
          $result->{$key} = $info->{num} ? 0 : '';
       }

It's getting some error and assigning zero so it can continue without 
crashing.  Any ideas what the error is?  The only thing I can think is 
a) the results of SHOW STATUS are somehow wrong, but I can't think of 
how, or b) you are in 'incremental' mode to see the differences between 
sets, and something is wrong with subtracting sets.  It might happen if 
you don't have high-resolution time support -- oh wait, there's actually 
a bug with that in 1.4.1 that might be the cause!

Are you willing to run the latest trunk code in Subversion?  That might 
help debug it.

Baron

Re: [Innotop-discuss] QCacheHit calculation

[Baron S. <ba...@xa...>]

Hi,

Dane Miller wrote:
> Hi again,
> 
> How is QCacheHit calculated in innotop's Q output?
> 
> Dane

In 1.4.1, it is on line 956, in the expression

          q_cache_hit    => { src => 'Qcache_hits/Com_select', 
              trans => [qw(percent)] },

Do you see anomalies with it?

Baron

Re: [Innotop-discuss] innotop S shows zeroes

[Baron S. <ba...@xa...>]

Hi Dane,

Dane Miller wrote:
> Hi Baron (and others?),
> 
> I'm using innotop 1.4.1 from FreeBSD ports, and am confused by the S
> (Load Statistics) output.  It mostly shows zeroes.  Here's a snip
> running with a 2sec polling interval on a box doing 400 qps ...
> 
> Uptime  Questions Com_delete Cm_dlt_mlt Com_insert Cm_in_slct    Cm_rplc
> Cm_rp_slct Com_select Com_update C_updt_mlt
>          0          0          0          0          0          0
> 0          0          0          0          0
>          0          0          0          0          0          0
> 0          0          0          0          0
>          0          0          0          0          0          0
> 0          0          0          0          0
>          0          0          0          0          0         
> 
> What's going on?  By comparison, innotop's Q output shows queries flying
> by.
> 
> 
> OS: FreeBSD 6.2
> perl: v5.8.8
> mysqld: 5.0.33 (started with --skip-innodb)
> innotop user has SUPER privs
> 

I'm not sure what could be happening.  It sounds like there is a bug 
somewhere, maybe an undefined value is making innotop throw and catch an 
exception, and when it does that it's just substituting a zero.

I'll add code to catch what I think might be happening when debug is 
enabled (the debug variable in the global config section).  A similar 
bug was the cause of quick-filters not working during my demo on Thursday.

Baron

Re: [Innotop-discuss] innotop S shows zeroes

[Dane M. <da...@gr...>]

Dane Miller wrote:
> Uptime  Questions Com_delete Cm_dlt_mlt Com_insert Cm_in_slct    Cm_rplc
> Cm_rp_slct Com_select Com_update C_updt_mlt
>          0          0          0          0          0          0
> 0          0          0          0          0
>          0          0          0          0          0          0
> 0          0          0          0          0

more info...
Sometimes I get correct values.  When I first launch innotop I get this
(truncated output): 

Uptime Questions
3718472 1338392876
0 0
3718482 1338395787
0 0
0 0

[Innotop-discuss] QCacheHit calculation

[Dane M. <da...@gr...>]

Hi again,

How is QCacheHit calculated in innotop's Q output?

Dane

[Innotop-discuss] innotop S shows zeroes

[Dane M. <da...@gr...>]

Hi Baron (and others?),

I'm using innotop 1.4.1 from FreeBSD ports, and am confused by the S
(Load Statistics) output.  It mostly shows zeroes.  Here's a snip
running with a 2sec polling interval on a box doing 400 qps ...

Uptime  Questions Com_delete Cm_dlt_mlt Com_insert Cm_in_slct    Cm_rplc
Cm_rp_slct Com_select Com_update C_updt_mlt
         0          0          0          0          0          0
0          0          0          0          0
         0          0          0          0          0          0
0          0          0          0          0
         0          0          0          0          0          0
0          0          0          0          0
         0          0          0          0          0         

What's going on?  By comparison, innotop's Q output shows queries flying
by.


OS: FreeBSD 6.2
perl: v5.8.8
mysqld: 5.0.33 (started with --skip-innodb)
innotop user has SUPER privs

Dane