I have recently started seeing high amount of set-option query count in mysql. Its around 15k/sec
mysql> SHOW GLOBAL STATUS LIKE '%set%';
+-------------------+------------+
| Variable_name | Value |
+-------------------+------------+
| Com_reset | 0 |
| Com_set_option | 5472249432 |
| Com_show_charsets | 31 |
| Com_stmt_reset | 0 |
+-------------------+------------+
4 rows in set (0.00 sec)
However nothing like "set" operation is seen in the "show processlist"
IMAGE
Any idea why?
Thanks
COM_SET_OPTION count is high probably because the MySQL library you are using issues a SET option command every time it creates a connection to the MySql server. Few libraries tend to set some basic options everytime they create a new connection.
This could also happen if your system does a lot of transactions with MySQL.
However, this is pretty normal. I am using MySql 5.6.34 with PHP. Refer
Related
I am going to upgrade my RDS for a much bigger instance type (r3.large to r3.2xlarge) and I would like to know if AWS will adjust the mysql parameters accordantly.. what are the may concerns should I have on this procedure? Is fining customization lost when it exist?
instance cpu Memory PIOPS-Optimized Network Performance
Price
db.r3.large 2 15 No Moderate $0.32
db.r3.2xlarge 8 61 Yes High $1.28
My main concern is regarding the caching configuration.
innodb_buffer_pool_size is currently 7GB and I thinking about leaving it as 50GB after upgrade. will this be adjusted automatically?
Just to complement the question, I am upgrading due to lack of memory as showed on this:
mysql> show status like '%qcache%';
+-------------------------+----------+
| Variable_name | Value |
+-------------------------+----------+
| Qcache_free_blocks | 134 |
| Qcache_free_memory | 148080 |
| Qcache_hits | 42459186 |
| Qcache_inserts | 14059268 |
| Qcache_lowmem_prunes | 2455035 |
| Qcache_not_cached | 22422639 |
| Qcache_queries_in_cache | 241632 |
| Qcache_total_blocks | 772112 |
+-------------------------+----------+
8 rows in set (0.01 sec)
As it state mysql cannot cache some stuff and has loads of prunes.
The value of parameter innodb_buffer_pool_size, by default, is assigned using the formula {DBInstanceClassMemory*3/4}. So if you change the db instance class(upgrade or downgrade), then the value is changed accordingly. This is valid as long as you have not changed the value manually and set it to a numeric value(without using the formula).
In your case,If you are upgrading the instance class to a higher class and If you have updated the value of the parameter(without using the formula), then the same is preserved after the db instance class is upgraded.
This is the query that I have written:
SELECT variable_name,0 - variable_value
FROM information_schema.global_status
WHERE variable_name IN ('Innodb_rows_inserted','Innodb_rows_updated'
,'Innodb_rows_deleted','Innodb_rows_read'
,'Innodb_data_reads','Innodb_data_read'
, 'Innodb_data_writes','Innodb_data_written');
+----------------------+--------------------+
| variable_name | 0 - variable_value |
+----------------------+--------------------+
| INNODB_DATA_READ | -6672384 |
| INNODB_DATA_READS | -422 |
| INNODB_DATA_WRITES | -22 |
| INNODB_DATA_WRITTEN | -333312 |
| INNODB_ROWS_DELETED | 0 |
| INNODB_ROWS_INSERTED | -2 |
| INNODB_ROWS_READ | -17 |
| INNODB_ROWS_UPDATED | 0 |
+----------------------+--------------------+
8 rows in set (0.00 sec)
Now, I want the difference between the most recently updated value for INNODB_ROWS_INSERTED and its last value.
For example - In the above output, value of INNODb_ROWS_INSERTED is 2. If I make one more insert and re run this query, the updated value will be 3. Now I want to display the difference, i.e. 1 in a new table or a file.
Thanks
Beware of the Observer effect.
Plan A: Put the original values in a temp table, but make sure it is not an InnoDB table. After the test, JOIN the information_schema query to it to get the diffs.
Plan B: Use SHOW GLOBAL STATUS LIKE 'Innodb%' before and after; parse the ouput (in, say, PHP); take the diffs. It seems that SHOW is less likely to be subject to the Observer effect. But the coding is more clumsy.
Plan C (won't work for those STATUS values): FLUSH STATUS zeros out some STATUS values. Do that before the test, then use SHOW SESSION STATUS LIKE '...' afterwards. (Note use of SESSION.) This works well for LIKE 'Handler%', which I find useful in digging into how queries work and how fast or slow they are.
With administrative permissions im mysql, how can I see all the open connections to a specific db in my server?
The command is
SHOW PROCESSLIST
Unfortunately, it has no narrowing parameters. If you need them you can do it from the command line:
mysqladmin processlist | grep database-name
As well you can use:
mysql> show status like '%onn%';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| Aborted_connects | 0 |
| Connections | 303 |
| Max_used_connections | 127 |
| Ssl_client_connects | 0 |
| Ssl_connect_renegotiates | 0 |
| Ssl_finished_connects | 0 |
| Threads_connected | 127 |
+--------------------------+-------+
7 rows in set (0.01 sec)
Feel free to use
Mysql-server-status-variables or Too-many-connections-problem
That should do the trick for the newest MySQL versions:
SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE DB like "%DBName%";
You can invoke MySQL show status command
show status like 'Conn%';
For more info read Show open database connections
SQL:
show full processlist;
This is what the MySQL Workbench does.
In MySql,the following query shall show the total number of open connections:
show status like 'Threads_connected';
If you're running a *nix system, also consider mytop.
To limit the results to one database, press "d" when it's running then type in the database name.
From the monitoring context here is how you can easily view the connections to all databases sorted by database. With that data easily monitor.
SELECT DB,USER,HOST,STATE FROM INFORMATION_SCHEMA.PROCESSLIST ORDER BY DB DESC;
+------+-------+---------------------+-----------+
| DB | USER | HOST | STATE |
+------+-------+---------------------+-----------+
| web | tommy | 201.29.120.10:41146 | executing |
+------+-------+---------------------+-----------+
If we encounter any hosts hots max connections and then not able to connect, then we can reset host tables by flushing it and is as follows:
FLUSH HOSTS;
In query browser right click on database and select processlist
I have a database table, with 300,000 rows and 113.7 MB in size. I have my database running on Ubuntu 13.10 with 8 Cores and 8GB of RAM. As things are now, the MySQL server uses up an average of 750% CPU. and 6.5 %MEM (results obtained by running top in the CLI). Also to note, it runs on the same server as Apache2 Web Server.
Here's what I get on the Mem line:
Mem: 8141292k total, 6938244k used, 1203048k free, 211396k buffers
When I run: show processlist; I get something like this in return:
2098812 | admin | localhost | phpb | Query | 12 | Sending data | SELECT * FROM items WHERE thumb = 'Halloween 2013 Horns/thumbs/Halloween 2013 Horns (Original).png'
2098813 | admin | localhost | phpb | Query | 12 | Sending data | SELECT * FROM items WHERE thumb = 'Halloween 2013 Witch Hat/thumbs/Halloween 2013 Witch Hat (Origina
2098814 | admin | localhost | phpb | Query | 12 | Sending data | SELECT * FROM items WHERE thumb = 'Halloween 2013 Blouse/thumbs/Halloween 2013 Blouse (Original).png
2098818 | admin | localhost | phpb | Query | 11 | Sending data | SELECT * FROM items WHERE parent = 210162 OR auto = 210162
Some queries are taking an excess of 10 seconds to execute, this is not the top of the list, but somewhere in the middle just to give kind of a perspective of how many queries are stacking up in this list. I feel that it may have something to do with my Query Cash configurations. Here are the configurations show from running the SHOW STATUS LIKE 'Qc%';
+-------------------------+----------+
| Variable_name | Value |
+-------------------------+----------+
| Qcache_free_blocks | 434 |
| Qcache_free_memory | 2037880 |
| Qcache_hits | 62580686 |
| Qcache_inserts | 10865474 |
| Qcache_lowmem_prunes | 4157011 |
| Qcache_not_cached | 3140518 |
| Qcache_queries_in_cache | 1260 |
| Qcache_total_blocks | 4440 |
+-------------------------+----------+
I noticed that the Qcache_lowmem_prunes seem a bit high, is this normal?
I've been searching around StackOverflow, but I couldn't find anything that would solve my problem. Any help with this would be greatly appreciated, thank you!
This is probably one for http://dba.stackexchange.com. That said...
Why are your queries running slow? Do they return a large result set, or are they just really complex?
Have you tried running one of these queries using EXPLAIN SELECT column FROM ...?
Are you using indexes correctly?
How have you configured MySQL in your my.cnf file?
What table types are you using?
Are you getting any errors?
Edit: Okay, looking at your query examples. What data type is items.thumb? Varchar, Text? Is it not at all possible to query this table using another method than literal text matching? (e.g. ID number). Does this column have an index?
I'm the owner of a web-game with a high-traffic database with a lot of queries.
I'm now optimizing the mySQL and tools like mysqltuner keep saying that I have insufficient query cache memory.
+-------------------------+-----------+
| Variable_name | Value |
+-------------------------+-----------+
| Qcache_free_blocks | 218 |
| Qcache_free_memory | 109155712 |
| Qcache_hits | 60955602 |
| Qcache_inserts | 38923475 |
| Qcache_lowmem_prunes | 100051 |
| Qcache_not_cached | 10858099 |
| Qcache_queries_in_cache | 19384 |
| Qcache_total_blocks | 39134 |
+-------------------------+-----------+
That's from about 1,5 day of running the server.
Ideally the lowmem_prunes would be 0 of course, but there are very much queries which are user-based. Like,
SELECT username FROM users WHERE id='1';
SELECT username FROM users WHERE id='12';
SELECT username FROM users WHERE id='12453';
SELECT username FROM users WHERE id='122348';
As I have about 3000 different users a day logging in you will have many queries like this in the memory.
I know about the ON DEMAND rule, but I'm avoiding it because we have a lot of queries which I don't want to check all over.
Increasing the memory wouldn't be a fix either since we're having so many queries.
Then I came up with the idea to make a cronjob to automatically RESET the query cache when the lowmem_prunes is zero. (which will probably be once an hour)
What's the best option?
1. Automatically reset the query cache once an hour
2. Buy more RAM and increase the cache with 1GB for example (which has it's downsides... I rather not do that)
3. Specify per query which should be kept in cache in which not.
4. Just keep it like this.