PlanetMysql.ru — информация о СУБД MySQL

What does FLUSH STATUS do? We all know that it will simply reset all status variables (except for ‘uptime’) to same values as immediately after a server restart. Just google it and you will find that behaviour statet on hundreds of sites on the Internet.

But NO – it is not true! Not anymore. MySQL documentation:
http://dev.mysql.com/doc/refman/5.5/en/flush.html

“This option adds the current thread’s session status variable values to the global values and resets the session values to zero. It also resets the counters for key caches (default and named) to zero and sets Max_used_connections to the current number of open connections.”

This bug report http://bugs.mysql.com/bug.php?id=22875 has some background. Before introduction of seperate SESSION and GLOBAL status variables, FLUSH STATUS really did reset (almost) all status variables to same values as immediately after a server restart.  Now it affects SESSION status variables (but why is SUPER privilege required for this?) and a few GLOBAL status variables only.

From the bug report I think that the change of behavior was not really planned and specified properly in advance but came as some kind of surprise – also to some people in the MySQL developer team. I agree with Konstantin Osipov’s (one of those MySQL developers that seemed surprised) comment in the bug report:

“As this behaviour got broken in 4.1, I personally consider it a regression and believe that it should be fixed as a regression. In order to fix it in line with the design of SHOW [SESSION/GLOBAL] STATUS we should implement FLUSH GLOBAL STATUS.FLUSH STATUS behaviour should be modified to not change any global data,  such as:
- key cache counters
- connection counters
- SHOW_LONG global variables.In other words, FLUSH STATUS should behave as FLUSH SESSION STATUS and only reset session-scope status variables. [SESSION] keyword should be added to the grammar and as optional.Key cache counters, connection counters, SHOW_LONG variables and server-scope status variable (those that have session counterparts) should be reset by FLUSH GLOBAL STATUS. FLUSH SESSION STATUS should no longer require SUPER privilege (connection privilege is enough, and as long as it is checked at connection, no privilege check is necessary).FLUSH GLOBAL STATUS should require SUPER privelege.”

But what happened was that the new behaviour was simply documented and since the problem/the report has been abandoned. It is now 5 years ago. Nothing happened since. The bug report is still open with the status of ‘verified’.

The reason why I am writing this is that I just replied to a concern to a MONyog user on whether MONyog could be fooled by this when calculating counters in the “ALL TIME” timeframe. The answer is that it cannot provided the actual server has implemented the GLOBAL status variable ‘uptime_since_flush_status’. All recent servers have (only very early 5.0 and 5.1 servers (5.0.35-,  5.1.24-) that nobody should use today have not). MONyog will simply discard all collected information older than ‘uptime_since_flush_status’ even if it has not yet been purged from the MONyog embedded database.

But still: Can we soon have that SESSION|GLOBAL switch for FLUSH STATUS, please? What we have now is a mismatch both as regards the semantics and the privileges requried. And 5 years of ‘stand-still’ for a ‘verified’ bug report related to server core features is too much (even though it is probably not the only one).

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 UDPATEs again automatically at startup. I do not favour of introducing of 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’). On Unix-type platforms you may modify the server startup script adding a call to Perl/Python/whatever script performing the updates on the P_S tables.

2) Multi-user 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?

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 “Testserver” WARNING is set at 84% and CRITICAL at 90% and for “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

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

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

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

Hi,

We are delighted to announce the release of MONyog 4.5. Listed below are some noteworthy features:

• You did get to know about what needs attention in Monitors/Advisors, but how about looking at all the alerts that need attention grouped on their severity for a certain period? This is what event is all about. An event occurs when the status of a counter changes. Keep your events tab open & you see MONyog alerting you – may it be “server availability” or “replication failure” or many other umpteen things that need attention.
• Many a times, MONyog shows an alert to bring your attention, but you are OK with that & don’t want to fix it. Just close the event & it will appear only when it becomes alert-able again. This is a nice way to accept & dismiss events, so that you can start with a clean slate with a baseline for normal acitivity for that instance.
  
• This one is a real time saver. You register a master & MONyog automatically registers all its slaves. If there are recursive slaves, well yes, they are auto-registered too. This feature is smart to indent slaves according to the hierarchy in the list of servers page. Note that MONyog assumes MySQL (port, username & password) and the SSH details of the slaves are same as that of its master. Once registered, you can edit connection details of slaves if it is different from master & get them monitored by MONyog.
• Long locked queries can cause havoc. With this release you can get alerted whenever a query results in longer locks. You can also ask MONyog to kill long locked queries as and when it happens. These options are present in process-list based sniffer.
• Groups of counters in Monitors/Advisors can now be enabled or disabled for a specific server. Before this release enabling/disabling affected all servers that are being monitored.

This release also contains many more enhancements & bug fixes. Refer the following release notes for details:

• MONyog 4.5 RC Release Notes
• MONyog 4.5 Beta2 Release Notes
• MONyog 4.5 Beta1 Release Notes

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 that you will like it. We would love to hear from you.

Cheers,
Team MONyog

The highlights of this release are:

* A brand new helper function interface: We have implemented an easy-form based interface for customizing helper functions. Any customization of helper functions or user defined functions being used with earlier versions have to be migrated manually to this version. From this version and onwards a GUI-’conflict resolver’ will guide the users very similar to how it works for customized counters.

