Jer*_*emy 5 mysql innodb percona
我们的数据库中UPDATE性能偶尔会出现大幅放缓.
例如,表FooTable我们有大约40列varchar PK,另外还有10个索引.以下查询花了44秒,而在其他时候它几乎立即运行.在减速期间,服务器上的负载平均值非常低(5分钟平均值为1.5),并且根据vmstat的IO也是相当合理的.
这是一个例子:
mysql> update FooTable set BarColumn=1349981286086 where varcharPK='e4348411-0fbb-460a-80f7-f1de304a9f7c'
Query OK, 1 row affected (44.94 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> show profile for QUERY 1;
+----------------------+-----------+
| Status | Duration |
+----------------------+-----------+
| starting | 0.000030 |
| checking permissions | 0.000004 |
| Opening tables | 0.000007 |
| System lock | 0.000003 |
| Table lock | 0.000003 |
| init | 0.000035 |
| Updating | 44.949727 |
| end | 0.000006 |
| query end | 0.000003 |
| freeing items | 0.000115 |
| logging slow query | 0.000002 |
| logging slow query | 0.000052 |
| cleaning up | 0.000003 |
+----------------------+-----------+
13 rows in set (0.02 sec)
Run Code Online (Sandbox Code Playgroud)
值得一提的是,上面的示例查询是在InnoDB表上运行的,该表是在一周前的"重建"(ALTER TABLE FooTable ENGINE = InnoDB;).我最初怀疑这与InnoDB已知的varchar /非顺序PK性能问题有关,但是我们有其他表使用顺序PK并且看到了相同的问题.
这是在生产服务器上:Centos 5 2.6.18-238.19.1.el5 x86_64 MySQL/Percona 5.1.57-rel12.8-log 96GB内存,在87个表中分布有58.8G数据
相关的InnoDB设置如下:
innodb_flush_log_at_trx_commit = 2
innodb_buffer_pool_size = 70G
innodb_log_file_size = 512M
innodb_log_buffer_size = 64M
innodb_file_per_table = 1
innodb_thread_concurrency = 0
innodb_flush_method = O_DIRECT
innodb_read_io_threads = 64
innodb_write_io_threads = 64
optimizer_search_depth = 0
innodb_file_format = barracuda
Run Code Online (Sandbox Code Playgroud)
我没有在这张桌子上使用FORMAT = COMPRESSED,但我在其他人身上.
关于如何弄清楚在更新阶段发生了多长时间的事情的任何建议?