2017-05-31 46 views
1

在过去的几天里,我们遇到了MySQL(旧版本5.1.69)的一些奇怪的性能问题。 慢日志显示的东西,如:在MySQL的重负载下插入/删除行需要几秒钟

# [email protected]: jboss[jboss] @ localhost [127.0.0.1] 
# Query_time: 46.595796 Lock_time: 0.000022 Rows_sent: 0 Rows_examined: 0 
SET timestamp=1496127084; 
insert into ACTIVE_RENT (LINE_ID, CHARGED_UP_TO, EVENT_ID, NUMBER, RENT_START, TYPE) values (149914, '2017-05-02 00:00:00', 625751, 'ABCD1234567', '2013-08-02 00:00:00', 'DETENTION'); 

# [email protected]: jboss[jboss] @ localhost [127.0.0.1] 
# Query_time: 19.401896 Lock_time: 0.000041 Rows_sent: 0 Rows_examined: 0 
SET timestamp=1496127084; 
delete from ACTIVE_RENT where ACTIVE_RENT_ID=463965; 

没有对删除或更新指定的级联,它只有一个外键到另一个表,并有此表没有触发器。桌子真的很基本。而且只有大约14k行。 通常情况下,这些插入或删除操作非常快,但最后几天它们在高峰时间可能非常缓慢。

我们增加了innodb_buffer_size到20G,但是这并没有太大的改变(就这个问题而言,其他的东西更快)。目前数据库大小约为40GB。 下面是my.conf。任何想法瓶颈可以从哪里来,以及如何处理它?我们正计划将MySQL升级到5.5版,但这种情况在几周内不会发生。

[client] 
default-character-set=utf8 
socket=/home/mysql-data/mysql/mysql.sock 

[mysql] 
default-character-set=utf8 
max_allowed_packet=32M 

[mysqld] 
# these are the install settings 
local-infile=0 
open_files_limit=8192 
query_cache_size = 256M 
query_cache_type = 1 
query_cache_limit = 6M 
query_prealloc_size = 16384 
query_alloc_block_size = 2048 
tmp_table_size = 128M 
max_heap_table_size = 256M 
table_cache = 1024 
thread_cache_size = 512 
key_buffer = 256M 
join_buffer_size = 8M 
read_buffer_size = 8M 
sort_buffer_size = 8M 
innodb_lock_wait_timeout = 120 
binlog_format=row 
max_allowed_packet=32M 
log-bin=mysql-bin 
server-id=1 
#Allow group_concat to return longer data types 
group_concat_max_len=16384 
default-character-set = utf8 
skip-character-set-client-handshake 
collation-server = utf8_unicode_ci 
init-connect='SET NAMES utf8' 
character-set-server = utf8 
innodb_buffer_pool_size = 20GB 
+0

检查服务器是否需要在磁盘临时表中创建批次...检查SHOW STATUS命令是否为此变量Created_tmp_disk_tables ...临时磁盘表是MyISAM表可能导致大量I/O使服务器执行少得多... –

回答

0

query_cache_size = 256M - 太大了。每当发生写入时,必须清除该表中QC的全部条目。这种时间与大小大致成正比。降至50M

您的表InnoDB?如果服务器有64GB并且主要用于MySQL,那么将buffer_pool设置为70%。

ACTIVE_RENT_IDPRIMARY KEY

进入InnoDB的一行INSERT不会花费46s,除非长期运行ALTER正在进行。环视四周;涉及其他事情。或者,也许是一个长期运行的交易,最终超时50秒?你在用autocommit=0吗? (我希望不是。)你在使用BEGIN...COMMIT吗?

表格的大小ACTIVE_RENT