Mariadb调优-慢写

Question

背景:我有一个网站，我正在从一个独立的MariaDB服务器迁移到一个MariaDB galera集群。其中的一部分让我将表从大量的MyISAM转换为InnoDB。不管它的价值是什么，该网站是一个大型joomla安装。

网站的前端端表现良好。那里没有问题。管理部分是痛苦的缓慢保存任何东西-25-30秒从你的时间点击保存，直到它完成。

安装3节点galera安装- 12核心Intel(R) Xeon(R) CPU E5-1650 v4 @3.60GHz64GBWSSD在Raid上

用于负载平衡的HA代理

/etc/my.cnf

[mysqld]
innodb_buffer_pool_siz=32Gb
innodb_log_file_size = 2Gb
innodb_flush_method=O_DIRECT
max_connections=750
innodb_flush_log_at_trx_commit=2
innodb_log_buffer_size=2Mb
query_cache_size=0
skip_name_resolve
sync-binlog=0

现在，我只有一个开发网站连接起来，这样我就可以可靠地测量正在发生的事情。在执行单个保存时，我注意到了等待的情况：

先保存：

MariaDB [(none)]> show global status like "%waits%";
+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| Innodb_log_waits              | 0     |
| Innodb_mutex_os_waits         | 4     |
| Innodb_mutex_spin_waits       | 4     |
| Innodb_row_lock_current_waits | 0     |
| Innodb_row_lock_waits         | 0     |
| Innodb_s_lock_os_waits        | 9     |
| Innodb_s_lock_spin_waits      | 11    |
| Innodb_x_lock_os_waits        | 1     |
| Innodb_x_lock_spin_waits      | 0     |
| Tc_log_page_waits             | 0     |
+-------------------------------+-------+
10 rows in set (0.01 sec)

保存后的

：

MariaDB [(none)]> show global status like "%waits%";
+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| Innodb_log_waits              | 0     |
| Innodb_mutex_os_waits         | 177   |
| Innodb_mutex_spin_waits       | 1580  |
| Innodb_row_lock_current_waits | 0     |
| Innodb_row_lock_waits         | 0     |
| Innodb_s_lock_os_waits        | 164   |
| Innodb_s_lock_spin_waits      | 687   |
| Innodb_x_lock_os_waits        | 656   |
| Innodb_x_lock_spin_waits      | 905   |
| Tc_log_page_waits             | 0     |
+-------------------------------+-------+

我知道innodb比myisam有更多的开销，但我认为禁用同步-binlog和将innodb_flush_log_at_trx_commit设置为2会有帮助，但我实际上看到的是写性能下降了大约1000%。

只是在寻找一些关于检查什么，什么可能是错误的指导。我不确定应用程序中单个保存的os_waits计数是否很高，在我看来似乎是如此，但我并不真正遵循导致它的原因或如何修复它。

在将慢速查询日志设置为2之后，这是它在尝试保存时捕捉到的唯一内容：

# Time: 180126 18:03:38
# User@Host: dev[dev] @  [192.168.10.200]
# Thread_id: 136  Schema: dev  QC_hit: No
# Query_time: 6.306918  Lock_time: 0.000000  Rows_sent: 0  Rows_examined: 109438
# Rows_affected: 82677
use dev;
SET timestamp=1517007818;
UPDATE jos_assets
SET lft = lft + 2
WHERE lft > 337711;
# Time: 180126 18:03:48
# User@Host: dev[dev] @  [192.168.10.200]
# Thread_id: 136  Schema: dev  QC_hit: No
# Query_time: 9.985669  Lock_time: 0.000000  Rows_sent: 0  Rows_examined: 109438
# Rows_affected: 82683
SET timestamp=1517007828;
UPDATE jos_assets
SET rgt = rgt + 2
WHERE rgt >= 337711;

提前结束。

Answer 1

这个问题非常特定于Joomla，并且与_assets表的效率低下有关。我想我应该更早地检查慢速查询日志，但正如您在最初的文章中看到的，在发布一篇导致更新82677行的新文章时，有两个查询正在一个“保存”中更新表。即使在最快的部署中，这也需要时间。

为什么Joomla每次保存帖子时都需要这样做，我不完全确定，但一些研究表明，删除该表中所有与文章相关的条目是安全的，因为该条目将其总共减少到大约4000行。现在快多了。

如果您的Joomla站点在转换为Innodb后速度较慢，请参阅以下页面，我在资产表中找到了一些信息：

https://www.itoctopus.com/creating-new-articles-on-your-joomla-website-is-taking-a-long-time-clean-your-assets-table