Lar*_*y B 0 mysql optimization innodb centos magento
我们的专用服务器正在运行一个大型 Magento 商店，其中有一个大约 250MB 的 MySQL 数据库。
服务器规格被列为具有 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
我已经看到建议的 my.cnf 用于 magento 专用数据库服务器（2GB ram）：
query_cache_size = 512M
query_cache_limit = 256M
tmp_table_size = 256M
key_buffer_size = 64M
read_buffer_size = 128M
read_rnd_buffer_size = 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:autoextend
innodb_autoextend_increment=32
我想知道是否有人可以根据我们的规范建议 my.cnf 参数的最佳值？
此外，如果在修补它们时我应该注意任何事情，例如：将其设置得太高并预计会出现灾难性故障。
任何想法将不胜感激。干杯。
当您对单个用户进行性能测试时，MySQL 通常是 Magento 存储的最后一个瓶颈。然而，my.cnf对于 Magento 商店或该服务器规范而言，您看起来并不理想。我在这里写了关于 Magento 的 MySQL 负载的详细答案，
https://serverfault.com/a/367856/113375
目前，您的最大努力是通过其他方式（更改主机/优化模板等）专注于改善页面加载时间并最后处理数据库；这实际上只适用于并发测试和事务负载。
来自 http://docs.sonassihosting.com/go_dedicated.pdf
根据您的 CPU 架构和总线速度 - 使用下图，您能够实现的最佳 PHP 页面渲染时间是 0.8 秒（不包括图像/js/css）。
让您大致了解要选择的硬件
在选择服务器时，您需要牢记两个数字：并发性和页面加载时间。并发是您的服务器在任何时候可以支持的客户数量。单个页面加载时间是单个客户实际加载页面的速度。
可能有：
- 缓慢的页面加载时间和低并发支持（低时钟速度 CPU (GHz)，很少的内核）
- 快速的页面加载时间，但低并发支持（高时钟速度 CPU (GHz)，很少的内核）
- 页面加载时间慢，但支持高并发（低时钟速度 CPU (GHz)，大量内核）
- 快速的页面加载时间和高并发支持（高时钟速度 CPU (GHz)，大量内核）
您可以根据此选择您的硬件。
并发
a) 标准的 Magento 演示商店能够在每小时每 GHz 提供大约 230 个唯一身份。
b) 一个典型的网络商店，具有管理员用户活动、开发活动、产品添加/删除可以看到这种下降大约 100%，达到每小时 115 个唯一身份/GHz。
c) 具有不良构建/重模板的商店可以进一步将数字再减少 100-200%，达到每小时每 GHz 50 个唯一身份。
当我们引用数字时，我们使用选项 b)。
单个页面加载时间
标准的 Magento 演示商店（CE 或 EE – 当 FPC 被禁用时）能够在以下位置加载主页：
Run Code Online (Sandbox Code Playgroud)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 的缺点
每个用户都有 root 访问权限。这意味着您系统上的其他 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 服务器。最坏的情况是，当他们根本没有处理经验的情况下出现问题时，会导致盲目恐慌。
为了获得更好/更准确的答案，请发布有关您商店的更多详细信息-
| 归档时间： |
|
| 查看次数： |
22958 次 |
| 最近记录： |