为什么Percona pt-online-schema-change表现如此糟糕？

Question

我们已经使用Percona OSC，而现在进行修改，我们的MySQL架构不锁定表和它一直很大，通常在添加新列或索引“大” InnoDB表（〜380万行）几个小时。

不过，最后更新我试过了（在我们最安静的时期过夜）7小时后运行只有40％完成，与另外11小时估计完成（这不断增加）。 RedHat服务器上的所有可用内存条均为4GB - 我们最近从16GB升级到32GB。

那么这里发生了什么？为什么突然间的时间突然增加了呢？我们刚刚达到percona/mysql /服务器无法应付的某种阈值吗？有没有我们可以调整的配置来提高性能？

该表有32列和12个索引（包括主键和2个其他唯一索引）。我知道这很多，但直到最近它才表现得很好。

表也有几个外键指向它，我们设置使用drop_swap方法来更新。

我使用的完整的命令是：

pt-online-schema-change --execute --ask-pass --set-vars innodb_lock_wait_timeout=50 --alter-foreign-keys-method=drop_swap 
--alter "ADD is_current TINYINT(1) DEFAULT '1' NOT NULL" u=admin,p=XXXXXXX,D=xxxxx_live,t=applicant 

的innodb_buffer_pool_size当前设置为2147483648 - 这应该增加多少？如果是这样，多少？ Web服务器（apache/php/symfony）也在这个盒子上运行。

我在这个特定的表上做出的最后一项更改是将1字段的排序规则更改为utf8_bin（其他字段为utf8_unicode_ci） - 这可能会有所作为吗？

Answer 1

假设所有的事情都是平等的，我会说某种阈值已经越过或某个其他进程正在加载数据库。 您使用的索引数量很高。 pt-osc创建新的空变更表格，然后开始以“块”复制。每个块所花费的时间会动态调整为0.5秒（默认情况下）。 您可以通过查看“show processlist”来查看谁在向数据库施压，以及pt-osc使用哪些块大小以获取更多信息。

Answer 2

这张表在MB/GB方面有多大？

InnoDB的缓存它在InnoDB的缓冲池（innodb_buffer_pool_size）页面，这对于性能非常重要。在具有> 4GB RAM的专用主机上，我们建议大约70-80％的内存指导应该用于InnoDB缓冲池。

使用SQL对这个职位收集你的表的逻辑尺寸和索引

https://www.percona.com/blog/2008/03/17/researching-your-mysql-table-sizes/

有了这些信息，你就可以立即告诉我们，如果MySQL实例（InnoDB引擎）是被内存不足。

如果你的工作数据集适合在内存中，那么很好，但如果不是，那么你很可能招致缓存未命中，然后MySQL将需要执行IO来访问磁盘资源以将页面交换到缓冲池中。 （IO总是在DB土地PITA）

的PT-OSC工作的性质是创建表的新修改的副本和回填从原来的行的新版本。新行也可以使用工具设置的触发器插入/更新或删除。要执行此回填，它必须在某个点触及该表中的所有行，并且大部分表可能很冷（不在RAM的缓冲池中）。所以基本上你机器上的RAM数量不多，但真正的InnoDB只能看到2GB的内存。

您的应用程序也在服务器上运行，因此您需要仔细观察一下您的情况，但我希望您可以大大提高分配给缓冲池的内存级别。我也希望你的大部分RAM没有被使用，但已经被分配到文件系统缓存中。

如果你的表只有几百MB（我怀疑它有4m记录和一个广泛的模式），那么可能有更深层次的问题需要复习，但我相信通过改变bufferpool的大小，你会看到一些更好的表现。

此外，它正在检查您的innodb_log_file_size是否适合您的工作量。这很重要，以便MySQL可以推迟IO。现在的尺寸是多少？