Update: Thank you all for making this campaign a colossal success. We are extending this offer till Dec 2nd, 23:59 PST. Many corporate users requested us to extend the offer as they require time to get official approval. Pick your copy right now! Use coupon code blkfrdy11 to get 50% off.

–

Happy Thanksgiving!

Black Friday is back with a bang. Get a flat 50% discount on all Webyog products. Yes, you read it right, a flat fifty percent discount. Hurry, this offer expires Nov 28th Dec 2nd, 23:59 PST. Use coupon code blkfrdy11 to avail the discount on any purchase. Buy Now.

Still using SQLyog Community Edition?

Upgrade to the feature rich SQLyog Professional/Enterprise/Ultimate Edition. This offer is literally too good to pass up. Compare features.

Worried about your MySQL server’s health?

Monitor it like a PRO. Get MONyog – MySQL Monitor & Advisor. Your MySQL DBA in a box! Check what it has to offer.

Want to extend your maintenance period?

Don’t think twice, head right away to Customer Area & save a flat 50%. On extension, you get free access to all future releases of the respective products for one year.

Hurry, this offer expires Nov 28th Dec 2nd, 23:59 PST. Use coupon code blkfrdy11 to avail the discount on any purchase. Buy Now.

Regards,
Chirag
Webyog, Inc.

Comments(5)

I have for the first time been spending some time trying to understand the performance_schema. It is not easy to understand everything unless you are very well-versed in server internals (what I am not) and much information available here is probably more useful for server developers and testers than for ordinary users. But anyway some of the P_S tables are reasonable simple and useful. For instance the ‘accounts’ and ‘hosts’ tables (introduced in MySQL 5.6x) are immensely useful for everybody.

The reason why I spent time with this now was (I am totally egoistic, of course) that we just released the first beta in a new MONyog release cycle where you may expose P_S contents for monitoring. Please refer this Blog.

However I have two concerns with the P_S implementation. This derives from the fact that P_S is to some extent  updateable for users having sufficient privileges. You may for instance disable/enable ‘consumers’ and decide whether information should be recorded in counts of CPU clock-cycles or microseconds etc. Also some tables may be truncated in order to discard old information and free memory.

The interface for this is standard SQL statements (UPDATE, TRUNCATE). IMHO this leads to two problems/concerns:

1) Server restart. If the server restarts all P_S settings are reset to default. The UPDATEs from last running instance are lost. I am  simply missing a mechanism to load the UPDATEs again automatically at startup. I do not favour  introducing a lot of new server startup options and variables (that would be around 100 I think if all cases should be covered and there already are more than enough options IMHO). One option could be a P_S configuration file (‘performance_schema.ini’) or maybe an EVENT executing at startup (“at startup” could be a useful schedule setting for an EVENT in other contexts as well – but it is not in any server version currently). Also the problem cannot be worked around an automated way currently on Windows as far as I can see, as on this platform the server is not started by a ‘script’ but by an executable (the ‘Windows Service Manager’ reading details from a registry key). On Unix-type platforms you may (I think so!) modify the server startup script adding a call to Perl/Python/whatever script performing the updates on the P_S tables.

2) Multi-user/multi-admin environment. If for instance GRANTS for ‘peter’@'thishost’ are like “GRANT CREATE USER, SELECT,UPDATE ON *.* TO ‘peter’@'thishost’ WITH GRANT OPTION;” then peter may “GRANT SELECT,UPDATE ON performance_schema.* TO ‘jimmy’@'thathost’;”. Now both peter and jimmy can UPDATE the P_S tables that are updateable. But the problem is that one of the users may do so without the knowledge of the other resulting in unexpected results. The only solution I found was LOCKING (example: “LOCK TABLES performance_schema.setup_consumers READ;“). I don’t find it fully satisfactory however, but I have no better solution with current implementation and also no usable idea for an improved implementation.  

Any thoughts?

Comments(5)

Introduction:

If you have been using MONyog you will know that any metrics/counters may be identified with either of the ‘states’ STABLE, WARNING and CRITICAL. For those metric where it is relevant MONyog ships with settings for this that are (to the extend possible) commonly agreed ‘best practices’ by MySQL DBA’s. Metrics in a WARNING or CRITICAL state display with a (yellow or red) ‘marker’ indicating that this metric is not in a STABLE state. For metrics in a CRITICAL state further an alert can be sent (as a mail alert and/or a SNMP trap).

