-1

I have a website that receives a lot of searches, so I need a cache.

The VPS is under the plesk license and the OS is Centos.

I have used the following command to implement a cache in mysql several days ago:

SET GLOBAL query_cache_size = 16777216;

The problem is that after some days the query_cache_size is reset automatically:

mysql> SHOW VARIABLES LIKE 'query_cache_size';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| query_cache_size | 0     |
+------------------+-------+
1 row in set (0.00 sec)

This is the file /etc/my.cnf:

[mysqld]
bind-address = 127.0.0.1
local-infile = 0
datadir = /var/lib/mysql
socket = /var/lib/mysql/mysql.sock
user = mysql

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

query_cache_size = 16777216
query_cache_type = 1
query_cache_limit = 1048576

How can I fix this problem?

Rick James
  • 78,038
  • 5
  • 47
  • 113
Daniele
  • 9
  • 6
  • Is any form of replication (especially Galera) involved? Is it your VPS or some Cloud service? What MySQL version? – Rick James Aug 23 '18 at 23:53

3 Answers3

0

In general the query_cache is not very useful. Amongst it's problems are global mutex, eviction of cached results occurs when you update a table (all the cached results for said table, ALL of them).

I would look at investigating what is going on with that instance. It might be that the provider manages it with some config management tool (Chef, Puppet, Saltstack, Ansible) and the MySQL variables are being set to a value that the owner thinks will protect the memory use on the hypervisor.

If you have console access check the Linux processlist for signs of an agent running locally that could point to Chef or Puppet. Depending on your level of experience and the amount of control you have on your machine, it could be useful to set up some audit logging to check who/what is connecting to your instance and altering the config.

https://mariadb.com/kb/en/library/mariadb-audit-plugin-installation/ https://github.com/mcafee/mysql-audit/wiki/Installation

You might be able to brute force it's state by using the event scheduler inside mysql (select your preferred interval).

USE mysql;
CREATE EVENT set_query_cache
ON SCHEDULE EVERY 5 SECOND
ON COMPLETION PRESERVE
DO
   SET GLOBAL query_cache_size = 16777216;
eroomydna
  • 1,031
  • 5
  • 5
  • This is a great solution! I am the owner of the VPS and i have a full access to ssh with root privileges, i will open a ticket asking at the company if they are changing my configuration. – Daniele Aug 08 '18 at 22:54
0

The variable query_cache_size is again set to 0 despite there is the event in mysql every 5 seconds:

select EVENT_DEFINITION,INTERVAL_VALUE from events;
+----------------------------------------+----------------+
| EVENT_DEFINITION                       | INTERVAL_VALUE |
+----------------------------------------+----------------+
| SET GLOBAL query_cache_size = 16777216 | 5              |
+----------------------------------------+----------------+

SHOW VARIABLES LIKE 'query_cache_size';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| query_cache_size | 0     |
+------------------+-------+
Daniele
  • 9
  • 6
0

You never enabled the event scheduler.

You need to enable it and maybe recreate the event script.

STEP 01 : Edit my.cnf

Please edit these lines in my.cnf

[mysql]
event_scheduler=ON

STEP 02 : Enabled it manually

Login to mysql, and run the following:

mysql> SET GLOBAL event_scheduler=1;
mysql> SET GLOBAL query_cache_size=16777216;

STEP 03 : Logout and Login and Check

Logout of mysql

mysql> exit

Login to mysql

$ mysql -uroot -p

Check the variables

mysql> SHOW GLOBAL VARIABLES LIKE 'event_scheduler';
mysql> SHOW GLOBAL VARIABLES LIKE 'query_cache_size';

If these give you ON (or 1) and 16777216, you are done.

STEP 04 : Drop and recreate the event

Please do not add events to the mysql system database.

Create another database, make it start 10 seconds after event creation

USE mysql;
DROP EVENT IF EXISTS set_query_cache;
CREATE DATABASE mystuff;
USE mystuff
CREATE EVENT set_query_cache
ON SCHEDULE EVERY 5 SECOND
STARTS (NOW() + INTERVAL 10 SECOND)
ON COMPLETION PRESERVE
DO
    SET GLOBAL query_cache_size = 16777216;

GIVE IT A TRY !!!

RolandoMySQLDBA
  • 182,700
  • 33
  • 317
  • 520
  • I think the biggest problem here was that you never enabled the event scheduler. The extra info was just for completeness. – RolandoMySQLDBA Aug 10 '18 at 13:47
  • @daniele Do you realize, whatever is causing QC size to go to 0 is also discarding every QC result every time it gets executed, effectively you have No QC every few seconds. You might as well turn it OFF and forget it. In 8.0 it will not exist no matter how much you like the concept. – Wilson Hauck Aug 17 '18 at 19:11
  • 1
    @WilsonHauck I could not agree more. I wrote about the Query Cache's constant battle with InnoDB : https://dba.stackexchange.com/questions/66774/why-query-cache-type-is-disabled-by-default-start-from-mysql-5-6/66796#66796. If Daniele does his homework and knows what result sizes his queries are, he is OK with his current version of MySQL. Once he upgrades to 8.0, RIP Query Cache !!! – RolandoMySQLDBA Aug 17 '18 at 19:15
  • 2
    @RolondoMySQLDBA From my perspective, QC concept just hid the real need for writing efficient SQL that had predictable data access patterns. Likely many people still have not heard about the miracle of EXPLAIN (myquery) to find out how their server is being used for data access. – Wilson Hauck Aug 17 '18 at 19:20
  • I have studied hundreds of servers. Maybe 3% have a legitimate need for the QC. The rest either have it off, or are deluded into thinking it benefits them. – Rick James Aug 23 '18 at 23:57