☰

我是否已经突破了当前 VPS 的极限或者还有优化的空间？

tag-icon • tag-icon apache-2.2 centos vps optimization mediatemple
我是否已经突破了当前 VPS 的极限或者还有优化的空间？

我目前使用的是 mediatemple DV 服务器（基本版）512mb 专用内存，这是基于 CentOS 的 VPS，带有 Plesk 和 Virtuozzo。从第一天开始，我的使用体验就很糟糕，我只能用几个缓存“创可贴”来缓解我的服务器问题，但我的网站也不像一年前那么小了，所以问题更加严重了。

我在不同的 (plesk) 域上运行了 3 个 Drupal 安装，其中 1 个 Drupal 安装是多站点，由 5-6 个站点组成，其中 2 个站点带来了实际流量。我提到的缓存“创可贴”是 APC，它最初似乎有很大帮助，还有 Drupal 的 Boost，它被认为是穷人的 Varnish，它使我的所有页面对匿名用户都是静态的。Google Ananlytics 上最近 30 天的综合估计：9 万访问者 26 万页面浏览量。

问题：停机时间很长，我不断检查我的网站是否正常运行，最近我发现它每天停机 3 次以上。重新启动 Apache 会让它恢复运行一段时间。我用谷歌搜索了每条错误消息，并查找了优化 DV 服务器的方法，但我不知道下一步该怎么做。这个服务器是否不好，我是否遇到了不可能达到的低限制，例如 12mb 内核内存屏障 (kmemsize)，这是否是我的问题，我是否需要进一步优化？

*我已在下面提供了尽可能多的信息，如有任何帮助或建议，我们将不胜感激

我在日志中看到的常见错误消息：

[error] (12)Cannot allocate memory: fork: Unable to fork new process
[error] make_obcallback: could not import mod_python.apache.\n
Traceback (most recent call last):
 File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 21, in ?
 import traceback
 File "/usr/lib/python2.4/traceback.py", line 3, in ?
 import linecache
 ImportError: No module named linecache
[error] python_handler: no interpreter callback found.
[warn-phpd] mmap cache can't open /var/www/vhosts/***/httpdocs/*** - Too many open files in system (pid ***)
[alert] Child 8125 returned a Fatal error... Apache is exiting!
[emerg] (43)Identifier removed: couldn't grab the accept mutex
[emerg] (22)Invalid argument: couldn't release the accept mutex

猫/ proc / user_beancounters：

Version: 2.5
       uid  resource           held    maxheld    barrier      limit    failcnt
     41548: kmemsize        4582652    5306699   12288832   13517715   21105036
            lockedpages           0          0        600        600          0
            privvmpages       38151      42676     229036     249036          0
            shmpages          16274      16274      17237      17237          2
            dummy                 0          0          0          0          0
            numproc              43         46        300        300          0
            physpages         27260      29528          0 2147483647          0
            vmguarpages           0          0     131072 2147483647          0
            oomguarpages      27270      29538     131072 2147483647          0
            numtcpsock           21         29        300        300          0
            numflock              8          8        480        528          0
            numpty                1          1         30         30          0
            numsiginfo            0          1       1024       1024          0
            tcpsndbuf        648440     675272    2867477    4096277    1711499
            tcprcvbuf        301620     359716    2867477    4096277          0
            othersockbuf       4472       4472    1433738    2662538          0
            dgramrcvbuf           0          0    1433738    1433738          0
            numothersock         12         12        300        300          0
            dcachesize            0          0    2684271    2764800          0
            numfile            3447       3496       6300       6300       3872
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            numiptent            14         14        200        200          0

顶部：（1 月份的平均负载非常高，为 3-10，我通过为 APC 提供更多内存将其降至当前水平）

top - 16:46:07 up  2:13,  1 user,  load average: 0.34, 0.20, 0.20
Tasks:  40 total,   2 running,  37 sleeping,   0 stopped,   1 zombie
Cpu(s):  0.3% us,  0.1% sy,  0.0% ni, 99.7% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    916144k total,   156668k used,   759476k free,        0k buffers
Swap:        0k total,        0k used,        0k free,        0k cached

MySQLTuner：（在优化了每个表并修复了所有超额的表之后，我将碎片数量降至 86）

[--] Data in MyISAM tables: 285M (Tables: 1105)
[!!] Total fragmented tables: 86

[--] Up for: 2h 44m 38s (409K q [41.421 qps], 6K conn, TX: 1B, RX: 174M)
[--] Reads / Writes: 79% / 21%
[--] Total buffers: 58.0M global + 2.7M per thread (100 max threads)
[!!] Query cache prunes per day: 675307
[!!] Temporary tables created on disk: 35% (7K on disk / 20K total)

答案1

你的内存（RAM）不足。

升级到 1 或 2 GB 应该会大量的性能提升。

这看起来会使您的成本增加一倍或三倍，因此您可能需要考虑其他 VPS 提供商。

答案2

如果您只将 VPS 用于 Drupal 网站，那么运行 Aegir 可能比使用 Plesk 等功能齐全的控制面板更好。不知道这是否能节省资源，或者能节省多少资源，但可能值得考虑。

有很多关于优化 Drupal 的最佳方法的文章，但它们通常需要投入大量内存。 本系列是一个好的开始。但首先，请确保您没有运行任何不需要的模块。

您可能还需要考虑是否将 MySQL 移至单独的服务器（尽管对于 Drupal 来说可能不是这样，因为它往往会大量使用数据库）。如果您的大部分流量来自匿名用户，那么可能值得考虑获取额外的服务器来运行缓存转发代理和/或 memcached。

但是在这个服务器上增加内存可能是最简单也是最好的解决方案。对于运行一些相当大的 Drupal 站点的组合 Web/MySQL 服务器来说，512Mb 并不多。

答案3

升级很可能会解决您的问题，但可能没有必要。如果您愿意在 Linux 中安装东西，您可以：

  • 使用以下代码覆盖 Drupal5 或 Drupal6 核心文件压力流- 优化发行版
  • 安装 Nginx 作为你的网络服务器（与 Drupal/Pressflow 配合良好，并具有缓存选项）
  • 在你的盒子顶部安装 Varnish，效果很好，但只适用于 Pressflow / Drupal 7
  • 放弃控制面板的（巨大）资源开销，使用 cli 或者更轻量级的

埃吉尔确实不错，但如果您允许其他人 (shell/ftp/php) 访问各个站点，则不太理想。在执行此操作之前，请先阅读相关内容。Omega8.cc 有一个“发行版”，可以从头构建 Aegir/Nginx，但它的方法相当激进，并安装了各种其他零碎的东西。我不建议这样做，请手动执行操作。

简而言之，与 Nginx/PHP-FPM/Aegir 相比，Plesk/Apache2 占用大量资源。如果将 Varnish-with-Pressflow 混合使用，内存占用会大大减少，同时速度也会大幅提升。Varnish 本身不会占用太多资源。

看到您使用 Virtuozo/Plesk，我猜您无法卸载控制面板。使用 Varnish 和/或 Nginx 并仅使用 Apache 作为后端可能仍然非常可行。但我不确定，我不是控制面板专家，而且您甚至可能无法更改 Web 服务器监听的端口。

您可以选择更自主的 VPS（如果可能的话，不要基于 Virtuozzo/OpenVZ），并尝试让 Nginx 等在此上运行。然后通过 Aegir 迁移您的网站。

相关内容