Bytes Sent Confusion

[Steve Bond]

Hello MonYoggers,

I have some questions about the data displayed as 'Bytes Sent to All Clients' within the monitors and advisors in MONYog.

I can see that the data is collected from the 'Bytes_Sent' global status item in MySQl itself, and that the data appears to be a cumulative total since the server came up.

Within the customisation page for the advisor I can see that the 'Graph' option is not enabled, however there is a Graph.

The graph does not appear to show the data collected from the bytes_sent collection but much lower values.

– Currently I am assuming that this is the difference between the last 2 collections. Can anyone confirm / deny this?

– Secondly I am interested in what occurs if a collection fails. Can anyone provide this information? Is collection result data logged anywhere?

We are seeing points on this graph which drop down to 0 at seemingly random intervals. (See Attachment)

I would like to identify whether this is a collection failure, a true network traffic interruption or just a quiet minute.

– Collection failure seems more likely as we are not experiencing any application problems and this server in question is under production load all day.

Thanks in advance for any insight.

Steve

[Mahesh]

Quote:

I can see that the data is collected from the 'Bytes_Sent' global status item in MySQl itself, and that the data appears to be a cumulative total since the server came up.

Within the customisation page for the advisor I can see that the 'Graph' option is not enabled, however there is a Graph.

— Actually if a counter is UPTIME based(You can check by Editing counter definition) then MONyog shows Graph for those irrespective whether chart is Enabled/Disabled.

Quote:

The graph does not appear to show the data collected from the bytes_sent collection but much lower values.

– Currently I am assuming that this is the difference between the last 2 collections. Can anyone confirm / deny this?

— Graph always plots values based on Delta (difference between last 2 collections).

Quote:

– Secondly I am interested in what occurs if a collection fails. Can anyone provide this information? Is collection result data logged anywhere?

— If there is no connection between MONyog and MySQL server then data won't be collected and chart will show blank during that period, once MOnyog starts collecting data chart will populate based on newly collected data again.

MONyog does sends an alert if MySQL server is not reachable because of reasons like MySQL server is not running, Credintials were changed/wrong etc..

Collection result data will log information not only if there is active connection between MONyog and MySQL but also if there is no connection.

Quote:

We are seeing points on this graph which drop down to 0 at seemingly random intervals. (See Attachment)

I would like to identify whether this is a collection failure, a true network traffic interruption or just a quiet minute.

– Collection failure seems more likely as we are not experiencing any application problems and this server in question is under production load all day.

— Can you check History/Trend for “General Info” — “Available” group for a period you observe this. If there is “No” entry in report which matches exactly at time when bytes_sent graph shows 0, then we can conclude that there is a network related issue.

What does history/trend report shows during a period when bytes_received shows 0 in graph.

Also What does MONyog.log says during a period when bytes_sent shows 0.

I guess there might be network failure.

[Steve Bond]

Hi Manesh,

Thanks for the detailed response.

I've checked the monyog.log and although this does show several connection/collection failures to the server in question they are not at the time of the drop to 0 on the graph.

– The collections are done over a VPN to a remote site so this isn't necessarily unexpected.

Also by setting the history/trend to cover the minute during which the graph dipped to 0 monyog shows 'yes' in the availability indicator.

[Mahesh]

Then during that point-in-time bytes_sent value might be 0.

Please check History/Trend report without using any GROUP By option.

While generating chart uncheck option called “Group by” and see report and compare against point-in-time where graph dipped to 0 in monitors page.

For example:

If bytes_sent graph shows value 0 at 12:15:00 then generate report without using Group by option between 12:00:00 to 12:30:00 and check value at 12:15:00, Does value matches?

[Steve Bond]

Thanks for the tip about the grouping.

Looking at the bytes sent and bytes recieved data for a 10 minute period around the dip it would appear the server was receiving data but not sending any for the minute between those collections.

Expanding the time period out there appears to be severel dips in received and sent data (at different times) over a 2 hours period.

There is also a massive spike in sent bytes (4.2G) which i don't believe is even possible in a minute.

Looks pretty nasty, leaning toward a possible switch issue for the dips. no idea about the spike!!

[Mahesh]

Please tell MONyog version you are using?

Also We need mysql.data file of a server for which bytes_sent shows spike of (4.2G) for a minute.

Please create a support ticket by sending an email to “[email protected]” for privacy.

We will provide you FTP details over ticket.

Thanks,

Mahesh

[Steve Bond]

I've just been reviewing the thread and realised it didn't post the ultimate outcome.

I sent the mysql.data file for the offending server from MonYog over to the webyog support guys and got the following response:

Quote:

Hi Steve,

Thanks for the mysql.data file. On analyzing the file we found that there was really a spike in the Bytes_sent value. The previous value of Bytes_sent was 37905826139, which jumped around 4.2GB to 42506680344 in 1 min duration.

We are still analyzing this case and trying to find if there is any bug on our side. We will update accordingly.

Followed by the final assessment of the situation:

Quote:

Our analysis shows that this happens due to overflow of a 32-bit Integer used for containing the status variables by the MySQL server.

Please see the report http://bugs.mysql.com/bug.php?id=42698 (what I posted to bugs.mysql.com myself 2½ years ago). A server restart will reset the status variable to ZERO. You may schedule such daily or weekly for instance.That (and an upgrade to MySQL 5.6.3 – but this is still an early beta) is the only solution if traffic is so heavy that the 32-bit integer will overflow between occasional restarts.

In our case we were just about to migrate our production databases over to MySQL 5.5 on separate servers, so the counters were 'reset' for now.

[peterlaursen]

OK … but you can always reset by executing FLUSH STATUS.

[Author]

Posts