9

我们正在运行 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 不再抱怨我们的应用程序没有关闭它们的连接。我们确实需要做一些改进,因为并非我们所有的查询都正确使用了索引,但现在这个修复帮助我们保持服务器正常运行。

亲切的问候,桑德。

4

3 回答 3

1

我发现服务器性能可以通过多种方式“升级”,其中一些是:

  1. 弄清楚你需要多少内存才能让 MySQL 遍历所有数据,同时还要提供大量已执行的 SQL 查询。您可以在此处阅读所有与内存相关的内容并了解其工作原理。之后,您可以启用大页面支持

  2. 我发现您可以通过启用APC来提高性能,您可以实际看到它是如何提高性能的。也看看这个

  3. 使用varnish,但在这里输入的内容很长。归根结底,您需要一个非常好的配置才能使其完美运行。

  4. 如果您仍然遇到问题,请尝试使用Xdebug找出阻碍每个进程的原因。不过,您可以从一开始就执行最后一个,因为您的 MySQL 将尝试执行您要求的所有内容,但一次执行 1 个进程。因此,它将存储它无法在内存中执行的每个进程,如果发生这种情况,它会溢出你的内存。

我的结论是,您可以通过从现金(Varnish、APC、MySQL mem)中获取更多与 php/mysql 相关的东西(您的服务器需要时间/资源用于什么)来重复使用,它可以处理的连接越多,无需造成高服务器负载。

于 2013-11-15T14:13:43.213 回答
0

你检查过你的可用空间吗?有一天,由于 magento 创建了巨大的日志 txt 文件,我们遇到了一些问题。检查您的 magento 站点,他们已从开发人员-> 日志设置中禁用了日志错误。这些文件的大小没有限制!至少这就是我所知道的......希望对你有所帮助。干杯!

于 2013-11-15T13:51:22.867 回答
0

桑德,

不确定服务器的事情,虽然在 magento 中工作发现了一些有用的东西,你可能想研究一下。

一些托管公司提供具有优化服务器的高质量 Magento 托管解决方案,以确保最佳 Magento 性能。以下是您可能会考虑的一些示例:

  • 单螺旋
  • 多余的
  • Peer1Hosting
  • 零滞后

此外,一旦我阅读了有关使用大数据和客户访问(大型数据库事务)的集群 magento,这是在 Web、数据库和文件系统级别完成的。

这是这样做的指南:

http://www.severalnines.com/blog/how-cluster-magento-nginx-and-mysql-multiple-servers-high-availability

还有一些简单但有用的提示是:

  • 启用js、css文件合并
  • 关闭日志
  • 启用编译
  • 设置索引器 cron

我相信 wordpress 也必须有同样的东西。

希望以上可以帮助一点,如果不是完全。

于 2013-11-15T13:44:46.730 回答