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(2)
