Proportion of MySQL variables

Question

I made some research on MySQL performance.
After doing some tests and verifyed the improvement, (thank you guys)
I end up asking myself:
"Is there any formula or metric between groups of variables?"

I mean, given a server with X GB of RAM and X2 processor

innodb_additional_mem_pool_size + innodb_buffer_pool_size <= Y% of X

innodb_log_file_size + innodb_log_buffer_size <= Z% of X

and so on...

Is there any specific proportion between this group of variables?

Answer 1

From the 5.6.3 Changelog:

The following items are deprecated and will be removed in a future MySQL release. Where alternatives are shown, applications should be updated to use them.

The innodb_table_monitor table. Similar information can be obtained from InnoDB INFORMATION_SCHEMA tables. See INFORMATION_SCHEMA Tables for InnoDB.

The innodb_locks_unsafe_for_binlog system variable.

The innodb_stats_sample_pages system variable. Use innodb_stats_transient_sample_pages instead.

The innodb_use_sys_malloc and the innodb_additional_mem_pool_size system variables.

Some of those were removed in 5.7.4.

The most important formula: For a InnoDB-only system, innodb_buffer_pool_size should be 70% of available RAM. A few more in Memory.

If you have not built your system yet, make that one setting and stop worrying until you have some real activity.

For most systems, query_cache_type = 0 and query_cache_size = 0.

innodb_log_file_size is best judged by how often you go through the log, not as some percentage of something else. Perhaps once an hour is good, but that is a very loose metric.

But, in general, the defaults are pretty good.

If you would like me to run an analysis of about 200 formulas on your existing system, provide me with SHOW VARIABLES and SHOW GLOBAL STATUS, plus how much RAM you have. Since some things are changing from version to version, what version are you using?

**Edit #2 -- more thorough analysis, since the up time was 5+ hours: Note: Most of the following is automated output, but I have reviewed it and made changes to it.

Version: 5.6.11-log 4 GB of RAM Uptime = 05:37:42; some GLOBAL STATUS values may not be meaningful yet. (maybe good enough) Are you sure this was a SHOW GLOBAL STATUS ? You are running on Windows. You appear to be running entirely (or mostly) InnoDB. The More Important Issues:

( innodb_buffer_pool_size / _ram ) = 1024M / 4096M = 25.0% -- % of RAM used for InnoDB buffer_pool -- For 4GB RAM, use about 1500M for innodb_buffer_pool_size.

( table_open_cache ) = 4,000 -- Number of table descriptors to cache ( Open_tables / table_open_cache ) = 102 / 4000 = 2.5% -- Cache usage (open tables + tmp tables) -- Suggest table_open_cache = 150 (This will conserve some RAM)

( Innodb_buffer_pool_pages_free * 16384 / innodb_buffer_pool_size ) = 66,195 * 16384 / 1024M = 101.0% -- buffer pool free -- buffer_pool_size is bigger than working set; could decrease it ( Innodb_pages_written / Innodb_buffer_pool_write_requests ) = 1 / 1 = 100.0% -- Write requests that had to hit disk -- Check innodb_buffer_pool_size -- It's as if you have not touched the data??? For SHOW GLOBAL STATUS to be useful, I need some activity.

( innodb_log_buffer_size ) = 256M -- Suggest 2MB-64MB, and at least as big as biggest blob set in transactions. -- Adjust innodb_log_buffer_size. (wasting RAM)

( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 20,262 / 60 * 256M / 512 = 1.77e+8 -- Minutes between InnoDB log rotations Beginning with 5.6.8, this can be changed dynamically; be sure to also change my.cnf. -- (The recommendation of 60 minutes between rotations is somewhat arbitrary.) Adjust innodb_log_file_size.

( innodb_additional_mem_pool_size ) = 64M -- (deprecated in 5.6.3, removed in 5.7.4.)

( max_heap_table_size / _ram ) = 62M / 4096M = 1.5% -- Percent of RAM to allocate when needing MEMORY table (per table), or temp table inside a SELECT (per temp table per some SELECTs). Too high may lead to swapping. -- Decrease max_heap_table_size to, say, 1% of ram.

( read_buffer_size / max_allowed_packet ) = 2M / 1M = 2 -- read_buffer_size > max_allowed_packet could cause LOAD DATA INFILE to fail (pre-5.1.24)

( (Com_show_create_table + Com_show_fields) / Questions ) = (25 + 25) / 1552 = 3.2% -- Naughty framework -- spending a lot of effort rediscovering the schema. -- Complain to the 3rd party vendor.

( local_infile ) = ON -- local_infile = ON is a potential security issue

( tmp_table_size ) = 256M -- Limit on size of temp tables used to support a SELECT -- Decrease tmp_table_size to avoid running out of RAM. Perhaps no more than 64M. A large tmp_table_size is not as useful as allocating more buffer_pool space.

( sort_buffer_size ) = 2M -- One per thread, malloced at full size until 5.6.4, so keep low; after that bigger is ok. -- This may be eating into available RAM; recommend no more than 2M.

( Slow_queries / Questions ) = 64 / 1552 = 4.1% -- Frequency (% of all queries) ( Select_scan / Com_select ) = 649 / 429 = 151.3% -- % of selects doing full table scan. (May be fooled by Stored Routines.) -- Add indexes / optimize queries ( long_query_time ) = 10.000000 = 10 -- Cutoff (Seconds) for defining a "slow" query. -- Suggest turn on the slowlog, set this to 2, then look at the slowlog, preferably with pt-query-digest.

Max_used_connections / max_connections = 4/151 = 2.6% -- Consider decreasing max_connections.

thread_cache_size = 20 -- For Windows, 0 is fine.

Questions / Uptime = Queries / Uptime = 0.077 per second -- This is so low that I wonder why you are asking about tuning. Even a terribly mis-tuned mysql will perform on with only a few queries per minute.

Bottom line... Tuning is not an issue (though I recommended a few changes). However, there are several queries that probably could be improved with indexes, modifications to the queries, etc.

Answer 2

There is one serious effort to do this - it can be found here. Check out the warning though

WARNING

It is extremely important for you to fully understand each change you make to a MySQL database server.... &c...

It is virtually impossible to factor in all variables - at the end of the day, it comes down to MySQL expertise. The author (Major Hayden) is a principal architect with RackSpace, so one can assume that he has some expertise.