我在 DigitalOcean 上运行 VPS，内存为 8GB，4 核。我们使用的是 Ubuntu 32 位。
最近遇到了一个问题，mysql 进程占用了 100% 的 CPU 负载，导致我们的服务器变慢。我尝试了网上能找到的各种方法，希望能得到一些帮助来配置我们的设置。
它是一个数据库密集型站点，我们将其用作我们主站点的 API 端点并托管许多其他站点。
运行 myqsltuner 后：
-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.5.47-0ubuntu0.12.04.1-log
[!!] Switch to 64-bit OS - MySQL cannot currently use all of your RAM
-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in InnoDB tables: 312M (Tables: 84)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[--] Data in MyISAM tables: 7K (Tables: 23)
[!!] Total fragmented tables: 84
-------- Security Recommendations ------------------------------------ -------
[OK] All database users have passwords assigned
-------- Performance Metrics -------------------------------------------------
[--] Up for: 5m 44s (6K q [19.360 qps], 500 conn, TX: 4M, RX: 981K)
[--] Reads / Writes: 67% / 33%
[--] Total buffers: 1.7G global + 2.7M per thread (160 max threads)
[!!] Allocating > 2GB RAM on 32-bit systems can cause system instability
[!!] Maximum possible memory usage: 2.1G (26% of installed RAM)
[OK] Slow queries: 0% (0/6K)
[OK] Highest usage of available connections: 5% (8/160)
[OK] Key buffer size / total MyISAM indexes: 128.0M/169.0K
[!!] Key buffer hit rate: 50.0% (6 cached / 3 reads)
[!!] Query cache efficiency: 8.4% (355 cached / 4K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 1% (2 temp sorts / 104 sorts)
[OK] Temporary tables created on disk: 19% (54 on disk / 274 total)
[OK] Thread cache hit rate: 98% (8 created / 500 connections)
[OK] Table cache hit rate: 95% (153 open / 160 opened)
[OK] Open file limit used: 9% (95/1K)
[OK] Table locks acquired immediately: 100% (5K immediate / 5K locks)
[OK] InnoDB data size / buffer pool: 312.9M/1.0G
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours - recommendations may be inaccurate
Variables to adjust:
query_cache_limit (> 512M, or use smaller result sets)
CPU 图表 这些峰值似乎是在 cron 作业运行时出现的。我们有一些作业对我们的产品数据进行分析，并使用结果更新相应的表格。
当它降回 0 时，这是因为我尝试进行一些研究、更改设置并重新启动服务后重新启动了该服务。
答案1
首先要做的事情是将自己转移到 64 位操作系统。这将允许您使用更多的系统资源。除非您这样做，否则做其他任何事情都没有意义。罗马大火时，我想起小提琴。
答案2
修复您的代码，而不是管理员问题。
请耐心听我说 - 我是一名 SQL Server 用户，而不是 MySql 用户，但是在 SQL Server 和 Oracle 中都看到过这种情况并了解了原因后，我并不认为 MySql 有什么神奇的不同。
我还没有看到 SQL Server CPU 过载的情况。这不是开玩笑。
一般来说，数据库不是 CPU 受限，而是 IO 受限。IO 通常通过内存（用于缓存）来缓解。
但是高（极高）的 CPU 使用率要么是可笑的坏服务器（比如 2000 个并行请求的 qauad 核心），要么是 SQL 写得非常糟糕（例如，将整数转换为字符串，然后将它们连接起来）。
现在，运行 32 位系统（严重的错误）将确保您无法使用真正半像样的硬件（由于 32 位地址空间的限制），但这主要应该显示在更低的性能和 CPU 使用率中，因为 CPU 由于缓冲不足而等待 IO。
现在，如果您将 CPU 负载视为负载因子而不是利用率，那么这将显示高负载因子，但利用率并不高。CPU 负载显示为等待处理的 CPU 进程，并且等待可能是 IO 操作。这值得进一步调查，但它不会像您的标题所示：“MySQL 使用 100% CPU”——这表明 CPU 利用率，而不是负载因子。这确实会指向荒谬的 SQL 编写，缺少顶部索引。
如果是这种情况 - 那就认真看看 SQL。如果是负载因素，那就转到一个不错的操作系统（即 64 位）并添加 RAM 并检查 IO 统计数据 - 任何不错的数据库服务器一段时间以来都在 SSD 上运行是有原因的。
答案3
只是分享我的经验，我已经设置了一个 LAMP 堆栈 32 位 linux VPS（ESXi），带有 8G RAM，运行内核 PAE，当网站推出和加载稍微增加时，php fastcgi 和 mysqld 的负载就会变高，loadavg 会泵到 100，服务器变得无法访问。
然后我尝试将内核切换回正常的 32 位，仅使用 ~4G RAM，问题消失，但有时会遭受 OOM-killer 的困扰。因此，我设置了另一台具有相同配置和软件包的 64 位服务器，将所有内容都切换到它。到目前为止，近 3 年没有出现任何问题。