* Apply settings to all servers of a specific tag: MONyog now has an option to apply a group of settings to all the servers with a specific tag. (Please note: New servers registered later with the same tag are not considered)

* Enhanced readability of MONyog logs: MONyog logs from now on contain the server name along with error making it easy to backtrack.

* Earlier multiple alerts for same issue would be sent if the counter was alertable for more than the specified number of data collections. Now we record what alerts have already been sent and will only send once. Settings in register server page has been updated accordingly.

Minor features & fixes:

* Automatic cleaning of size zero dump files: We have automated deleting dump files of size zero (that could be left behind if MONyog was terminated abruptly).

* Added an option to change the refresh interval from the processlist page.

* Processlist-based sniffer will no longer show the query ‘SHOW FULL PROCESSLIST’ executed by MONyog (Note: This only applies to the processlist-based sniffer and not to the processlist page where user has configurable filtering options).

* Fixed a (SQLite) database lock resulting in failure to update Dashboards and Monitors/Advisors pages.

* When SFTP option was chosen to analyze ‘MySQL general query log’ and SSH was disabled, MONyog still used SFTP to analyze the logs with out throwing any error.

* Small GUI enhancement/improvements.

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

Hi,

We are delighted to unveil MONyog 4.0 — a major new release. Listed below are overviews of some of the major features.

Tracking changes to your MySQL configuration

Maintaining server configuration and tracking changes to it plays a vital role in the maintenance of MySQL servers. DBAs may be responsible for hundreds of servers and keeping an eye on the configuration settings for all of them could be difficult to say the least. With MONyog 4.0 now you can compare global MySQL configuration of multiple servers side-by-side, with all changes highlighted so that differences are visually discernible at a glance. Wondering why server A isn’t performing as well as server B when they share the exact same load? The answer could lie in the configuration files!

What’s more is that MONyog now lets you track changes to the global configuration of your MySQL server no matter if the configuration parameters were specified in my.ini/my.cnf, are server defaults or if somebody with SUPER privilege has executed a SET GLOBAL statement.

Improved customization framework

Many MONyog users have long since complained that the customization feature was complex and hard to use: One had to be well-versed in object-oriented JavaScript concepts to even make a minor change. Moreover, unless you manually backed up your customizations, you’d loose all of them if you decided to upgrade! That was motivation enough for us to redesign the entire framework.

With MONyog 4.0 knowledge of writing basic JavaScript functions is more than sufficient to customize any Monitor/Advisor or roll out your very own set. A simple form-based interface with verbose instructions makes it very easy to define a new Monitor/Advisor.

We understand that not every user will make use of the 220+ Monitors/Advisors that we ship with MONyog. So why waste all the computing power? You can now disable a subset of the Monitors/Advisors and keep only the ones you use. If you change your mind later, you can always re-enable them again.

MONyog 4.0 provides a unique customization interface. Now you won’t have to worry about loosing your changes, making mistakes (you can always revert to the original!), or feel scared to experiment.

Improved stability and lots of minor features and bug fixes

As always, this release too contains a lot of bug fixes. MONyog has undergone severe stress testing and is monitoring 200 without issues in our test environment now. From this release we have reduced the number of Linux binaries. In version 3.72 we introduced packages specific to glibc versions. It was necessary at that time to ensure stability on both older Linux distros (RHEL3-generation) as well as the most recent distros using glibc version 2.5. But we never liked it ourselves. It could confuse users – and sometimes did. Since then we have been researching and testing different packaging concepts so that a single binary will do the job on all distros.  This release contains a single 32 and a single 64 binary – each with the option of a .tar.gz archive and a RPM installer.

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

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

Regards,

Team MONyog

Important note: Please note that if you have installed a MONyog 4.0 (beta) release you cannot install this one unless first completely removing the 4.0 installation including the complete MONyog data folder.

Changes (as compared to 3.77) include:

Bug Fixes:
* Monitors/Advisors on InnoDB Deadlocks were truncating the output message and hence in some cases, users were unable to view both queries involved in the deadlock. This has been changed such that the first 2048 characters of both queries are displayed.
* On Windows 7 systems changes to MONyog’s .INI file from external programs had no effect upon restart (as Windows reverted the changes). Now throughout MONyog’s lifetime the .INI file will be locked so that a user may only edit the file manually when MONyog is not running (but users can use the MONyog interface to change any setting while MONyog is running). Any changes made to the file when MONyog is not running will be reflected by it once it is restarted.
* If MySQL Error Log monitoring was enabled for a particular server, the first two data collections for that server would cause large network traffic to occur if the MySQL error log was very large. This was because the entire log file was read in the first collection. Now only the last 1MB of the file is read.

Miscellaneous:
* All libraries have been upgraded to their latest versions. Although, from a user-perspective, the changes are minimal, this has alleviated several memory leaks and other performance issues.
* This release has been checked in depth with with the best leak-detection tools available for both Linux and Windows.  All discovered leaks have been fixed.
* The cache parameters for the SQLite library have been modified with this release to allow for registering more servers on the same system as before. Before MONyog’s memory usage used to grow continually with time as each open SQLite handle has an associated cache which could grow to any size, irrespective of system capacity. The cache size per handle has been reduced and the total SQLite cache size will never exceed 1 GB with this build.

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