web-dev-qa-db-ja.com

Drupal NFS共有ではひどいパフォーマンスがあります

Drupal 7サイトで、次の設定があります-WebVMとNFSVMを実行しているVMwareESXi4.1ホストサーバー。WebVMはApacheとmod_phpを使用しています。サイトはまだ開発中であるため、ファイルが頻繁に更新されるため、すべての形式のキャッシュをオフにする必要があります。

各ページリクエストは、完了するまでに約15〜20秒かかります。 PHPコードのプロファイリングは、モジュールをロードするすべてのis_dir（）、is_file（）関数呼び出しに大部分の時間（通常は90％以上）がかかっていることを示しています。

PHPのリアルパスキャッシュサイズを数メガバイトに増やしました。straceは、lstat呼び出しが200以上から約6に減少し、stat（）が少し減少することを示しています（約600呼び出し）。ただし、これによりかなりの時間が短縮されましたが、最も要求の厳しいページのリクエストごとの10秒の障壁を超えることはできません。

キャッシュを伴わないこのセットアップからパフォーマンスを向上させる方法はありますか？

編集：MySQLは問題ではありません。クエリのキャッシュとは、リクエストが完了するまでに最大で1秒かかることを意味します。

構成と統計：

VMホスト：シングルクアッドコアXeon CPU

VM：

web-Centos 6 64bt、2.5GB RAM、通常のCPU/HD優先度（2コア）nfs-Centos 6 64bt、2GB RAM、通常のCPU優先度（4コア）、高HD優先度

PHP：32Mのリアルパスキャッシュサイズ（テスト目的ではこれほど大きい）

NFS：

~]# egrep -v '#|^$' /etc/nfsmount.conf 
[ NFSMount_Global_Options ]
 Defaultvers=4
 Ac=False
 Rsize=32k
 Wsize=32k
 Bsize=32k

NFSを介した読み取り速度は、32kブロックを使用する100Mテストファイルのddの問題ではありません。

3200+0 records in
3200+0 records out
104857600 bytes (105 MB) copied, 1.84984 s, 56.7 MB/s

real    0m1.857s
user    0m0.007s
sys 0m0.330s

空のリアルパスキャッシュを使用したApacheプロセスのStrace：

    % time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 50.78    1.157452         337      3434        28 stat
 32.58    0.742656         628      1182       425 open
  9.29    0.211788         762       278         1 lstat
  3.17    0.072322           0    237865           write
  2.45    0.055839         490       114        13 access
  0.45    0.010262          43       237           brk
  0.34    0.007725          10       811        74 read
  0.28    0.006340           9       679           fstat
  0.22    0.005069          18       281           poll
  0.20    0.004533           6       698           getdents
  0.09    0.001960          10       190           mmap
  0.05    0.001065          14        74           accept4
  0.04    0.001000         333         3           chdir
  0.03    0.000750           4       190           munmap
  0.01    0.000339           0       836           close
  0.01    0.000247           3        75           writev
  0.00    0.000068           0       611           fcntl
  0.00    0.000063           1        77           shutdown
  0.00    0.000000           0         1           lseek
  0.00    0.000000           0         5           rt_sigaction
  0.00    0.000000           0         1           rt_sigprocmask
  0.00    0.000000           0         3           setitimer
  0.00    0.000000           0         5           socket
  0.00    0.000000           0         5         5 connect
  0.00    0.000000           0        74           getsockname
  0.00    0.000000           0        15           setsockopt
  0.00    0.000000           0         5           getcwd
  0.00    0.000000           0         1           futex
------ ----------- ----------- --------- --------- ----------------

リアルパスがキャッシュされた後のStrace

    % time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 60.14    1.371006         484      2831        28 stat
 31.79    0.724705         627      1155       425 open
  3.53    0.080354           0    237865           write
  2.65    0.060433         530       114        13 access
  0.43    0.009913          99       100           brk
  0.38    0.008730          11       804        74 read
  0.35    0.007910          12       675           fstat
  0.30    0.006775          10       654           getdents
  0.13    0.003065          11       281           poll
  0.09    0.002000         333         6         1 lstat
  0.07    0.001545           2       807           close
  0.05    0.001063          14        74           accept4
  0.04    0.001000           6       179           mmap
  0.02    0.000404           2       179           munmap
  0.01    0.000271           4        75           writev
  0.01    0.000212           0       611           fcntl
  0.01    0.000129           2        77           shutdown
  0.00    0.000022           0        74           getsockname
  0.00    0.000000           0         1           lseek
  0.00    0.000000           0         5           rt_sigaction
  0.00    0.000000           0         1           rt_sigprocmask
  0.00    0.000000           0         3           setitimer
  0.00    0.000000           0         3           socket
  0.00    0.000000           0         3         3 connect
  0.00    0.000000           0        15           setsockopt
  0.00    0.000000           0         5           getcwd
  0.00    0.000000           0         3           chdir
------ ----------- ----------- --------- --------- ----------------

マウント：

nfs.xxx.xxx.xxx:/path/to/website/files on /path/to/website/files type nfs (rw,hard,intr,noac,vers=4,addr=xx.xx.xx.xx,clientaddr=xx.xx.xx.xx)

当然のことながら、どんな助けでもありがたいです。

centosvmware-esxinfsdrupal
3
Marcus

率直に言って、NFSのDrupalは本物の豚です。せいぜい、NFSまたはglusterのようなものを介して「ファイル」ディレクター{y、ies}を共有したいと思います。 NFS上のDocRootは、合計すると、モジュールディレクトリに表示されるgetdents（2）やフレンドはもちろん、lstat（2）とaccess（2）の呼び出しはすべてキラーです。APCのようなものが非常に役立ちます。実際のread（2）時間、およびコンパイルの遅延は削除されますが、PHPはすべてのファイルに対してlstat（2）とaccess（2）を実行します。さらに高速化するには、 apc.stat = 0を設定できますが、あなたが言ったように、Apacheを再起動する（または手動でクリアする）場合を除いて、PHPファイルを絶えず変更している場合は、役に立ちません。このような変更を行うたびに、apc.phpを介したAPCキャッシュ）。

ベストプラクティスでは、DocRootを専用の最適化されたデバイス（SANなど）に保存するか、各Webヘッドに個別に保存することをお勧めします。 「files」ディレクトリは通常、gluster/nfs /etc。を介して共有する必要がありますが、代わりに、ユースケースやフロントのLBがスティッキーセッションをサポートするかどうかに応じて、サーバー間で定期的にrsyncすることもできます。 CDN、またはAmazonのS3やBlackMeshのSwiftなどのサービスを使用して、ファイルディレクトリを完全に削除することもできます。

Drupalの詳細で専門的な知識を持つホスティングプロバイダーは、これらのアーキテクチャ上の懸念のいくつかを支援できます。AcquiaまたはBlackMeshに連絡することをお勧めします（私は後者で働いています）。わかりません。 Acquiaがそうする場合でも、BlackMeshは、既存のホスティングプロバイダーまたはオンサイトホスティングと連携してDrupalのソリューションを最適化するオフサイト支援も提供していることを私は知っています。

あなたのサイトで頑張ってください！

1
BMDan

一般に、noacを使用してマウントすると、パフォーマンスが低下します。

なぜ使っているの？

編集：上記のコメントで、後でWebサーバーとロードバランサーを追加すると言っています。 BMDanが提案したように、アプリケーションでnoacを使用する必要がある場合は、クラスターファイルシステム（OCFS2など）を調べる必要があります。

乾杯

0
HTTP500