相关疑难解决方法(0)

我已经看到一些专用的 MySQL 服务器，它们只使用一个内核。我比 MySQL 的 DBA 更擅长开发，所以需要一些帮助

设置

服务器非常庞大，具有 OLAP/DataWarehouse (DW) 类型的负载：

• 主要：96GB RAM，8 核 + 单个 RAID 10 阵列
• 测试：32GB RAM，4核
• 最大的 DB 是 540 GB，总共大约 1.1TB，主要是 InnoDB 表
• Solaris 10 Intel-64
• MySQL 5.5.x

注意：最大的 DB 是从 OLTP DR 服务器复制的 DB，DW 就是从这里加载的。它不是完整的 DW：仅持续 6 个月到 6 周，因此它比 OLTP DB 小。

对测试服务器的观察

• 3 个独立的连接
• 每个都有一个并发的（和不同的） ALTER TABLE...DROP KEY...ADD INDEX
• 这 3 个表有 2.5、3.8 和 450 万行
• CPU 使用率上升到 25%（一个核心被最大化）并且不会更高
• 3 次 ALTER 需要 12-25 分钟（最小的一次需要 4.5 分钟）

问题

1. 需要什么设置或补丁才能允许使用多个内核？
   也就是说，为什么 …

RAM 的重要性是一个既定的事实，但在 MySQL 使用 CPU 时，关于内核和多线程重要性的资料要少得多。我说的是在 4cores vs 6cores vs 8cores 上运行 MySQL 的区别等等。

不同的存储引擎使用 CPU 的方式不同吗？

这是一个纯理论问题。假设我在多台服务器上部署了一个应用程序。

1. 负载均衡器，
2. 多个/可扩展的应用程序服务器
3. 一个（单一的）数据库服务器（目前）

在前两个部分，我知道要寻找什么。但是数据库服务器呢？我应该寻找什么样的硬件？

• CPU 频率与数据库服务器相关吗？
• 多核 CPU 是否相关？
• RAM比CPU重要吗？

PS：假设选择的数据库是 MySQL 或 PostgreSQL。

首先让我承认我对硬盘的内部工作原理非常无知。因此，当我阅读变量innodb_flush_method的手册时，它让我感到困惑。我可以用外行的术语解释 O_DSYNC 和 O_DIRECT 的区别，以及如何知道这是否是数据库服务器上的性能问题。

我的设置的一些统计信息：运行 MySQL 5.1.49-64 位的 Mac OSX 10.6（32 位内核，因为架构已过时）（希望它能让我使用内存）。8GB RAM，~6GB innodb 数据/索引。

我正在运行 MySQL 服务器，以在 Debian 作为来宾操作系统的 VM (VMWare) 上进行测试。来宾有四个模拟 CPU 内核，因此我将 thread_concurrency 设置为四个。

我在大型表上执行昂贵的连接，这可能需要几分钟，但我在来宾操作系统上看到，一次只使用一个核心。无论用于所涉及的表的存储引擎如何（使用 MyISAM 和 InnoDB 测试），都会发生这种情况。此外，在执行这些大型查询时，整个数据库似乎都被阻塞了，我无法并行执行任何其他查询。奇怪的是 htop 显示，用于查询的核心在查询运行时发生了变化！

为什么会发生这种情况？

这是来自SHOW FULL PROCESSLIST;（没有其他查询）的相关条目：

| 153 | root       | localhost | pulse_stocks  | Query   |   50 | Copying to tmp table | 
SELECT DISTINCT * FROM 
`pulse_stocks`.`stocks` sto,
`pulse_new`.`security` sec
WHERE
(sto.excntry = sec.excntry AND sto.stock_id = sec.ibtic) OR
( sto.isin = sec.isin AND sto.isin <> "" AND sec.isin <> "" )
ORDER BY
sto.id
LIMIT 0, 30 

没有其他待处理的查询。另一个有趣的观察是，如果我省略这 …

我见过一些人建议，应O_DSYNC与SAN中使用。

MySQL 文档对 O_DSYNC 的一般情况是这样说的：

在某些版本的 GNU/Linux 和 Unix 中，使用 Unix fsync() 调用（InnoDB 默认使用）和其他类似方法将文件刷新到磁盘的速度非常慢。如果您对数据库写入性能不满意，您可以尝试将 innodb_flush_method 参数设置为 O_DSYNC。O_DSYNC 刷新方法在大多数系统上的执行速度似乎较慢，但您的可能不是其中之一。

并专门针对与SAN使用：

在某些 InnoDB 数据和日志文件位于 SAN 的系统上，对于主要包含 SELECT 语句的读取繁重的工作负载，默认值或 O_DSYNC 可能会更快。始终使用反映您的生产环境的相同类型的硬件和工作负载测试此参数。

尽管他们建议人们应该测试，但措辞是如此空洞（即“某些系统，“可能是”），如果他们甚至不费心进行测试并坚持使用默认值（fdatasync），那么人们可以原谅。但在我的（不科学的）测试我发现 O_DSYNC 提供了巨大的性能优势 - 至少对于一些麻烦的 SELECT 查询。

我想知道是否有人可以更详细地解释为什么这个选项可以在使用 SAN 时提供这样的好处。本好书当然讨论了这个选项，而不是在一个SAN的环境。

我正在使用：

• MySQL 5.1 与 RHEL 6 (x86_64) 上的 InnoDB 插件
• 虚拟化环境（vSphere）；具有 FC 互连的 SAN 由我们的 IaaS 提供商提供
• 带有屏障=0 挂载选项的 Ext4 文件系统
• I/O 调度器是最后期限