我们的专用服务器正在运行一个大型 Magento 商店，其 MySQL 数据库大小约为 250MB。
该服务器规格为拥有 5 个 Xeon 2Ghz 处理器（4MB 缓存）和 12GB 内存。
我原本以为上述规格足以让 Magento 快速运行，然而尽管网站速度不慢，但实际上并没有它应该的那么快。
当前MySQL my.cnf文件如下：
skip-innodb
ft_min_word_len=3
query_cache_limit = 4M
query_cache_size = 16M ## 32MB for every 1GB of RAM
query_cache_type = 1
max_user_connections = 50
max_connections = 50
interactive_timeout = 300
wait_timeout = 200
connect_timeout = 200
thread_cache_size = 32
key_buffer_size = 64M ## 128MB for every 1GB of RAM
join_buffer_size = 1M
max_connect_errors = 20
max_allowed_packet = 12M
table_cache = 1024
record_buffer = 1M
sort_buffer_size = 1M ## 1MB for every 1GB of RAM
read_buffer_size = 1M ## 1MB for every 1GB of RAM
read_rnd_buffer_size = 1M ## 1MB for every 1GB of RAM
thread_concurrency = 4 ## Number of CPUs x 2
myisam_sort_buffer_size = 32M
tmp_table_size = 16M
max_heap_table_size = 12M
[safe_mysqld]
open_files_limit = 2048
[mysqldump]
quick
max_allowed_packet = 12M
我看到过针对 magento 专用数据库服务器（2GB 内存）的建议 my.cnf 为：
查询缓存大小 = 512M
查询缓存限制 = 256M
tmp_table_size = 256M
密钥缓冲区大小 = 64M
读取缓冲区大小 = 128M
读取缓冲区大小 = 128M
批量插入缓冲区大小 = 64M
myisam_sort_buffer_size = 128M
myisam_max_sort_file_size = 128M
myisam_max_extra_sort_file_size = 128M
myisam_repair_threads = 2
myisam_recover
innodb_additional_mem_pool_size = 256M
innodb_log_buffer_size = 128M
innodb_log_file_size = 128M
innodb_log_files_in_group = 2
默认情况下，innodb_flush_log_at_trx_commit 为 0。
innodb_buffer_pool_size = 512M
innodb_data_home_dir = /var/lib/mysql/
innodb_data_file_path = ibdata1:256M:自动扩展
innodb_autoextend_increment = 32
我想知道是否有人可以根据我们的规范为 my.cnf 参数建议最佳值？
此外，当我对它们进行修补时，我应该注意什么，比如：如果设置得太高，可能会导致灾难性的失败。
任何想法都将不胜感激。干杯。
答案1
MySQL 通常是最后的当您为单个用户进行性能测试时，Magento 商店的瓶颈。尽管如此，您的结果my.cnf看起来并不是 Magento 商店的最佳选择，也不是该服务器规格的最佳选择。我在这里写了一个关于 Magento 的 MySQL 负载的详细答案，
https://serverfault.com/a/367856/113375
目前，您最好的努力是通过其他方式（更改主机/优化模板等）集中精力改善页面加载时间，最后解决数据库问题；这实际上只对并发测试和事务负载起作用。
从 http://docs.sonassihosting.com/go_dedicated.pdf
根据您的 CPU 架构和总线速度 - 使用下面的图表，您能够实现的最佳效果是 0.8 秒的 PHP 页面渲染时间（不包括 images/js/css）。
让您大致了解要选择的硬件
在选择服务器时，您需要记住两个数字：并发性和页面加载时间。并发性是指您的服务器可以随时支持多少客户。单个页面加载时间是指页面为单个客户实际加载的速度。
有可能：
- 页面加载速度慢，并发支持低（CPU 主频低 (GHz)、核心少）
- 页面加载速度快，但并发支持低（高时钟速度 CPU（GHz）、核心数少）
- 页面加载速度较慢，但支持高并发（低时钟速度 CPU（GHz）、多核心）
- 快速的页面加载时间和高并发支持（高时钟速度 CPU（GHz）、大量核心）
您可以据此选择您的硬件。
并发
a) 标准的 Magento 演示商店每 GHz 每小时能够提供大约 230 个唯一访问者。
b) 一个典型的网上商店，包括管理员用户活动、开发活动、产品添加/删除，可以看到这一数字下降了大约 100%，即每 GHz 每小时 115 个唯一身份访问。
c) 如果商店的模板构建不良/过于繁重，则该数字还会进一步降低 100-200%，即每 GHz 每小时 50 个唯一访问者。
当我们引用数字时，我们使用选项 b)。
单个页面加载时间
标准 Magento 演示商店（CE 或 EE - 当 FPC 被禁用时）能够以以下方式加载主页：
0.7 seconds 2.4GHz CPU 0.6 seconds 2.8GHz CPU 0.51 seconds 3.3GHz CPU 0.48 seconds 3.46GHz CPU但同样，构建不良/过重的模板会导致该数字呈指数级增长。当我们引用数字时，我们使用带有示例数据的演示商店模板作为示例。
以上来源摘自http://docs.sonassihosting.com/go_dedicated.pdf
我假设您有 5 个 CPU - 您使用的是 VPS（云或其他），如果是这样，I/O 可能会成为您的瓶颈，无论是磁盘还是网络。不幸的是，由于 VPS 的竞争性质 - 它们对于 Magento 托管来说从来都不是真正理想的选择 - 除非管理它的个人/公司对 Magento 优化有非常深入的了解并且硬件没有竞争。
Magento 的 VPS 缺点
每个用户都有根访问权限。这意味着您系统上的其他 VPS 节点可以启动 bonnie/iperf/hping，然后消耗无法分区/拆分的资源 - HDD I/O、网络或中断。因此，即使您有保证的 CPU/RAM - 您也受共享子系统的影响。
你的 CPU 和 RAM 有限。是的，您可以扩大/缩小规模 - 但最终，小型 Magento 商店受益于分配给 MySQL 实例的最低 2GB RAM，结合 1GB RAM/逻辑 CPU 核心的经验法则。因此，VPS 至少应该有 3GB RAM 和 1 个 CPU 核心 - 至少最多（经过适当调整后）将能够为 Magento 商店每天服务大约 1,500 名独立访客 - 假设没有 HDD I/O 或网络 I/O 瓶颈。
你必须自己处理。奇怪的是，如今电子商务网站所有者和运营商还应负责设置、监控和管理其托管基础设施。店主应该专注于他们擅长的领域 - 经营业务，而不是尝试解决错误、调整性能或管理命令行 Linux 服务器。最糟糕的情况是，当出现问题时，他们根本没有处理经验，从而导致盲目恐慌。
为了获得更好/更准确的答案，请发布有关您商店的更多详细信息-
- 每日独立访客数量是多少？
- 每位访客的页面浏览量？
- 游客主要来自哪个国家？
- 您预计未来 12 个月网站流量会增长吗？如果会，增长多少？
- 您的网站提供数字下载吗？
- 商店浏览次数？
- 目录中的产品数量？
- 目录中有多少个类别？
- 目录中的属性数量？
- 目录中的属性集数量？
- 当前磁盘空间使用情况？
- 当前带宽使用情况？
- 每日交易量是多少？
答案2
我将跳过大量的文字并直接切入正题。
看一下这些：
max_user_connections = 50
max_connections = 50
Apache 默认运行 500 个连接。目前，如果有 50 个请求发往 MySQL / MySqlI，则更多请求将被拒绝。