☰

服务器性能调整

tag-icon • tag-icon performance lamp
服务器性能调整

我继承了一个系统，需要从硬件角度尽可能地调整其性能。首先，我是一名 Web 开发人员，而不是系统管理员，我不想过早地进行性能调整，因此在过去几天里，我做了一些研究，还设置了服务器和应用程序监控，并编写了如何改进的小计划，但我需要一个有经验的系统管理员来审查这一点。

我们这样做的原因是因为网站似乎很慢流量正在稳步增长。主要计划是重写系统，因为许多糟糕的架构决策，数据库本身，没有正确规范化。因此，在重写的同时，我们想做一些“愚蠢”/简单的扩展（如果可能的话），只是为了让客户满意。

我们当前的系统

  • 操作系统：CentOS 5 64位（Linux 2.6.18-238.12.1.el5）
  • 网络服务器：HP DL 320、Intel Xeon 四核 L5520 @ 2.26GHz CPU、8GB RAM、2 x 500 GB SATA 驱动器、RAID 控制器、冗余 PSU
  • MySQL5.0
  • PHP5.2.10
  • 阿帕奇2.2.3 使用 php_mod

服务器监控结果

我们正在运行单个服务器，它托管 Web 应用程序和数据库。

  • 每秒平均请求数~1.4，峰值~3 RPS
  • 磁盘 I/O 利用率，峰值为 25%（只有在运行某些后台任务时才会达到），除此之外约为 2-5%
  • 物理内存，峰值时使用率约为70％。

MySQL 配置

  • 我们目前正在使用 InnoDB 和 MyISAM 表的混合体
  • 查询缓存已关闭
  • innodb_buffer_pool_size = 8M
  • innodb_flush_method = (空)
  • innodb_log_file_size = 5M
  • innodb_thread_concurrency = 8

我并不关心 MyISAM 参数，因为我计划将所有表转换为 InnoDB，这样对我来说更容易调整。

我目前的计划

1. 系统监控

保持系统监控的薄弱，以便我们以后能够更清楚地了解性能调整是否成功。

2.分析应用程序监控

收集哪些页面加载时间最长的信息

3. 使用清漆

据我所知，Varnish 大致会缓存整个页面，并充当代理，稍后可以在没有 Apache 参与的情况下提供这些页面。在我们的案例中，我们有很多内容不会经常更改，尽管生成这些内容会消耗大量资源。

4. 使用自定义脚本进行基准测试

编写自定义脚本来模仿用户的行为，并尝试使用“贪婪”功能。当网站未被访问时，同时运行这些脚本并收集系统的性能信息。在网站优化之前和之后执行此操作。虽然这一点对我来说是有道理的，但我之前并没有听说过做这样的事情，只是在 Rails 基准测试中看到类似的想法，我想避免过早的基准测试，所以我很乐意听到一些关于这方面的意见。

5.将所有表转换为InnoDB

这将使所有调整过程变得更加简单。

6.数据库层调优

  • 打开查询缓存并将其设置为 256MB，然后使用以下公式不断测量缓存性能：Qcache_hits / Qcache_inserts x 100 = Your Query Cache's effectiveness.

  • 设置query_cache_limit= 256K

  • 创建一个每小时运行两次的 cron 作业并执行：FLUSH QUERY CACHE;
  • 我们正在使用 Sphinx，因此对于它的 SELECT 查询，我还将添加SQL_NO_CACHE，尽管query_cache_limit无论如何都应该阻止 Sphinx 破坏缓存。

7. 物理内存调优

这有点棘手，因为我们只有大约 3GB 的额外内存可以分配给 MySQL。在我们的例子中，Innodb TableSpaces 的总大小约为 3GB。以下文章：选择 innodb_buffer_pool_size建议将其innodb_buffer_pool_size设置为 InnoDB TableSpaces 总大小的 10% 以上，在我们的例子中是 3.1GB，所以我们没有足够的内存。然而给我们的服务器添加更多的物理内存不是问题。

除了innodb_buffer_pool_size调整之外，还应进行以下 MySQL 参数更改：

  • innodb_flush_method = O_DIRECT（避免双缓冲）
  • innodb_log_file_size = 256M

8. 页面生成时间调整

我遇到的大多数博客都建议使用 Nginx 和 APC（PHP 缓存）。我看过基准测试结果，与启用 mod_php 的 Apache 相比，它们似乎都令人印象深刻。但值得注意的是，在我们的案例中，我们在高峰时段的服务量为 3RPS。用 Nginx 更改 Apache 并不是一个简单的过程，坦率地说，如果需要，我宁愿让经验丰富的系统管理员来做这件事。也许有人可以提供一些建议，在我们的案例中是否值得迁移服务器？

有人能考虑到我的情况，就这个计划给我一些反馈吗？

谢谢！

答案1

您的总体计划是正确的。继续进行系统监控和页面速度分析前触摸任何东西。除非你知道问题出在哪里，否则你无法解决问题。

一旦您知道了您的瓶颈是什么（磁盘、CPU、RAM、数据库、WebApp），您就可以按照它们对用户的影响顺序开始定位它们。

在调优方面，你遗漏的一个具体项目是数据库分析（EXPLAIN修改查询并创建/修改索引以提高性能）。这是有经验的 DBA 的工作——创建太多索引会阻碍插入，而创建错误的索引则不会提高性能。

您还应该认真考虑拆分数据库服务器和 Web/应用程序服务器：两者都有相当困难的工作，将它们拆分可以避免一台主机过载。

如果我要执行上面概述的计划，我将按以下步骤进行：

  1. 监控和指标-- 识别问题
  2. 问题分析-- 数据库分析等
  3. 将表转换为 InnoDB（重复 1 和 2）
  4. 页面生成时间调整（重复 1 和 2）
  5. 物理内存调整以及额外的数据库层调优
    （不到绝对必要，我不会调整这些设置，而且我会先咨询有经验的 DBA）
  6. 缓存（清漆或同等物）。

除非您拥有开发环境或生产中的维护窗口（您不想让测试负载破坏您的生产环境），否则我不会使用自定义脚本进行基准测试。

相关内容