私は現在、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)
メモリ(RAM)が不足しています。
1GBまたは2GBにアップグレードすると、大規模パフォーマンスが向上します。
コストが2倍または3倍になるように見えるので、他のVPSプロバイダーを検討することをお勧めします。
DrupalサイトにのみVPSを使用している場合は、Pleskのような本格的なコントロールパネルよりもAegirを実行した方がよい場合があります。リソースを節約できるかどうか、またはどれだけ節約できるかはわかりません。 、しかしそれは考慮する価値があるかもしれません。
Drupalを最適化する最良の方法に関する記事はかなりありますが、通常はかなりの量のRAMを投入する必要があります。 このコレクション は良いスタートです。ただし、最初に、必要のないモジュールを実行していないことを確認してください。
MySQLを別のサーバーに移動するかどうかを検討することもできます(ただし、データベースを非常に頻繁に使用する傾向があるため、Drupal)ではない可能性があります)。また、トラフィックのほとんどが匿名ユーザー向けである場合次に、キャッシングフォワードプロキシやmemcachedを実行するために追加のサーバーを取得することを検討する価値があるかもしれません。
ただし、このサーバーの追加メモリは、おそらく最も簡単で最良のソリューションです。 512Mbは、かなり大きなDrupalサイトを実行しているWeb/MySQLサーバーの組み合わせにはそれほど多くありません。
アップグレードすることで問題が解決する可能性が高いですが、必ずしも必要ではない場合があります。 Linuxにインストールすることに慣れている場合は、次のことができます。
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を介してサイトを移行します。