我们正在运行 VPS，并且遇到由 mysql 服务器引起的高负载。目前我们无法找到这个问题的原因，因此我希望有人能指出我正确的方向。
VPS 有 4 个 CPU 和 4GB（18/11 编辑：现在 8GB）可用 RAM。磁盘信息不可用，但我相信它们不是最快的。在这个 VPS 上，我们运行 1 个 magento CE 1.7.0.2 安装和 20 个网上商店和 8 个 wordpress 安装（连接到 magento 系统）。我们确实在 magento 系统中安装了一些自定义扩展。我们使用 Ubuntu 13.04 和 Nginx 1.2.6、mysql 5.5.34、PHP 5.4.9、varnishd 3.0.4 并使用 APC 作为操作码缓存器。
顶部运行时：
top - 13:58:21 up 17:51, 2 users, load average: 4.40, 4.09, 3.91
Tasks: 119 total, 3 running, 116 sleeping, 0 stopped, 0 zombie
%Cpu(s): 94.0 us, 3.5 sy, 0.0 ni, 2.0 id, 0.2 wa, 0.0 hi, 0.0 si, 0.3 st
KiB Mem: 4049220 total, 3101744 used, 947476 free, 253548 buffers
KiB Swap: 1044476 total, 22324 used, 1022152 free, 1442356 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22378 mysql 20 0 3439m 588m 7888 S 224.0 14.9 73:21.99 mysqld
24650 eemeega6 20 0 532m 56m 28m S 26.0 1.4 0:11.25 php5-fpm
24658 eemeega6 20 0 534m 57m 27m S 25.8 1.5 0:02.80 php5-fpm
24649 eemeega6 20 0 529m 58m 33m S 25.4 1.5 0:12.95 php5-fpm
24652 eemeega6 20 0 532m 61m 33m R 22.2 1.5 0:05.00 php5-fpm
24659 eemeega6 20 0 538m 59m 25m R 16.6 1.5 0:00.83 php5-fpm
24661 eemeega6 20 0 533m 55m 27m S 16.2 1.4 0:00.81 php5-fpm
24648 eemeega6 20 0 535m 65m 34m S 15.4 1.7 0:14.46 php5-fpm
24653 eemeega6 20 0 536m 64m 32m S 11.8 1.6 0:04.55 php5-fpm
24662 eemeega6 20 0 533m 49m 21m S 6.2 1.3 0:00.31 php5-fpm
1236 nobody 20 0 731m 369m 76m S 1.0 9.4 6:38.74 varnishd
22478 www-data 20 0 90532 10m 1044 S 0.4 0.3 0:07.56 nginx
10 root 20 0 0 0 0 S 0.2 0.0 2:29.32 rcu_sched
247 root 20 0 0 0 0 S 0.2 0.0 1:20.05 jbd2/dm-0-8`
我们的 my.cnf 文件具有以下值：
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
bind-address = 127.0.0.1
key_buffer = 64M
max_allowed_packet = 1M
thread_stack = 192K
thread_cache_size = 8
myisam-recover = BACKUP
max_connections = 50
table_cache = 2048
table_definition_cache = 1024
#thread_concurrency = 10
thread_cache_size = 24
wait_timeout = 60
interactive_timeout = 60
query_cache_limit = 1M
query_cache_size = 64M
log_error = /var/log/mysql/error.log
log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 8
#log-queries-not-using-indexes = /var/log/mysql/mysql-not-indexes.log
expire_logs_days = 10
max_binlog_size = 100M
#InnoDB
innodb_buffer_pool_size = 1280M
innodb_additional_mem_pool_size = 32M
innodb_log_buffer_size = 1M
innodb_thread_concurrency = 8
innodb_lock_wait_timeout = 60
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
[mysql]
#no-auto-rehash # faster start of mysql but no tab completition
[isamchk]
key_buffer = 16M
!includedir /etc/mysql/conf.d/
mysqltuner.pl 的输出：
[--] Reads / Writes: 97% / 3%
[--] Total buffers: 1.4G global + 2.7M per thread (50 max threads)
[OK] Maximum possible memory usage: 1.6G (40% of installed RAM)
[OK] Slow queries: 0% (0/1M)
[OK] Highest usage of available connections: 42% (21/50)
[OK] Key buffer size / total MyISAM indexes: 64.0M/35.4M
[OK] Key buffer hit rate: 99.8% (902K cached / 1K reads)
[!!] Query cache efficiency: 1.2% (16K cached / 1M selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 739K sorts)
[!!] Joins performed without indexes: 129
[OK] Temporary tables created on disk: 5% (56K on disk / 1M total)
[OK] Thread cache hit rate: 99% (21 created / 16K connections)
[OK] Table cache hit rate: 24% (940 open / 3K opened)
[OK] Open file limit used: 9% (378/4K)
[OK] Table locks acquired immediately: 100% (4M immediate / 4M locks)
[OK] InnoDB data size / buffer pool: 339.7M/1.2G
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Adjust your join queries to always utilize indexes
Variables to adjust:
query_cache_limit (> 1M, or use smaller result sets)
join_buffer_size (> 128.0K, or always use indexes with joins)
我们运行 mysql 的时间超过 24 小时，并根据 mysqltuner 和 tune-primer 使用优化的大多数设置。使用修复和优化功能来优化所有数据库。
不幸的是 mysql 正在交换到磁盘，因此我认为 CPU 负载很高。
我希望有人能指出我找到交换/高负载原因的正确方向。我们并没有经常遇到缓慢的日志查询（仅在重新索引 magento 时）。
如果有人需要更多信息，请问我。
[解决方案]：
所以基本上我们通过关闭 php.ini 中的持久连接解决了这个问题： mysql.allow_persistent = Off 我们注意到 mysql 的 CPU 使用率下降了。Tuning-prmier 不再抱怨我们的应用程序没有关闭它们的连接。我们确实需要做一些改进，因为并非我们所有的查询都正确使用了索引，但现在这个修复帮助我们保持服务器正常运行。
亲切的问候，桑德。