MySQL正在查杀服务器IO

可能重复:
MySQL正在查杀服务器IO。

我pipe理一个相当大/繁忙的vBulletin论坛(在gigenet上运行),数据库是〜10 GB(〜9千万个post,每秒约60个查询),最近MySQL已经根据iotop和减慢网站。

我能想到的最后一个想法是使用复制,但我不知道这会有多less帮助和担心数据库同步。

我没有想法,任何提示如何改善的情况将不胜感激。

眼镜 :

Debian Lenny 64bit ~12Ghz (6 cores) CPU, 7520gb RAM, 160gb disk. Kernel : 2.6.32-4-amd64 mysqld Ver 5.1.54-0.dotdeb.0 for debian-linux-gnu on x86_64 ((Debian)) 

其他软件:

 vBulletin 3.8.4 memcached 1.2.2 PHP 5.3.5-0.dotdeb.0 (fpm-fcgi) (built: Jan 7 2011 00:07:27) lighttpd/1.4.28 (ssl) - a light and fast webserver 

PHP和vBulletin被configuration为使用memcached。

MySQL设置:

 [mysqld] key_buffer = 128M max_allowed_packet = 16M thread_cache_size = 8 myisam-recover = BACKUP max_connections = 1024 query_cache_limit = 2M query_cache_size = 128M expire_logs_days = 10 max_binlog_size = 100M key_buffer_size = 128M join_buffer_size = 8M tmp_table_size = 16M max_heap_table_size = 16M table_cache = 96 

其他:

 > vmstat procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- rb swpd free buff cache si so bi bo in cs us sy id wa 9 0 73140 36336 8968 1859160 0 0 42 15 3 2 6 1 89 5 > /etc/init.d/mysql status Threads: 49 Questions: 252139 Slow queries: 164 Opens: 53573 Flush tables: 1 Open tables: 337 Queries per second avg: 61.302. 

编辑其他信息。

首先,虽然只是切线相关,但是您应该考虑从MyISAM切换到InnoDB。 在可能的并发性下,它会performance得更好,并且在发生崩溃时丢失数据的可能性要小得多。

你有多less内存喂养到memcached实例? 如果你的驱逐和错过率很高,增加这一点可能会有帮助,但这需要一些实验。

考虑到您的数据集大小和可用的RAM,128MB的key_buffer肯定是太低了。 如果你可以腾出内存(或者如果切换到InnoDB,用“InnoDB缓冲池大小”replace“key_buffer”),我应该说它应该更像1-2GB。 你的“块入”是你的块的3倍,这可能意味着MySQL将不得不为磁盘的大部分读取。 您可以使用mysqltuner或phpmyadmin中的统计信息来查看sorting缓冲区等事情是否需要调整,但它们很可能不是最大的问题。

在查询caching中检查您的详细统计信息,例如命中率。 有一个很好的机会,实际上并没有什么好处,应该closures,特别是因为你也使用memcache。

好消息是,你是阅读而不是书面的,这意味着你可以通过caching相对容易地提高性能。 最糟糕的情况是,如果没有足够的可用RAM来增加key_buffer或memcached,并且无法扩展当前服务器,则可以将lighttpd和memcached移动到单独的附近服务器,并将整个〜8GB专用于MySQL。 有了10GB的数据集,这将是充足的。 为了提高性能,不需要求助于复制从服务器,尽pipe其他人提到这对于备份和故障转移有利的。

无论您是否可以减less开销,我都会build议将MySQl复制到辅助服务器。 使用一些负载均衡器,可以显着减less停机时间并减轻服务器的负担。 只是一个想法。 如果您需要关于设置复制的一些指导,请给我留言。

如果您的论坛的stream量与我在pipe理vBulletin中看到的stream量类似,那么您实际上应该为50-75%的请求调用PHP或MySQL(即,超过一半的请求来自未经authentication的“潜伏者”) 。

如果您还没有这样做,请考虑为未经身份validation的用户实施反向代理 – 除非您对vBulletin进行了一些严重的修改,否则未经validation的用户将无法看到任何dynamic内容。

更新:相关阅读: 如何将Nginx设置为caching逆向代理?

如果你有8GB的内存,你的mysql服务器的内存值看起来很小。 你的数据库和Web服务器在同一台主机上吗? 简单的解决scheme可能是设置第二个主机,并将Web和数据库服务分开(如果尚未安装)。

这是一个典型的SQL问题(不pipe是oracle,sql-server,mysql都无关紧要)。

数据库是绑定的。 经常需要大量快速光盘。 VPS通常不会让你知道你在这里。 如果你说“169GB光盘”那么问题是 – 你在这里有什么IO预算? 如果这是一个简单的光盘上的简单的小虚拟光盘,或RAID 5 …共享…便宜…欢迎来IO缓慢。 如果是在FAST光盘上,突袭10 ….这个问题。 此外,在这样的大小,你的服务器是非常“不寻常的”,因为它是小的。 10GB的数据库我会保持在内存(12-16GB的服务器内存只为数据库服务器)。 而6核和7GB则有点奇怪(对于如此多的内核来说,内存很小)。

要进行优化,您可以:

  • 分析SQL语句,尤其是那些花时间和大量IO。 不知道如何从MySQL获得这些信息(我主要是SQL服务器)。 玛贝有一些索引失踪? 9百万(!)的post并不是每个论坛都有的,所以它可能会遇到一个数据库优化问题,这对大多数人来说都不是问题。
  • 进行磁盘IO检查,找出磁盘IO预算有多糟糕。
  • 更改您的Mysql统计信息。 你引用的缓冲区对于10GB数据库来说非常小。 例如:tmp_table_size = 16M – 如果某个东西需要临时表,对于一个10GB的数据库来说可能太小了。 和所有其他项目一样 – 数据库不是1GB大,所以可能需要一些调整。
  • 检查http://mysqltuner.pl/mysqltuner.plbuild议,并考虑根据他们调整caching大小和tmp表
  • 浏览您访问最多的慢查询,并考虑优化(或避免)它们
  • 如果你使用SATA磁盘驱动器,迁移到更快的驱动器 – 例如SAS( 这很重要
  • 如果你只用2个磁盘驱动器使用raid1,试着在raid10中把它扩展到4
  • 如果在上述两种情况下受到预算的限制,考虑扩展可用内存,并将数据库放在内存中,并将其复制到第二台主机上(这是非常危险的,但是如果您能够承受最近丢失的数据崩溃,这不是你的业务的核心,它可以是一个选项)