If the ‘best practices’ we have implemented in MONyog do not fit your environment or use case, it can easily be customized. Open the MONyog ‘Monitors/Advisor’ page, click on the name of the metric you want to adjust (it is a link). A small popup opens. As an example let us take the ‘Connection usage’ in the ‘Current connections’ group. In the popup you will see the settings for this metric. They are defined like this

Warning = 75
Critical = 85

To change the settings click ‘Customize’ in the popup and next ‘View Advanced’ to see all options. It will open in a new browser tab. If you are willing to allow the number of current connection to reach 90% of the max_connections allowed before the state should change to CRITICAL  just enter “90″ as the value for the threshold of the CRITICAL state and save.

Differentiating thresholds for different MySQL servers:

What we described above will have effect for all MySQL servers monitored. It was also meant to be an introduction only.  The real  question to be dealt with here is different however: Is it possible to have different ‘state’ settings for different MySQL servers?

The answer is YES, and it is very simply to do actually. Say you monitor 2 servers that you in MONyog have named “Testserver” and “Production” respectively, and that you want a CRITICAL setting of “90″ for “Testserver” and “80″ for “Production”. Then the CRITICAL setting is not a constant (applying for all MySQL servers) anymore, but a condition needs to be added. MONyog exposes connection details to different MySQL servers monitored as Javascript objects that can be referenced with a simple if/case-condition. And it is very simple to work with. Just replace the constant with a (javascript-)function like this

function()
{
if(MONyog.Connections.ConnectionName == “Testserver”) return 90;
if(MONyog.Connections.ConnectionName == “Production”) return 80;
}

Below a (reduced) screenshot of values entered in the customizations page:

.. and now save. That is all. Now the CRITICAL condition for this metric is defined differently for the MySQL servers “Testserver” and “Production”.

Note that everything happens centrally at the MONyog level and there is nothing to do on the MySQL servers monitored. And also there is no need for any other program or utility (such as a database client or whatever) to do this. MONyog is agent-less and self-contained.

The objects that can be referenced in the customization interface are listed in the MONyog documentation here along with the explanation of the ‘MONyog Object Model’: http://www.webyog.com/doc/MONyog/MONyog_object_model.htm

In the above image we have defined different WARNING and CRITICAL values for another metric (‘percentage of max_allowed reached’ in the ‘Connection history’ group) for two servers: For both servers WARNING is set at 84% and CRITICAL at “Testserver” is set at at 90% and at “Production” CRITICAL is set at 87%. You will notice the red and yellow ‘markers’ displaying accordingly.

(There is one more detail you should be aware of: MONyog will not necessarily alert using mail or SNMP first time a CRITICAL value has been reached. There is a setting for this as well. The default setting is that the CRITICAL condition must have been in existence for 5 consecutive data retrievals from MySQL. This setting is specific for every MySQL server registered in MONyog and is available  in the MONyog ‘Register servers’ page for each server, but the value can be overridden for an individual metric by setting the “RetryOverride” value from the customizations page. Please be aware of this when testing or you may become confused why you don’t get the alerts you’d expect)

Download the MONyog whitepaper: http://www.webyog.com/en/whitepapers/MONyogWhitePaper.pdf
Read the MONyog documentation online: http://www.webyog.com/doc/index.php
Download MONyog TRIAL: http://webyog.com/en/downloads.php
Purchase MONyog: http://webyog.com/en/buy.php

Comments(0)

SSL-users in MySQL seem to cause quite a lot of problems for people. Quite a lot af bug reports have been posted to bugs.mysql.com over time that have most or all been classifed as ‘not a bug’. Numerous discussions exists on the Internet as well and people find weird workarounds like directly manipulating the mysql.user table.  I write this Blog because yesterday I found a discussion in a Forum where a dozen of self-appointed ‘experts’ tried to help a newbie with this causing only more confusion.

First problem: Let us try

DROP USER /*!70101  IF EXISTS */ ssss@localhost — just a ‘sidekick’, but not the point here
CREATE USER ssss@localhost;
GRANT UPDATE ON ttest.* TO ssss@localhost REQUIRE SSL;
GRANT SELECT ON ttest.* TO ssss@localhost;

Some people expect that a client would connect without encryption and would be able to SELECT from table (but not UPDATE) in the `ttest` database. But connection without encryption is not possible at all. SSL is required for authentication. Let us SHOW GRANTS:

