当777ms还不够好时(MariaDB调优)

时间:2015-08-06 22:16:20

标签: performance mariadb my.cnf

在过去的几个月里,我一直在横冲直撞,优化了我管理的Joomla网站。当我第一次开始时,主页过去常常在30-40秒内打开,尽管主机公司建议我反复升级我的专用服务器。

我能够通过虔诚地遵循GT Matrix和PingdomTools之类的所有建议(例如使用JCH-optimize,.htaccess缓存和压缩设置以及MaxCDN)将页面速度降低到大约800ms,但现在我和#39; m卡住了优化我的my.cnf设置,尝试了一些相关文章中提出的各种设置。使用当前设置打开主页的最快速度是刷新后的777毫秒,这可能听起来不是太糟糕,但请查看我的专用服务器的配置:

  • 2个四元组,128GB,2x480GB SSD RAID
  • CloudLinux /交友/ WHM
  • 阿帕奇/ suEXEC的/ PHP5 / FastCGI的
  • MariaDB 10.0.17(所有表转换为XtraDB / InnoDB)

网站流量适中,每天有10,000和20,000名访问者,浏览量约为200,000次。

这些是当前的my.cnf设置。我的目标是将页面速度降低到600毫秒以下,这应该可以使用这种硬件,只要它以正确的方式调整。

[mysqld]
local-infile=0
max_connections=10000
max_user_connections=1000
max_connect_errors=20
key_buffer_size=1G
join_buffer_size=1G
bulk_insert_buffer_size=1G
max_allowed_packet=1G
slow_query_log=1
slow_query_log_file="diskar/mysql-slow.log"
long_query_time=40
connect_timeout=120
wait_timeout=20
interfactive_timeout=25
back_log=500
query_cache_type=1
query_cache_size=512M
query_cache_limit=512K
query_cache_min_res_unit=2K
sort_buffer_size=1G
thread_cache_size=16
open_files_limit=10000
tmp_table_size=8G
thread_handling=pool-of-threads
thread_stack=512M
thread_pool_size=12
thread_pool_idle_timeout=500
thread_cache_size=1000
table_open_cache=52428
table_definition_cache=8192
default-storage-engine=InnoDB

[innodb]
memlock
innodb_buffer_pool_size=96G
innodb_buffer_pool_instances=12
innodb_additional_mem_pool_size=4G
innodb_log_bugger_size=1G
innodb_open_files=300
innodb_data_file_path=ibdata1:400M:autoextend
innodb_use_native_aio=1
innodb_doublewrite=0
innodb_user_atomic_writes=1
innodb_flus_log_at_trx_commit=2
innodb_compression_level=6
innodb_compression_algorithm=2
innodb_flus_method=O_DIRECT
innodb_log_file_size=4G
innodb_log_files_in_group=3
innodb_buffer_pool_instances=16
innodb_adaptive_hash_index_partitions=16
innodb_thread_concurrency
innodb_thread_concurrency=24
innodb_write_io_threads=24
innodb_read_io_threads=32
innodb_adaptive_flushing=1
innodb_flush_neighbors=0
innodb_io_capacity=20000
innodb_io_capacity_max=40000
innodb_lru_scan_depth=20000
innodb_purge_threads=1
innodb_randmon_read_ahead=1
innodb_read_io_threads=64
innodb_write_io_threads=64
innodb_use_fallocate=1
innodb_use_atomic_writes=1
inndb_use_trim=1
innodb_mtflush_threads=16
innodb_use_mfflush=1
innodb_file_per_table=1
innodb_file_format=Barracuda
innodb_fast_shutdown=1

我尝试了Memcached和APCU,但它没有用。使用'文件'作为Joomla全局配置中的缓存处理程序。是的,我运行了my-sqltuner,但这没有任何帮助。

就Linux而言,我是新手,并怀疑上述设置可以改进。有任何意见和/或建议吗?

1 个答案:

答案 0 :(得分:0)

long_query_time=40

Set that to 1 so you can find out what the slow queries are.

max_connections=10000

That is unreasonably high. If you come anywhere near it, you will have more problems than failure to connect. Let's say only 3000.

query_cache_type=1
query_cache_size=512M

The Query cache is hurting performance by being so large. This is because any write causes all QC entries for the table to be purged. Recommend no more than 50M. If you have heavy writes, it might be better to change the type to DEMAND and pepper your SELECTs with SQL_CACHE (for relatively static tables) or SQL_NO_CACHE (for busy tables).

What OS?

Are the entries in [innodb] making it into the system? I thought these needed to be in [mysqld]. Check by doing SHOW VARIABLES LIKE 'innodb%';.

Ah, buggers; a spelling error:

innodb_log_bugger_size=1G
innodb_flus_log_at_trx_commit=2
inndb_use_trim=1

and more??

After you get some data in the slowlog, run pt-query-digest, and let's discuss the top couple of queries.