| Variable_name | Value | +---+---+ | read_buffer_size | 131072 | +---+---+ 11.innodb_flush_log_at_trx_commit
Konfigurasi pada valui ini hanya opsional, apabila edit menjadi 0 (nol) bisa menjadi sedikit lebih cepat, namun kekurangannya adalah memungkinkan untuk kehilangan data yang sedang ditransaksikan apabila server crash.
SHOW VARIABLES WHERE Variable_name = 'innodb_flush_log_at_trx_commit' ; +---+---+
| Variable_name | Value | +---+---+ | innodb_flush_log_at_trx_commit | 1 | +---+---+
Optimasi MySQL dengan script
Cara lain yang cukup mudah untuk memastikan bahwa MySQL Server yang terinstall sudah dikonfigurasi dengan baik, yaitu dengan menggunakan script MySQL Tunning, beberapa contoh dari script tersebut adalah:
1. Tuning-primer: MySQL performance tuning primer script 2. MySQLTuner-perl
MySQLTuner-perl script ini dibuat dengan bahasa Perl dan akan melakukan pengecekan terhadap konfigurasi database MySQL yang kita miliki. Jangan lupa untuk membackup file konfigurasi yang ada sebelum menjalankannya.
Penggunaan MySQL Tunner Script
Download terlebih dahulu MySQL Tunner
Jalankan MySQL Tunner dengan menggunakan perintah berikut:
perl mysqltuner.pl
Contoh hasil outputnya:
>> MySQLTuner 1.4.0 - Major Hayden <[email protected]>
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/ >> Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login: root Please enter your MySQL administrative password:
[OK] Currently running supported MySQL version 5.5.41-MariaDB-log [OK] Operating on 64-bit architecture
--- Storage Engine Statistics ---
[--] Status: +ARCHIVE +Aria +BLACKHOLE +CSV +FEDERATED +InnoDB +MRG_MYISAM [--] Data in MyISAM tables: 3M (Tables: 9)
[--] Data in InnoDB tables: 6G (Tables: 694)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17) [--] Data in MEMORY tables: 620K (Tables: 34)
[!!] Total fragmented tables: 695
--- Security Recommendations ---
[OK] All database users have passwords assigned
--- Performance Metrics ---
[--] Up for: 9d 22h 17m 49s (116M q [136.299 qps], 1M conn, TX: 327B, RX: 65B) [--] Reads / Writes: 97% / 3%
[--] Total buffers: 6.4G global + 2.9M per thread (512 max threads) [OK] Maximum possible memory usage: 7.9G (51% of installed RAM) [OK] Slow queries: 2% (2M/116M)
[OK] Highest usage of available connections: 50% (259/512) [OK] Key buffer size / total MyISAM indexes: 256.0M/1.3M [OK] Key buffer hit rate: 96.8% (155K cached / 4K reads)
[OK] Query cache efficiency: 48.0% (100M cached / 208M selects) [!!] Query cache prunes per day: 579946
[OK] Sorts requiring temporary tables: 0% (88 temp sorts / 2M sorts)
[!!] Joins performed without indexes: 63229
[!!] Temporary tables created on disk: 31% (1M on disk / 4M total)
[OK] Thread cache hit rate: 99% (880 created / 1M connections)
[!!] Table cache hit rate: 2% (776 open / 29K opened)
[OK] Open file limit used: 0% (8/2K)
[OK] Table locks acquired immediately: 99% (42M immediate / 42M locks)
[!!] InnoDB buffer pool / data size: 6.0G/6.2G
[OK] InnoDB log waits: 0
--- Recommendations ---
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance Adjust your join queries to always utilize indexes
When making adjustments, make tmp_table_size/max_heap_table_size equal Reduce your SELECT DISTINCT queries without LIMIT clauses
Increase table_open_cache gradually to avoid file descriptor limits
Read this before increasing table_open_cache over 64: http://bit.ly/1mi7c4C Variables to adjust:
query_cache_size (> 128M)
join_buffer_size (> 256.0K, or always use indexes with joins) tmp_table_size (> 32M)
max_heap_table_size (> 32M) table_open_cache (> 800)
innodb_buffer_pool_size (>= 6G)
Pada bagian Variable to adjust kita sudah mendapatkan parameter mana saja yang dapat digunakan untuk memaksimalkan kinerja MySQL.
Penggunaan MySQL Tunning Primer Script
Download terlebih dahulu script tunning-primer
wget https://launchpadlibrarian.net/78745738/tuning-primer.sh
Jalankan dengan menggunakan perintah:
./tuning-primer.sh
Berikut hasil pada saat menjalankan script tersebut
Using login values from ~/.my.cnf - INITIAL LOGIN ATTEMPT FAILED - Testing for stored webmin passwords: None Found
Could not auto detect login info!
Found potential sockets: /var/lib/mysql/mysql.sock Using: /var/lib/mysql/mysql.sock
Would you like to provide a different socket?: [y/N] n Do you have your login handy ? [y/N] : y
User: root
Password: password
Would you like me to create a ~/.my.cnf file for you? [y/N] : y ~/.my.cnf already exists!
Replace ? [y/N] : y
-- MYSQL PERFORMANCE TUNING PRIMER -- - By: Matthew Montgomery -
MySQL Version 5.5.41-MariaDB-log x86_64
Uptime = 9 days 22 hrs 21 min 11 sec
Avg. qps = 136
Total Questions = 116945853 Threads Connected = 1
Server has been running for over 48hrs.
It should be safe to follow these recommendations To find out more information on how each of these runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service
SLOW QUERIES
The slow query log is enabled.
Current long_query_time = 10.000000 sec.
You have 2487948 out of 116945874 that take longer than 10.000000 sec. to complete
Your long_query_time seems to be fine
BINARY UPDATE LOG
The binary update log is enabled
Binlog sync is not enabled, you could loose binlog records during a server crash
WORKER THREADS
Current thread_cache_size = 64 Current threads_cached = 63 Current threads_per_sec = 0 Historic threads_per_sec = 0
Your thread_cache_size is fine
MAX CONNECTIONS
Current max_connections = 512 Current threads_connected = 1
Historic max_used_connections = 259
The number of used connections is 50% of the configured maximum.
Your max_connections variable seems to be fine.
INNODB STATUS
Current InnoDB index space = 1.04 G Current InnoDB data space = 6.16 G Current InnoDB buffer pool free = 0 % Current innodb_buffer_pool_size = 6.00 G
Depending on how much space your innodb indexes take up it may be safe to increase this value to up to 2 / 3 of total system memory
MEMORY USAGE
Max Memory Ever Allocated : 7.13 G
Configured Max Per-thread Buffers : 1.46 G Configured Max Global Buffers : 6.39 G Configured Max Memory Limit : 7.85 G Physical Memory : 15.35 G
Max memory limit seem to be within acceptable norms
KEY BUFFER
Current MyISAM index space = 1 M Current key_buffer_size = 256 M Key cache miss rate is 1 : 31 Key buffer free ratio = 81 %
Your key_buffer_size seems to be fine
QUERY CACHE
Query cache is enabled
Current query_cache_size = 128 M Current query_cache_used = 116 M Current query_cache_limit = 8 M
Current Query cache Memory fill ratio = 90.99 % Current query_cache_min_res_unit = 4 K
However, 5758316 queries have been removed from the query cache due to lack of memory
Perhaps you should raise query_cache_size
MySQL won't cache query results that are larger than query_cache_limit in size
SORT OPERATIONS
Current sort_buffer_size = 2 M
Current read_rnd_buffer_size = 256 K
Sort buffer seems to be fine
JOINS
./tuning-primer.sh: line 402: export: `2097152': not a valid identifier Current join_buffer_size = 260.00 K
You have had 62647 queries where a join could not use an index properly You have had 588 joins without keys that check for key usage after each row
You should enable "log-queries-not-using-indexes" Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your join_buffer_size to accommodate larger joins in one pass.
Note! This script will still suggest raising the join_buffer_size when ANY joins not using indexes are found.
OPEN FILES LIMIT
Current open_files_limit = 2565 files
The open_files_limit should typically be set to at least 2x-3x that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine
TABLE CACHE
Current table_open_cache = 800 tables
Current table_definition_cache = 800 tables You have a total of 778 tables
You have 800 open tables.
Current table_cache hit rate is 2%
, while 100% of your table cache is in use
You should probably increase your table_cache
TEMP TABLES
Current max_heap_table_size = 32 M Current tmp_table_size = 32 M
Of 4970956 temp tables, 23% were created on disk
Created disk tmp tables ratio seems fine
TABLE SCANS
Current read_buffer_size = 128 K Current table scan ratio = 18 : 1
read_buffer_size seems to be fine
TABLE LOCKING
Current Lock Wait ratio = 1 : 68390
Your table locking seems to be fine
mysql_secure_installation
merupakan tools tambahan yang menjadi bawaan dari MySQL, tool ini dapat digunakan untuk meningkatkan keamanan server MySQL
# mysql_secure_installation
/usr/bin/mysql_secure_installation: line 379: find_mysql_client: command not found
NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!
In order to log into MariaDB to secure it, we'll need the current password for the root user. If you've just installed MariaDB, and you haven't set the root password yet, the password will be blank, so you should just press enter here.
Enter current password for root (enter for none): OK, successfully used password, moving on...
Setting the root password ensures that nobody can log into the MariaDB root user without the proper authorisation.
Set root password? [Y/n] y New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables.. ... Success!
By default, a MariaDB installation has an anonymous user, allowing anyone to log into MariaDB without having to have a user account created for them. This is intended only for testing, and to make the installation go a bit smoother. You should remove them before moving into a
production environment.
Remove anonymous users? [Y/n] y
... Success!
Normally, root should only be allowed to connect from 'localhost'. This ensures that someone cannot guess at the root password from the network. Disallow root login remotely? [Y/n] y
... Success!
By default, MariaDB comes with a database named 'test' that anyone can access. This is also intended only for testing, and should be removed before moving into a production environment.
Remove test database and access to it? [Y/n] y
- Dropping test database... ... Success!
- Removing privileges on test database... ... Success!
Reloading the privilege tables will ensure that all changes made so far will take effect immediately.
Reload privilege tables now? [Y/n] y ... Success!
Cleaning up...
All done! If you've completed all of the above steps, your MariaDB installation should now be secure.