SHOW GRANTS FOR ssss@localhost;
/* returns

Grants for ssss@localhost
——————————————————-
GRANT USAGE ON *.* TO ‘ssss’@'localhost’ REQUIRE SSL
GRANT SELECT, UPDATE ON `ttest`.* TO ‘ssss’@'localhost’
*/

Second problem:

DROP USER /*!70101 IF EXISTS */ ssss@localhost
CREATE USER ssss@localhost;
GRANT UPDATE ON ttest.* TO ssss@localhost REQUIRE SSL;
GRANT UPDATE ON ttest.* TO ssss@localhost;

Some people expect that this will “REVOKE”/REMOVE ‘REQUIRE SSL’ from the user as it is not specified in the last statement. But it does not:

SHOW GRANTS FOR ssss@localhost;
/* returns

Grants for ssss@localhost
——————————————————-
GRANT USAGE ON *.* TO ‘ssss’@'localhost’ REQUIRE SSL
GRANT UPDATE ON `ttest`.* TO ‘ssss’@'localhost’
*/

From the returns from SHOW GRANTS it is clear that SSL settings are global for user (used for authentication) and in GRANT syntax linked to the “USAGE” privilege (or rather “no-privilege acronym”). This is expected, it is documented but still confuses a lot of people.

This will do:

GRANT USAGE ON ttest.* TO ssss@localhost REQUIRE NONE;
/* returns

Grants for ssss@localhost
———————————————–
GRANT USAGE ON *.* TO ‘ssss’@'localhost’
GRANT UPDATE ON `ttest`.* TO ‘ssss’@'localhost’
*/

(and “GRANT UPDATE ON ttest.* TO ssss@localhost REQUIRE NONE;” would do excatly the same BTW in this case)

The point:

IMHO it is an illogical mess-up that SSL settings for a user are specified along with specific privileges (in a GRANT statement). A more logical way to specify SSL settings for a user would be to have the REQUIRE clause with CREATE USER – ie.

CREATE USER ssss@localhost REQUIRE SSL;
GRANT UPDATE ON ttest.* TO ssss@localhost;
(and then an ALTER USER statement would also be nice)

However historically “GRANT” is a much older statement in MySQL than “CREATE USER” (“CREATE USER” was introduced in MySQL 5.0 and “GRANT” very much earlier). So that is where we are now – trapped by history here we cannot make things logically right unless breaking compability!

I also recognize that many people/clients will never issue a CREATE USER statement as GRANT will create the use implicitly (if not exists) provided that the ‘no_auto_create_user’ SQL-mode  is not SET. But then the option to specify REQUIRE could be in both places.

Similar considerations actually also applies to

Third problem: How to change a password for a user? It may be done like this (not manipulating the mysql.user table directly):

GRANT USAGE ON *.* TO ‘ssss’@'localhost’ identified by ‘newpw’;

Again I think an ALTER USER statement would be the logically correct way:

ALTER USER ‘ssss’@'localhost’ identified by ‘newpw’;

.. as also password is not linked to specific privileges, but to user and authentication as such.

Comments(4)

Please note: This Blog was updated with a few clarifications on October 21st 2011.

As we announced in the release Blog for SQLyog version 9.3 we here publish instructions and tools for localizing SQLyog.

To understand how localization works you should first open the SQLyog 9.3 installation folder on your system. Inside it there is a (SQLite) database file named “L10n.db”. It contains all strings in all localizations distributed by us (currently English and Japanese) displayed by SQLyog GUI. If you have selected to run SQLyog in a non-English language SQLyog will load the localized strings from this file and use them for display and not the English strings.  To enable more languages just copy an updated “L10n.db” file with support for more languages into the SQLyog installation folder.  

