主页 / server / 问题 / 129944
In Process
J.Rameau
Asked: 2010-04-07 16:32:15 +0800 CST

我是否突破了当前 VPS 的极限，还是有优化空间？

  • 772

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

我有 3 个 Drupal 安装在单独的（plesk）域上运行，其中 1 个 drupal 安装是一个多站点，由 5-6 个站点组成，其中 2 个站点带来了实际流量。我提到的那些缓存“创可贴”是 APC，它最初似乎很有帮助，还有 Drupal 的 Boost，它被认为是穷人的 Varnish，它使我的所有页面对于匿名用户都是静态的。过去 30 天对 Google Analytics 的综合估计：90k 访问者 260k 网页浏览量。

问题：很多停机时间，我不断检查我的网站是否正常运行，最近我每天发现它超过 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

TOP：（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)
centos apache-2.2 optimization vps mediatemple

3 个回答

  1. 您的内存 (RAM) 不足。

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

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

    • 2

  2. 如果您仅将 VPS 用于 Drupal 站点，那么您最好运行 Aegir 而不是像 Plesk 这样的成熟控制面板。不知道这是否会节省资源或节省多少资源，但可能值得考虑。

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

    您可能还想考虑是否将 MySQL 移动到单独的服务器（尽管可能不适合 Drupal，因为它倾向于大量使用数据库）。如果您的大部分流量是针对匿名用户的，那么可能值得考虑使用额外的服务器来运行缓存转发代理和/或 memcached。

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

    • 1

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

    • 使用 Pressflow 覆盖您的 Drupal5 或 Drupal6 核心文件-优化发行版
    • 将 Nginx 安装为您的网络服务器（与 Drupal/Pressflow 配合使用非常好，并且具有缓存选项）
    • 在您的盒子顶部安装 Varnish，这非常有效，但仅适用于 Pressflow / Drupal 7
    • 放弃控制面板的（大）资源开销并使用 cli / 更轻的东西

    Aegir非常好，但如果您允许（shell/ftp/php）其他人访问各个站点，则不理想。在你这样做之前阅读它。Omega8.cc 有一个“发行版”，它从头开始构建 Aegir/Nginx，但它有一个非常激进的方法，并安装了各种其他零碎的东西。我不会建议它，手工做的东西。

    简而言之，与 Nginx/PHP-FPM/Aegir Throw Varnish-with-Pressflow 相比，Plesk/Apache2 是一种资源消耗型，您将拥有更小的内存使用量以及巨大的速度提升。Varnish 本身并不吃太多资源。

    看到您使用 Virtuozo/Plesk，我假设您无法卸载控制面板。使用 Varnish 和/或 Nginx 并简单地使用 Apache 作为后端可能仍然非常可行。但我不确定，我不是控制面板的人，很可能你甚至不能改变你的网络服务器监听的端口。

    您可以选择更多自己动手做的 VPS（如果可能的话，不要基于 Virtuozzo/OpenVZ）并尝试让 Nginx 等人致力于此。然后通过 Aegir 迁移您的站点。

    • 1

相关问题