I'm trying to optimise the Digital Ocean droplet that my Laravel web app is running on, and have noticed that MySQL is constantly using ~50% of its 1GB RAM. By far the most common and well-attested method for decreasing MySQL's memory footprint is to disable its Performance Schema feature by setting performance_schema = 0 in /etc/mysql/my.cnf.
However, no answer I've seen yet makes any mention of what exactly this feature does, why it's enabled by default, and the implications of disabling it. To me it seems too be good to be true, and while I'm all for optimisation, I also don't want to compromise the integrity of my web app's server.
The performance_schema is for monitoring and instrumenting the MySQL Server. Many types of monitoring tools may depend on it. I won't describe the specific events it monitors, because that's in the manual.
You can run MySQL Server without the performance_schema enabled, but monitoring will be compromised. If you disable monitoring, you will not be able to diagnose performance problems or resource usage.
The IT industry is becoming increasingly aware that monitoring is an important feature of servers and infrastructure. I don't think it's a good tradeoff to disable the performance_schema in MySQL Server to gain a mere 512MB of memory. If you are that constrained on memory, then you should reconsider if MySQL Server is the right technology choice for your platform.
Related
We have a 2GB Digital Ocean server, and it is dedicated for a MySQL server of other two PHP servers. we are using Percona MySQL Server 5.6 on this server. We configured MySQL replication and these configuration is working fine
Our issue is sometime our site monitoring tools reporting that some of the URL hosted with this server is down (May be this is happening once in a week or two). When I am checking, I could see that Mysql Master server load is too much high (May be 35 - 40), so the MySQL server was not responded. # that I usually do a MySQl service restart, this restart cause to server load become normal and the sites started working after service restart.
This is a back-end MySQL database server of 20-25 PHP applications (WordPress, Drupal and some custom applications server).
Here are my questions,
Why this server load automatically goes down, after a spikes happens?
Is there any way in which database is causing issues? So that I can identify the application too.
How can I identify the root cause of this issues
Depending upon your working dataset, a 2GB server providing access for 20-25 PHP applications (WordPress, Drupal and some custom applications server) could be the issue.
For example, if you have a 1.4GB buffer pool (assuming all tables are InnnoDB) and 10GB of data, then your various applications could end up competing for resources, such as I/O, buffer pool pages, Adaptive Hash Index, query cache. They could also, assuming caching is used, be invalidating theit caches within a similar timeframe, thus sending expensive queries to the database.
Whilst a load of 50 is something that you would normally want to avoid, the load average is not something that you should concern yourself with if showing in isolation.
The use of the uninterruptible state has since grown in the Linux
kernel, and nowadays includes uninterruptible lock primitives. If the
load average is a measure of demand in terms of running and waiting
threads (and not strictly threads wanting hardware resources), then
they are still working the way we want them to.
http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html
If the issue is happening once per week then it is starting to sound like a batch process, or cache expiration issue - too much happening at once for the resources available.
The best thing to do is to monitor and look for the cause. Since you are already using Percona Server, using PMM should give you the perfect insight to find the cause, although it works with Oracle MySQL, MariaDB, Aurora, etc. You can try a demo to see the insights that you can gain:
https://pmmdemo.percona.com. The software is Open Source and free to use.
You can look in QAN to find the most expensive queries, whilst looking at Prometheus data to give an insight into the host itself. There are some recommendations to get the most from PMM, depending upon your flavour of MySQL.
Is there a way to monitor MySQL I/O performance in XAMPP?
I am building an application that will interface with the MySQL database and for testing in XAMPP MySQL, I would like to be able to monitor I/O performance.
XAMPP does not have a performance monitoring tool built in for Mysql, since it is a web server and just comes packaged with Mysql when installed. There are a number of free and paid ways to monitor I/O performance for Mysql.
If you are on a linux server you can use iostat, htop, innotop, show innodb engine status and a number of other packages to monitor I/O performance yourself. Here is a Useful link.
Mysql Workbench is free and has a Dashboard where you can see performance.
Monyog is another great tool but is not free and requires some setup. However, the performance monitoring for a DBA is worth the effort, especially if you have dozens of sites.
Currently we have a website running on a Centos 6.5 webserver with Direct Admin. APC was configured in the past and is working nicely, but some reading suggested to also implement memcached to cache some static tables (like for instance menu's).
As of MySQL 5.6, the innoDB tables are compatible with a mysql memcache deamon, so I started off following this guide: http://dev.mysql.com/doc/refman/5.6/en/innodb-memcached-installing.html.
The config script is ran and the deamon is installed.
However the Drupal memcache plugin does not see memcache is running. That module is obviously checking for the php memcached deamon, while my deamon is already running in mysql.
Since both extensions are called memcached.so, we strongly have the feeling this is the same thing. Are there actually two different things and does Drupal not support the InnoDB memcached deamon, do I need both (php extension to access the mysql extension?), or was this supposed to be working and did we something wrong?
Update
The status report showed something like "not running", but one of my colleagues has installed the PHP PECL extension now and it seems to be working. But then I still don't understand what the MySQL innodb deamon plugin does. Is it not needed, or does it improve database access even more then the PHP extension would?
The Memcached interface to InnoDB is a feature of MySQL to support the memcached protocol, yet with InnoDB as the back-end storage. It seems like lot of people have been confused by what this means, so I'll try to explain.
Whereas a real memcached daemon stores data in memory, MySQL stores data persistently in an InnoDB table. PHP applications can read and write data using the memcached extension, as if they're using a standard memcached in-memory store. However, they are really reading and writing rows from the InnoDB table.
This is somewhat slower than standard memcached, because it has the overhead of writing to disk is greater than accessing memory. But it's somewhat faster than using SQL to read and write those rows, because it skips the complexity of the SQL parser and query optimizer.
That's really the new feature in MySQL: to bypass SQL, and give access directly to the InnoDB storage engine through a simple, but familiar interface. They chose memcached on the theory that many developers would be familiar with it and have tools and language support for it already.
The InnoDB memcached interface is similar to the earlier experimental plugin called HandlerSocket developed in 2010. http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html
Here's a Percona blog that shows tests of the relative speeds of InnoDB memcached versus SQL queries: http://www.percona.com/blog/2013/03/29/mysql-5-6-innodb-memcached-plugin-as-a-caching-layer/
Re your question in comments:
You might be misunderstanding. The data is never in Memcached. There is no automatic synchronization between MySQL and Memcached. The only thing is that MySQL is mimicking the API and protocol of Memcached. There's no reason that they did this, except to make the API familiar to developers.
When you use the "Memcached API for InnoDB" you're connecting your application to a port listened to by the mysqld daemon process. Your requests on this connections read and write rows directly in the InnoDB storage engine. There's no Memcached instance in between.
The InnoDB Memcached Plugin is a feature in MySQL >= 5.6 that runs a Memcached daemon in the existing mysqld process supporting the Memcached API listening on a different port (11211 by default). Because it runs in the same process space as InnoDB, you get low-latency access to data stored in InnoDB tables and through existing, widely-available Memcached clients.
This has a few interesting use-cases:
Transparent support for adding InnoDB as a high-performance persistence layer to existing memcached clients/applications
Improved performance over SQL queries for interacting with InnoDB tables directly (especially for inserting new key/value pairs), since the simple Memcached protocol bypasses the overhead of SQL parsing and query-plan optimization
High-performance 'MySQL + caching layer' architecture, where the memcached daemon fetches data from from the underlying InnoDB table and serves cached data directly from local memory
Case #3 is particularly noteworthy: Although the Memcached plugin is configured by default to read/write directly to the underlying InnoDB table (innodb_only cache policy), it can be configured to use its own, separate local memory cache just like a standalone Memcached instance would, either without using InnoDB storage at all (cache-only), or using InnoDB as a backing store (caching). (Note that the currently-accepted answer is incorrect on this point.)
Refer to the architecture diagram from the documentation (note the 'local cache (optional)' component, which is used by the cache-only or caching cache policies):
(source: mysql.com)
In terms of setup/installation, if you're using the Memcached plugin for anything other than a standalone key-value cache (case #1), you will need to create a mapping from Memcached keys/values to your InnoDB tables/columns by writing a row to the special innodb_memcache.containers table. See Creating a New Table and Column Mapping for details.
A bit of a side-track here, but nowadays you're better of using the memcache_storage module. The module page has plenty of good pointers how to use the module and with what other modules it integrates nicely to have a better and faster caching for your site.
I have a mysql server in linux platform. I need to do performance tuning in that mysql server which is innodb engine.I want know the manual configuration in my.cnf file. so, what are all the important innodb parameters to be configure ? Because innodb and myisam engines are having different tuning operations. please tell some useful things to do
I would recommend using MySQL Tuner
This is good starting point for MySQL performance tuning.
You should also be running some kind of monitoring software that is able to graph
you MySQL health. This is vastly helpful when the performance trouble comes in.
I would recommend you munin with the MySQL plugins.
Regards -- Luke
I have very limited resources (RAM) on my server (Debian lenny) and I need to install mySQL server, it will not be extensively used. I installed apt-get install mysql-server before but it was taking about 150MB of RAM and I am looking for alternative servers, are there any, I couldn't find anything.
Thank you in advance!
It can certainly be tuned to use less ram than the default. In particular, Debian may ship it with a configuration which is more suitable for a typical server-grade machine.
If you feel the need to run MySQL on a very memory-constrained platform, consider tuning its memory usage as described here: How MySQL Uses Memory
You probably want to use InnoDB; the most important thing to tune is to make your innodb_buffer_pool a sensible size (There are other InnoDB buffers you may want to tune too; read its documentation).
If you aren't using MyISAM, reduce its key_buffer_size to a small value (say 4M). MyISAM can't be disabled as it's used internally.
If you aren't using InnoDB, turn it off entirely.