The tools for localization are available from the SQLyog Community repository at Googlecode (http://code.google.com/p/sqlyog/). It is the contents of the ‘localization’ folder in the ‘source’ tab. From here on we will use the term SQLyog localization kit for the contents of this ../localization/ folder. To check out the localization kit for the latest SQLyog GA release use the link https://sqlyog.googlecode.com/svn/branches/stable_ga/localization/(and https://sqlyog.googlecode.com/svn/trunk/localization/ for the latest public release whether beta, RC or GA) for your SVN client (TortoiseSVN recommended for most Windows users). It contains tools and resources needed to add more languages/localizations to the “L10n.db” file.

Let us start listing the content:

* In the ‘bin’ folder you will find a “L10n.db” database completely identical to the one shipped with the SQLyog installer.

* In the ‘Strings’ folder you will find a XML-file named “Config.XML” and (in a recursive “String” folder) a folder for each language supported (named “en” and “ja”). In each of those folders you will find a number of XML files (following ‘Android XML’ specification) with English and localized Japanese strings respectively.

* The batch file ‘compile.bat’.  It is a batch script calling a ‘compiler’ that generates an updated “L10n.db file” based on the content of the “Strings” folder.

* The ‘Tools’ folder is not something you should normally care about. It contains some resources, shared libraries and executables etc. (such as the ‘compiler’ referred to above).  The content of it is used by the ‘compile.bat’ file – and not by user/translator directly.  

To make a translation there are bascially 4 steps:

1)

First step is to define a new language in the “Config.XML” file. We will assume that we are translating to German. In the passage that looks like

<language>
<ja langname=”日本語” />
</language>

.. add support for German like this:

<language>
<ja langname=”日本語” />
<de langname=”Deutsch” />
</language>

“de” is the language code and “Deutsch” is how it will display in the SQLyog UI. Please note that we use the language codes from this Microsoft document. It does not matter currently actually, but it may later be used for auto-detection of some LOCALE-specific parameters (decimal format, date format etc.), so please stick to the Microsoft recommendation unless there is a compelling reason not to do so. Also be careful not to change the encoding of the file. It is UTF8 and should remain so.

2)

Make a copy of the “en” folder and rename the copy “de”.

3)

Now comes the hard work. Translate the XML files in the “de” folder from English to German. And again be careful not to change the encoding of the files.

Also note the details:

* XML standards for encoding of special characters must be honoured (‘&apos;’ for “‘” (apostrophe) etc.). The characters that should be encoded are  & (&amp;), < (&lt;), > (&gt;) , ” (&quot;) and ‘ (&apos;) – and NO MORE! This is XML and not HTML!

* occurrences of “%d” and “%s” must be kept as they are and should be in the same order they appear in “en”. Failure to do so will result in an error in the next step.

* Also keyboard shortcuts are handled from the XML files. Actually there are two kinds of keyboard shortcuts in SQLyog (like in most Windows programs):

a) One kind is ‘static shortcuts’.

Those are the ones the you find listed in the “help .. keyboard shortcuts’ menu. Let’s have a look at a randomly picked string in English here:

<string name=”1027″>Schema Synchronization Tool (Ctrl+Q)</string>

The substring “(Ctrl+Q)” should not be translated. This kind of keyboard shortcuts are not localized. “(Ctrl+Q)” is just part of what is displayed. It is a constant string. The functionality of this type of shortcut is hardcoded into SQLyog.

b) ‘language dependent shortcuts’.

This is a Windows feature that it seems a lot of people don’t really know about. To understand what it is (if you don’t) just open SQLyog (in English) and press the ALT key. You will see that some letters in the menu become underlined.  For instance in the menu item “Table”, the “a” is underlined. You may next open the table menu by pressing “a” and even continue selecting from the submenu pressing a single letter key. In Windows this is achieved by preceeding “a” with an “&” in the menu (where it is not displayed – it only ‘codes’ the “a” to be a shortcut). So Windows ‘knows’ this menu item as “T&able” internally. That string is also what the “L10n.db” database contains.  Do not forget here that in the XML files “&” needs to be encoded as “&amp;”. So the German string in the XML file for the “Table” menu item could be “T&amp;abelle” (if you want to keep “a” as the ALT-keyboard shortcut in German). When choosing this type of shortcuts you should be careful not to use the same more than once in same menu level and you should of course try to follow de-facto standards as used in localized Windows itself, utilities that ship with Windows (Notepad etc.) as well as commonly used Windows programs (like office suites, browsers etc.).

Also you may use XML/HTML-comments in the XML-files.  That could be useful for instance if more people share the work of a translation or if there is something that you want to identify easily later.

A concluding comment on editors: Some editors may have issues with UTF8 and they should not be used. Notepad will work fine but it does not support syntax highlighting, auto-indenting and similar ‘developer features’ that are convenient to have. We have checked with Notepad++ that works fine – but there are undoubtedly dozens of editors available out there that will do the job. And also do not use a Word Processor – it should be a plain text editor.

