web-dev-qa-db-ja.com

現在のVPSの限界を押し上げましたか、それとも最適化の余地がありますか?

私は現在、mediatemple DVサーバー(基本)512mb専用RAMを使用しています。これは、PleskとVirtuozzoを備えたCentOSベースのVPSです。初日からの私の経験は悪く、いくつかのキャッシュ「バンドエイド」でサーバーの問題を解決することしかできませんでしたが、私のサイトも1年前ほど小さくないため、問題は悪化しています。

私は3つのDrupalインストールを別々の(plesk)ドメインで実行しています。そのうちの1つdrupalインストールはマルチサイトであり、そのうちの2つは5〜6サイトで構成されていますサイトは実際のトラフィックをもたらしています。私が言及したキャッシュ「バンドエイド」は、最初は大いに役立つと思われるAPCと、貧乏人のワニスと見なされるDrupal's Boostであり、匿名ユーザーに対してすべてのページを静的にします。過去30日間の合計Google Ananlyticsでの見積もり:9万人の訪問者26万人のページビュー。

問題:多くのダウンタイムがあり、サイトが稼働しているかどうかを継続的にチェックしています。最近、1日に3回以上ダウンタイムが発生しています。 Apacheを再起動すると、しばらくの間、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

cat/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)
4
J.Rameau

メモリ(RAM)が不足しています。

1GBまたは2GBにアップグレードすると、大規模パフォーマンスが向上します。

コストが2倍または3倍になるように見えるので、他のVPSプロバイダーを検討することをお勧めします。

2
LapTop006

DrupalサイトにのみVPSを使用している場合は、Pleskのような本格的なコントロールパネルよりもAegirを実行した方がよい場合があります。リソースを節約できるかどうか、またはどれだけ節約できるかはわかりません。 、しかしそれは考慮する価値があるかもしれません。

Drupalを最適化する最良の方法に関する記事はかなりありますが、通常はかなりの量のRAMを投入する必要があります。 このコレクション は良いスタートです。ただし、最初に、必要のないモジュールを実行していないことを確認してください。

MySQLを別のサーバーに移動するかどうかを検討することもできます(ただし、データベースを非常に頻繁に使用する傾向があるため、Drupal)ではない可能性があります)。また、トラフィックのほとんどが匿名ユーザー向けである場合次に、キャッシングフォワードプロキシやmemcachedを実行するために追加のサーバーを取得することを検討する価値があるかもしれません。

ただし、このサーバーの追加メモリは、おそらく最も簡単で最良のソリューションです。 512Mbは、かなり大きなDrupalサイトを実行しているWeb/MySQLサーバーの組み合わせにはそれほど多くありません。

1
WheresAlice

アップグレードすることで問題が解決する可能性が高いですが、必ずしも必要ではない場合があります。 Linuxにインストールすることに慣れている場合は、次のことができます。

  • drupal5またはDrupal6コアファイルを Pressflow -最適化されたディストリビューションで上書きします
  • nginxをWebサーバーとしてインストールします(Drupal/Pressflowでうまく機能し、キャッシュオプションがあります)
  • ボックスの上にワニスをインストールします。これは優れた機能を発揮しますが、Pressflow/Drupal 7
  • コントロールパネルの(大きな)リソースオーバーヘッドを捨てて、cli /何か軽いものを使用します

Aegir は本当に素晴らしいですが、他の人がさまざまなサイトへの(Shell/ftp/php)アクセスを許可する場合は理想的ではありません。そうする前にそれについて読んでください。 Aegir/Nginxをゼロから構築するOmega8.ccによる「配布」がありますが、それはかなり急進的なアプローチを持ち、他のあらゆる種類の断片をインストールします。私はそれをアドバイスしません、手で何かをします。

要するに、Plesk/Apache2は、Nginx/PHP-FPM/Aegir Throw Varnish-with-Pressflowと比較してリソースを大量に消費するため、メモリ使用量がはるかに少なくなり、速度が大幅に向上します。ニス自体は多くの資源を消費しません。

Virtuozo/Pleskを使用しているので、コントロールパネルをアンインストールできないと思います。 VarnishやNginxを使用し、単にバックエンドとしてApacheを使用することは、依然として非常に合理的である可能性があります。しかし、私はコントロールパネルの人ではないので、Webサーバーがリッスンするポートを変更することさえできない可能性があります。

より自作のVPSを選択して(可能であればVirtuozzo/OpenVZベースではない)、Nginx etalにその作業を依頼することができます。次に、Aegirを介してサイトを移行します。

1
Matt