4)

Once you have completed the translation of the XML files just execute the ‘compile.bat’ file from command line. German strings from the XML files you translated will be inserted to the ‘L10n.db’ database in the ‘bin’ folder. The updated ‘L10n.db’ can now be copied into the SQLyog installation folder and SQLyog will have the option for German language.  

Finally please note that we have a category in our Forums dedicated to localization.  If you are facing a problem feel free to discuss with us or fellow countrymen for details of a translation.

Comments(0)

We are pleased to announce the release of MONyog 4.7 GA. Below is a brief on new features:

Dashboard

The world is moving towards tablets (I agree iPad in the title is a misnomer) and most of them don’t support Adobe Flash. As you know MONyog dashboard charts were on Flash and did not work on tablets. With this release we have switched to HTML5 charts. Not only do they work on all Smartphones and Tablets, they are faster than Flash charts. Hence, desktop users also gain from this release.

Flash charts used elsewhere in MONyog are also changed to slick HTML5 charts.

Embedded in this post are screen-shots with relevant section zoomed-in on an iPad.

MONyog dashboard in action

Disk Usage Info

Wayback Machine

Who doesn’t like Wayback Machine? Well, MONyog gets one of its own. A neat way of tracking MySQL variables/Status and Queries fired while looking at historic “Number of threads connected” & “Number of slow queries” data. The user gets a chance to see the graphs of “Number of threads connected” & “Number of Slow Queries”, typically a spike on this chart would need attention. Zooming on this spike gives details like Status/Variables/Queries in that zoomed time range. We can also get details at a certain point in time.

Wayback Machine

Replication Tab

Monitoring replication is now even easier. Thanks to the all new ‘Processlist’ like interface to monitor MySQL replication. This tab details the current MASTER & SLAVE STATUS.

MONyog customers can download the latest installer from Webyog’s Customer Portal.

To evaluate MONyog, please download the 30-day trial.

We are very excited about this release, and hope you like it. We would love to hear from you.

Regards,
Chirag
Team MONyog

Comments(2)

“Publishing software in English will make you reach most of the global audience” is a myth. Users like software in their own language. For Non-English speaking audience localized software is a necessity. We heard it. SQLyog is now available in Japanese & will be made available in other international languages soon. We are using crowd-sourced human translation services from myGengo for translating SQLyog. I’d also like to add that our website is machine translated using Google Translate.

Embedded below are some related screenshots:

Option to change language

SQLyog in Japanese

If you want to do your own translation, we will soon provide instructions and tools for creating localizations as a ‘drop-in’ solution to an already installed instance. Watch this space for a post on it.

We are very excited about this new 9.3 release and would love to have your feedback. What other languages would you like SQLyog in?

Regards,
Chirag
Team SQLyog

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

Comments(5)

We have released SQLyog 9.2 GA with enhancements to the Data Search feature (and more).

Since we introduced the Data Search feature in SQLyog 9.1 we had a lot of positive responses – but also a few critical remarks that using the feature could cause unnecessary server load as well as unnecessarily long response times. Such scenario could arise when searching for a string in a BLOB column used for storing media files for instance. Or when searching all tables of a database when there was only need to search a few tables.

We have addressed this concern by adding filter options that let the user restrict the search to specific data types and to a subset of databases of a server, a subset of tables of a database or a subset of columns of a table.

Also we have added “+” and “-” operators for inclusive and exclusive exact match.

I would like to elaborate a little more on Data Search:

Data Search does not replace SQL, of course. It is a supplementing feature. It is in particular useful when your are searching for something you don’t know what exactly is and don’t know exactly where to find. And when you are just too lazy to write a long SQL statement. As we have posted here before you could consider the Data Search feature as a tool to ‘google your database’ (as google ‘advanced search’ operators are used). But a database has a hierachy and has datatypes what a document has not. So this filtering option is a logical database-related enhancement to the google ‘advanced search’ syntax used for documents.

Let us take an example: Suppose you want to find all instances of email addresses with a specific domain name in all your networked systems (on the Internet as well as Intranet). We have 3 such public systems (our Forums, Blog and FAQ) for our MySQL-related products alone  that are ‘standard applications’ that we did not code ourselves and thus do not know internals about very well. In all those systems people may comment or contact us. Add to this our non-public systems – like our CRM system and our support ticket system (based on our own web application IssueBurner that aggregates everything sent from and received to our contact email addresses to a database). As all the mentioned systems use a MySQL backend we will now easily be able to answer the question “Who have ever contacted us with a @like.this email address, when did it happen and what was the subject/matter?”. Simply because we can find the data in all systems. And anybody in our organization can do (provided that they have access) without knowing details about how and where the different applications store the information.

When we introduced Data Search in 9.1 I actually expected some comments that “this is a feature for amateurs and I do not intend to use it as I am familiar with SQL”. We did not get such comments till now! I think users already found out that it saves a lot of time.

Also in this release we are following up on the ‘Foreign Key lookup’ introduced in 9.0. This is now also functional from the RESULT tab in SQLyog.

And finally In this realease we added a ‘date picker’ GUI for managing DATE, DATETIME and TIMESTAMP columns as well as an option to clone a connection. Both were popular user requests for some time and have now been implemented.

See all details for this and other recent releases here.

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

Comments(1)

We are often asked by users deploying MONyog what hardware system they should plan for it. Typically they have been evaluating and testing with a few MySQL servers only. Now after evaluation they are planning the deployment and  users that want to monitor a large number of (local/LAN-based, remote/hosted and Cloud-based) MySQL servers from a single dedicated MONyog machine will often ask us questions like

* How many MySQL severs can be handled by a single MONyog instance?
* How powerful should the CPU be? Any specific model(s) recommendation?
* Is MONyog multithreaded and will it take advange of multi-core architectures?
* How much memory is required?
* Are there any requirements or recommendations for the storage system?
* Will MONyog do better with advanced storage systems (SAN, RAID setups, solid state storage systems)?

Here we will concentrate on one deployment scenario:  the scenario where the user want to monitor a large number of MySQL servers from a single MONyog instance on a dedicated machine (running MONyog alone or shared with other utilities such as network monitoring systems) placed in their Intranet environment.  Note that this is not the only deployment scenario however – in particular we have noticed that an increasing number on users deploy MONyog on the Cloud. This includes an Amazon EC2 micro-instance (free for 1 year, and then $14/month) from where you may monitor a handfull of MySQL instances. But let us concentrate here on the ‘traditional’ scenario: monitoring a large number of MySQL servers from a single MONyog instance.

The short answer is “Just relax.  MONyog handles monitoring hundreds of MySQL servers from a single instance using a cheap ‘state of the art commodity system of today’”.

The longer answer (aggregated from a few replies to users in our support ticket system over the last months) could be this:

* General system considerations: You can safely monitor 200+ servers on a ‘state-of-the-art commodity machine’. This may maybe not quite be understood as ‘a machine you buy in the supermarket around the corner for 500 $’, but so-called ‘dedicated server hardware systems’ are not requried at all.  MONyog simply does not need it due to its lightweight design.  Look for a good quality ‘workstation machine’ or similar simply. We have actually been able to monitor 500 MySQL servers with a sample interval as low as 1 second from a Dual Core 3 Ghz machine. However the load (CPU and I/O) will of course depend what requests the users sitting in front of their browsers send to Monyog.  There are some functionalities/reporting modules that take more resources than others. Thus the ‘conservative’ statement that “You can safely monitor 200+ servers on a ‘state-of-the-art commodity machine’.” (but you may very well be able to do more, actually!)

* Multithreading: MONyog is very much multithreaded. For every MySQL server monitored a seperate thread will run. If you enable OS monitoring one more will run for each. One more for slave monitoring if you use it. Other threads handle I/O from and to SQLite, serve HTTP-requests, send mail alerts etc. With 200 MySQL servers you will likely have 500-1000 active threads inside the MONyog process. But this is not much related to number of CPU cores. You can have multithreaded systems running on a single core system. Multithreading is a software concept – not a hardware concept. Actually we primarily stress-test MONyog  on a 3 Ghz CoreDuo machine running 64 bit (CentOS) Linux. We have other systems  – including a 4-5 year old 32 bit Pentium 4  (single core) machine used for testing with 32 bit Linux and Windows. The test systems all  have plain 7200 RPM ATA/SATA harddisks and no more than 4 GB of memory (some have 2 GB only). So Monyog does not require a lot of CPU cores to run smoothly. But as it is heavily multithreaded  it will use multiple cores efficiently if running on a recent OS that does.

* Memory: The only component of MONyog that may use considerable memory is SQLite due to its caching mechanism. The way we have linked the SQLite library in our code restricts the SQLite cache not to grow beyond 2 GB. Of course the MONyog built-in HTTP daemon etc. will also use a little memory, and also the OS will, but you will in most scenarios not harvest any significant performance gain on a dedicated MONyog machine adding more memory than 4 GB. If you want to be on the safe side to avoid swapping and want to analyze very large (slow or general) query log files in particular you could consider 8 GB memory for your dedicated MONyog machine.

* CPU: With MONyog running on this ‘commodity machine’  with 200 servers registered you should expect an average CPU load just around 10-20% with a (for monitoring) reasonable sample interval (minutes, not seconds) as long as MONyog just collects data and a single client (browser) is connected watching the MONyog Dashboard page, Processlist page or the Monitors/Advisors page. It also depends on how much you use SSH-tunnel to your MySQL servers and if the ‘query sniffer’ is running for the MySQL servers monitored or not. However the user may send some specific requests to MONyog that will require extensive calculations. For instance (slow or general) log analysis with large log chunks does and  history/trend analysis with GROUP BY option does if you have selected a large time interval for analysis. If some user requests such, MONyog will use as much free CPU as the OS allows a single process to do until the calculation has been completed -  and then obviously the more powerful the CPU is, the faster the calculation will be performed and the sooner the user will see the result. However for normal use a ‘state-of-the-art’ consumer dual- or quad-core 2-3 Ghz CPU is fully sufficient.

* Storage systems: Don’t think about SAN, expensive external RAID racks of whatever of the kind. But ‘a little faster than normal disk system’  (like a 10K RPM disk, some small RAID system etc.) could be used with advantage – in particular if you monitor your servers with a short collection interval (say less than 15 seconds) where I/O could be the first ‘bottleneck’ encountered.  Also we have not done any specific optimizations for solid-state disk systems in MONyog simply because we consider it un-necessarily expensive ‘overkill’ to use such with MONyog. However a major part of what I/O operations MONyog does is handled by the SQLite library and SQLite is used extensively on systems with solid-state storage and handles it very well – so if you want you can use it.

Download the MONyog whitepaper: http://www.webyog.com/en/whitepapers/MONyogWhitePaper.pdf
Read the MONyog documentation online: http://www.webyog.com/doc/index.php
Download MONyog TRIAL: http://webyog.com/en/downloads.php
Purchase MONyog: http://webyog.com/en/buy.php

Comments(3)

I wanted to download MySQL Proxy 0.72 (the latest stable to my best knowledge) but I found ..

1) This page: http://www.mysql.com/downloads/ does not list MySQL proxy at all.

2) Anyway all versions up to 0.81 are available from FTP mirrors (like ftp://ftp.easynet.be/mysql/Downloads/MySQL-Proxy/) so I was able to get my hands on it.

Accidentially I found shortly after that ..

3) This page: http://dev.mysql.com/downloads/ (only) has 0.81 ALPHA listed.

4) Here http://bugs.mysql.com/bug.php?id=61474 MySQL supporter references a version 0.9 that is nowhere referenced on mysql.com nor dev.mysql.com but seems available from Launchpad.

I don’t understand why stable versions are not available from mysql.com any more.  I think I know/understand  that there were some securtity concerns with pre-0.8x (but they do not affect me with my environment so I am happy with 0.72). In any case I find it very confusing that a GA/stable version is withdrawn once published without even a note about why it happened.  I cannot know of course if this is a deliberate choice or maybe just a mistake by the MySQL web team. But as said: I find it very confusing that a GA version suddenly is not available where it used to be. If it has so serious issues that they/Oracle do not want to distribute it, then http://www.mysql.com/downloads/ should have a note about why it was removed and tell about 0.81/0.9 version(s) download options (from dev …).

I tried to ask about this in the above-mentioned bug report. The supporter here was not in a position to reply (what I understand and accept – and I probably should not have asked there).  But the problem is that I don’t know where else I could ask.

Please tell: was the removal of 0.72 from http://www.mysql.com/downloads/ a deliberate choice (and if so, why?) or a simple mistake (if so, please fix it!). And if there is a 0.9 (development) version that can be considered good enough for ordinary users posting a bug report to test with, then why is it then not available on http://dev.mysql.com ?

Comments(5)