Moodle 5.3 日本語ドキュメント(第一次翻訳):ほぼすべてのページが日本語に翻訳されました。まだ第一次翻訳のため、不自然な表現や誤訳が残っている可能性があります。お気づきの点があれば、ページコメントでお知らせいただくか、直接編集してください。スクリーンショットの多くは、まだ英語版の画面のままです。以前のバージョンの日本語ドキュメントは、バージョンメニューからご覧いただけます。
Moodle 5.3 Japanese documentation (first-pass translation): almost all pages have now been translated into Japanese. As this is a first pass, some wording may read unnaturally or be mistranslated. If you notice anything, please leave a page comment or edit the page directly. Most screenshots still show the English interface. Japanese documentation for earlier versions is available from the version menu.

パフォーマンスの推奨事項

提供: MoodleDocs
(Performance recommendationsから転送)
移動先:案内、検索

Moodleは、小規模な利用から数千人規模のユーザへの拡張まで、非常に高いパフォーマンスを発揮させることができます。パフォーマンスに関わる要因は、基本的に他のPHPベースのデータベース駆動型システムと同じです。サーバを最適化する際は、ユーザにとって最も大きな違いをもたらす要因に焦点を当ててください。たとえば、データベースにアクセスするユーザよりも閲覧しているユーザが相対的に多い場合は、ウェブサーバのパフォーマンスの改善に目を向けてください。

ベースラインベンチマークを取得する

最適化を試みる前に、改善しようとしているシステムのコンポーネントのベースラインベンチマークを取得してください。LinuxではLBS(注:最終更新2002年5月)を試し、Windowsではパフォーマンス モニターを使用してください。システムの現在のパフォーマンスに関する定量的なデータが得られれば、行った変更が実際に効果をもたらしたかどうかを判断できます。

パフォーマンス改善のための調整の全体的な目的は、RAM(キャッシング)を使用し、ディスクベースの処理を減らすことです。スワップファイルの使用をできる限りなくすよう努めることが特に重要です。システムがスワップを始めたら、それはRAMを増やす必要があるというサインです。

最適化の優先順位は通常、一次記憶装置(RAMの増設)、二次記憶装置(より高速なハードディスク / ハードディスク構成の改善)、プロセッサ(より多く、より高速に)の順です。

システムのボトルネックのうち特にMoodleに影響するものを見つけるために、Benchmarkプラグインをインストールして使用したり、JMeterのようなツールで負荷テスト / ストレステストを行ったりするのも興味深いでしょう。開発者ドキュメントのJMeterページを参照してください。

スケーラビリティ

Moodleの設計(アプリケーション層が明確に分離されています)により、高いスケーラビリティを持つ構成が可能です。(Moodleの大規模インストールの一覧を確認してください。)

大規模サイトでは通常、ウェブサーバとデータベースを別々のサーバに分けますが、小規模なインストールでは一般的にその必要はありません。

Moodleのインストールは、たとえば複数のウェブサーバを使用して負荷分散できます。個々のウェブサーバは同じデータベースに問い合わせ、同じファイルストアとキャッシュ領域(キャッシングを参照してください)を参照する必要がありますが、それ以外の点ではアプリケーション層の分離が十分に完全であるため、この種のクラスタリングが実現可能です。同様に、データベースをサーバのクラスタ(例:MySQLクラスタ)にすることもできますが、これは簡単な作業ではないため、Moodleパートナーなどの専門家のサポートを求めてください。

非常に大規模な負荷分散システムでは、共有コンポーネントのパフォーマンスが重要になります。共有ファイル領域を適切にチューニングし、効果的なキャッシュを使用することが重要です(Redisを強く推奨します)。システム管理のこれらの分野に関する十分な理解は、最低限の要件と考えるべきです。

サーバクラスタ

Using Moodleフォーラムのディスカッション:

ハードウェア構成

注:パフォーマンス改善のために行える最も迅速かつ効果的な変更は、ウェブサーバのRAMの量を増やすことです。できるだけ多く(例:4GB以上)搭載してください。一次メモリを増やすと、プロセスがディスクにスワップする必要が減り、サーバがより多くのユーザを処理できるようになります。

  • 入手できる中で最高のプロセッサ性能、すなわちデュアルプロセッサまたはデュアルコアプロセッサを使用すると、パフォーマンスが向上します。最近のBIOSではハイパースレッディングを有効にできるはずですが、CPUベンチマークツールを使用して、それがプロセッサ全体のパフォーマンスに違いをもたらすかどうかを確認してください。
  • 予算が許すなら、SATAドライブではなくSCSIハードディスクを使用してください。SATAドライブはシステムのCPU使用率を高めますが、SCSIドライブは独自の統合プロセッサを持ち、複数のドライブを使用する場合に真価を発揮します。SATAドライブを使用せざるを得ない場合は、マザーボードとドライブ自体がNCQ(Native Command Queuing)をサポートしていることを確認してください。
  • シークタイムの短いハードディスクを購入してください。これにより、特にMoodleのレポートにアクセスする際に、システム全体の速度が向上します。当然ながら、現在ではソリッドステートドライブ、特にエンタープライズグレードのSSDが、回転型メディアをはるかにしのぐ性能を持っています。
  • スワップファイルのサイズを正しく設定してください。一般的なアドバイスは、物理RAMの4倍に設定することです。
  • RAIDディスクシステムを使用してください。作成できるRAID構成はさまざまですが、一般的には次の構成が最適です:
    • (可能であれば)ハードウェアRAIDコントローラをインストールする
    • オペレーティングシステムとスワップドライブは、RAID-1として構成した1組のディスクに置く。
    • Moodle、ウェブサーバ、データベースサーバは、RAID-5として構成した別の1組のディスクに置く。
  • 'moodleData'領域を比較的低速なストレージ(例:NASデバイスへのNFSマウント)に置く場合、デフォルトのキャッシュ構成(このストレージに書き込みます)ではパフォーマンスの問題が発生します。キャッシングのページを参照して、代替手段を選択してください。Redisを推奨します。SANデバイスとファイバーチャネル上でGlusterFS / OCFS2 / GFS2を使用すると、パフォーマンスが向上する可能性があります(詳細はMoodleのフォーラムスレッド、NFSパフォーマンスチューニングを参照してください)
  • レイテンシとスループットを改善するためにギガビットイーサネットを使用してください。これは、ウェブサーバとデータベースサーバを別々のホストに分けている場合に特に重要です。
  • ネットワークカードの設定を確認してください。バッファと送受信ディスクリプタの使用を増やし(プロセッサとメモリのオーバーヘッドとのバランスを取ってください)、TCPチェックサムの計算をOSではなくカードにオフロードすることで、パフォーマンスが向上する場合があります。
  • 300人のユーザによるサーバのストレステストに関するこのケーススタディを読んでください。
  • ネットワークトラフィックとサーバ負荷に関するこの関連レポートも参照してください。
  • Educauseでの(VMWareを使用した)SFSUのプレゼンテーションも参照してください:[1]

オペレーティングシステム

  • サーバのオペレーティングシステムには、Linux(推奨)、Unixベース、Windows、Mac OS Xを使用できます。*nix系のオペレーティングシステムは、サーバがシェルインタフェースのみで構成されるため、同じタスクを行う場合でも一般的にMac OS XやWindowsのサーバより必要なメモリが少なくて済みます。さらにLinuxにはライセンス料がかかりませんが、他のオペレーティングシステムに慣れている場合は、習得に大きな労力が必要になることがあります。SMPで多数のプロセッサを稼働させている場合は、Solarisのような高度にチューニングされたOSの使用も検討するとよいでしょう。
  • 最適化の手順については、使用しているOSやベンダ固有の手順を確認してください。
    • Linuxの場合は、Linux Performance Teamのサイトを参照してください。
    • Linuxの場合は、hdparmコマンドを調べてください。たとえば、hdparm -m16 -d1を使用すると、複数セクタの読み書きとDMAを有効にできます。ディスクは「async」および「noatime」オプションを付けてマウントしてください。
    • Windowsの場合は、サーバをネットワークアプリケーション向けに最適化するよう設定してください(コントロール パネル、ネットワーク接続、ローカル エリア接続、プロパティ、Microsoft ネットワーク用ファイルとプリンター共有、プロパティ、最適化)。最適化に関するドキュメントをMicrosoft TechNetサイトで検索することもできます。

キャッシングのパフォーマンス

Moodleのキャッシングは、さまざまなキャッシュの多くでデフォルトでディスクを使用することがあり、全体としてかなり低速です。そのため、RedisやMemcachedのようなメモリキャッシュアプリケーションを使用してこれをRAMに移すことで、かなり確実な改善が得られます。実際、筆者らの(比較的小規模な)Moodleサイトで行った最大の改善はRedisのインストールだったと言ってもよいほどです。この効果は、SSDではなく従来型のハードドライブを使用している場合に増幅され、とりわけそれらが徐々に、しかし確実に故障し始めたとき(書き込みが遅いのにSMARTエラーも書き込みエラーも出ない、典型的な状態。とにかくものすごーーく遅い)に顕著です。

これらのアプリケーションは一部のデータベースクエリもキャッシュするため、クエリを再実行する必要がなくなり、この点でもパフォーマンスが向上します。筆者個人としては、セキュリティ機能が優れており、より新しく開発が進んでいるという理由から、MemcachedよりもRedisをお勧めします。特にRedisの詳細やインストール方法については、Redisキャッシュストアのページを参照してください。

ウェブサーバのパフォーマンス

最近のほとんどのウェブブラウザには、各ページコンポーネントの読み込みにかかる時間を確認できるインスペクタ機能があり、通常は「ネットワーク」タブにあります。また、Yslow拡張機能を使用すると、高速に読み込まれるウェブサイトのためのYahooの14のルール、全文Best Practices for Speeding Up Your Web Site、(動画)に照らしてページを評価できます。

PHPのパフォーマンス

  • PHPには組み込みのアクセラレータが含まれています(最近のバージョンのPHPでは、これはOpCacheです)。有効になっていることを確認してください。
  • キャッシュされたPHPページをTMPFSファイルシステムに置くと読み書きのパフォーマンスを改善できますが、停電やサーバの再起動時にはキャッシュの内容が失われることに注意してください。
  • PHPは(CGIではなく)Apache/IIS6 ISAPIモジュールとしてインストールした場合にパフォーマンスが向上します。IIS 7.0/7.5(Windows Server 2008/R2)のユーザは、最高のパフォーマンスを得るためにFastCGIでのインストールを選択してください。
  • php.iniのmemory_limitも確認してください。memory_limitディレクティブのデフォルト値は128Mです。サイトによっては、特に一部のバックアップ処理のために、これより大きくする必要があるかもしれません。
  • MoodleバージョンごとのPHP設定も参照してください。
  • (Apacheとともに)PHP-FPMを使用してください。

APC

Apacheのパフォーマンス

  • WindowsサーバでApacheを使用している場合は、Apache Loungeのビルドを使用してください。このビルドは、公式のApacheダウンロードと比べてパフォーマンスと安定性が改善されていると報告されています。なお、これは非公式ビルドのため、公式リリースに追随しない場合があります。
  • MaxRequestWorkersディレクティブ(Apache 2.4より前はMaxClients)を正しく設定してください。次の計算式を参考にしてください(予備の余裕を残すため、利用可能なメモリの80%を使用します):
MaxRequestWorkers = 利用可能な総メモリ * 80% / Apacheプロセスの最大メモリ使用量
Apacheプロセスのメモリ使用量は通常10MBですが、Moodleは1プロセスあたり最大100MBを簡単に使用することがあるため、一般的な目安として、利用可能なメモリをメガバイト単位で100で割ると、MaxClientsの控えめな設定値が得られます。Moodleサーバでは、MaxRequestWorkersをデフォルトの150から下げることになる可能性が高いでしょう。より正確な見積もりを得るには、次のシェルコマンドで値を読み取ってください:
#ps -ylC httpd --sort:rss
MaxRequestWorkersの値を256より大きくする必要がある場合は、ServerLimitディレクティブも設定する必要があります。
警告:利用可能なメモリを超える値をMaxRequestWorkersに設定したくなっても、そうしないでください。サーバが利用可能な量を超えるRAMを消費し、ディスクへのスワップを始めてしまいます。
  • 必要なメモリを減らすために、httpd.confファイルでApacheが読み込むモジュールの数を必要最小限に減らすことを検討してください。
  • 最新バージョンのApacheを使用してください。Apache 2ではメモリモデルが改善されており、メモリ使用量がさらに減少します。
  • Unix/Linuxシステムでは、httpd.confのMaxConnectionsPerChild(Apache 2.4より前はMaxRequestsPerChild)を20~30程度まで下げることを検討してください(これより低く設定すると、フォークのオーバーヘッドが利点を上回り始めます)。
  • 負荷の高いサーバでは、KeepAlive Offを設定する(Moodleページにリソースへのリンクやアップロードされた画像が含まれていない場合にのみ行ってください)か、KeepAliveTimeoutを2~5に下げることを検討してください。デフォルトは15(秒)で、値が大きいほど、アイドル状態かもしれない接続のために待機させられるサーバプロセスが多くなります。KeepAliveTimeoutのより正確な値は、ユーザがページをダウンロードするのにかかる時間を観察することで得られます。KeepAlive関連の変数を変更した後は、より多くのワーカープロセス / スレッドを起動するための追加のオーバーヘッドが発生する場合があるため、CPU使用率を監視してください。
  • KeepAlive Offを使用する代わりに、Moodleサーバの前段にリバースプロキシサーバを設置して、画像を含むHTMLファイルをキャッシュすることを検討してください。そうすれば、MoodleサーバのApacheでキープアライブを再び使用できます。
  • .htaccessファイルを使用しない場合は、AllowOverride変数をAllowOverride Noneに設定して、.htaccessの検索を防いでください。
  • コンテンツネゴシエーションを避けるため、DirectoryIndexを正しく設定してください。次は本番サーバでの例です:
DirectoryIndex index.php index.html index.htm
  • サーバ上で開発作業を行っているのでない限り、ExtendedStatus Offを設定し、mod_infoとmod_statusも無効にしてください。
  • DNSの遅延を減らすため、HostnameLookups Offのままにしてください(デフォルト)。
  • TimeOutの値を30~60(秒)に減らすことを検討してください。
  • Optionsディレクティブでは、ディレクトリスキャンを行うOptions Multiviewsを避けてください。ディスクI/Oをさらに減らすには、次を使用してください:
Options -Indexes FollowSymLinks
  • 圧縮によってHTTPレスポンスのサイズが小さくなり、応答時間が短縮されます
  1. mod_deflateをインストールして有効にします。ドキュメントまたはmanページを参照してください
  2. ルートディレクトリの<directory>セクション内の仮想サーバ設定ファイル(またはAllowOverridesがOnの場合は.htaccessファイル内)に、次のコードを追加します:
<ifModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml text/x-js text/javascript text/css application/javascript
</ifmodule>
  • Apacheのevent MPMを使用してください(デフォルトのPreforkやWorkerではなく)

IISのパフォーマンス

以下はすべて、レジストリの次の場所を変更します:

HKLM\SYSTEM\CurrentControlSet\Services\Inetinfo\Parameters\
  • KeepAliveTimeoutに相当するのはListenBackLogです(IIS - レジストリの場所はHKLM\ SYSTEM\ CurrentControlSet\ Services\ Inetinfo\ Parameters)。これを2~5に設定してください。
  • MemCacheSizeの値を変更して、IISがファイルキャッシュに使用するメモリ量(Mb)を調整します(デフォルトは利用可能なメモリの50%)。
  • MaxCachedFileSizeを変更して、ファイルキャッシュにキャッシュされるファイルの最大サイズをバイト単位で調整します。デフォルトは262,144(256K)です。
  • ObjectCacheTTLという新しいDWORDを作成して、キャッシュ内のオブジェクトがメモリに保持される時間(ミリ秒単位)を変更します。デフォルトは30,000ミリ秒(30秒)です。

OpenLiteSpeed

OpenLiteSpeedにはLSCacheという独自の組み込みキャッシュがあり、ウェブGUIから制御され、PHP OpCacheとも互換性があります。OpenLiteSpeedの最適化の詳細は、OpenLiteSpeedのページにあります。

Lighttpd、NginXおよびCherokeeのパフォーマンス

lighttpd、nginx、cherokeeのような軽量なウェブサーバを、FastCGIモードのPHPと組み合わせて使用することで、サーバのパフォーマンスを向上させることができます。LighttpdはもともとC10k問題に対処するための概念実証[2]として作成されたもので、主にメモリが限られたサーバに推奨されていますが、その設計の由来と非同期IOモデルにより、Moodleを含む高負荷のウェブサイトやウェブアプリに適した、実績のある[3]代替HTTPサーバとなっています。追加情報、設定例、リンクについては、MoodleDocsのLighttpdページを参照してください。

また、lighttpdとnginxはどちらも、ロードバランサおよび / またはリバースプロキシとして動作してバックエンドサーバの負荷を軽減でき[4]、既存のサーバで実際にソフトウェアを変更することなくメリットをもたらします。

なお、これらは、特にウェブサービスやMoodleネットワーキングなどの拡張機能を使用している場合、すべての中で最もテストされていないサーバ環境である可能性が高いことに注意してください。比較的シンプルな構成の、利用の多いMoodleサイトで検討するのが最適でしょう。

X-Sendfile

X-Sendfileモジュールは、Moodleから大きなファイルを送信する際のパフォーマンスを向上させます。利用可能な場合は、この機能を使用するようにウェブサーバとMoodleを設定することをお勧めします。

ウェブサーバを設定します:


config.phpでサポートを有効にします(config-dist.phpを参照してください):

//     $CFG->xsendfile = 'X-Sendfile';           // Apache {@see https://tn123.org/mod_xsendfile/}
//     $CFG->xsendfile = 'X-LIGHTTPD-send-file'; // Lighttpd {@see http://redmine.lighttpd.net/projects/lighttpd/wiki/X-LIGHTTPD-send-file}
//     $CFG->xsendfile = 'X-Accel-Redirect';     // Nginx {@see http://wiki.nginx.org/XSendfile}

サーバの実装で必要な場合は、ファイルの場所の接頭辞を設定します:

//     $CFG->xsendfilealiases = array(
//         '/dataroot/' => $CFG->dataroot,
//         '/cachedir/' => '/var/www/moodle/cache',    // for custom $CFG->cachedir locations
//         '/localcachedir/' => '/var/local/cache',    // for custom $CFG->localcachedir locations
//         '/tempdir/'  => '/var/www/moodle/temp',     // for custom $CFG->tempdir locations
//         '/filedir'   => '/var/www/moodle/filedir',  // for custom $CFG->filedir locations
//     );

cronのパフォーマンス

cronはMoodle全体のパフォーマンスにとって非常に重要な要素です。多くの非同期処理がcronにオフロードされるため、cronが稼働しており、フロントエンドから与えられる作業を処理できるだけのスループットを持っている必要があります。

UnixまたはLinuxでのcron#高パフォーマンスなcronタスクを参照してください。

データベースのパフォーマンス

MariaDBのパフォーマンス

MariaDBの最適化はMySQLと似ていますが、同時にMariaDBの動作の仕組みにより異なる点もあります。全体的なパフォーマンスは一般的にMySQLよりMariaDBの方が優れているため、データベースの最適化を検討している場合は、MySQLからMariaDBに切り替えることでパフォーマンスが向上する可能性があります。すでにMariaDBを使用していて最適化したい場合は、MariaDBのページでパフォーマンスの推奨事項を確認できます。

MySQLのパフォーマンス

MySQLのパフォーマンスを改善するためにできる最も重要なことは、Innodb Buffer Poolの記事にある推奨事項を読み、理解し、実施することです。

サーバに設定値を収容できるだけのメモリ(RAM)があれば、バッファプールサイズはサーバの稼働中でも安全に変更できます。MySQL専用のマシンでは、この値を利用可能なメモリの80%に安全に設定できます。

innodb_buffer_pool_instancesを、利用可能なコア、vCPU、またはチップの数に設定することを検討してください。この値は、MySQLドキュメントの推奨事項に従って調整してください。

以下は、パフォーマンス向上のためにmy.cnf(Windowsではmy.ini)で調整できるMySQL固有の設定です。このファイルには設定とその値の一覧が含まれています。現在の値を確認するには、次のコマンドを使用してください。

SHOW STATUS;
SHOW VARIABLES; 

重要:MySQLサーバの設定を変更する前に、必ずデータベースのバックアップを作成してください。my.cnfを変更した後は、mysqldを再起動してください。

可能であれば、MySQLTunerツールをMySQLサーバに対して実行すると、現在の負荷、ステータス、変数に基づいて、以下のほとんどの設定に適した構成値を自動的に計算してくれます。

  • 次の設定でクエリキャッシュを有効にします:
query_cache_type = 1. 

ほとんどのMoodleインストールでは、次のように設定してください:

query_cache_size = 36M 
query_cache_min_res_unit = 2K. 

クエリキャッシュは、データベースの更新が少ない場合にパフォーマンスを向上させます。

  • テーブルキャッシュを正しく設定してください。Moodle 1.6では次のように設定し、
table_cache = 256 #(table_open_cache in MySQL > 5.1.2)

(最小値)、Moodle 1.7では次のように設定します。

table_cache = 512 #(table_open_cache in MySQL > 5.1.2)

(最小値)。テーブルキャッシュはすべてのスレッド(接続)で使用されるため、opened_tablesの値を監視してさらに調整してください。opened_tables > 3 * table_cache(MySQL > 5.1.2ではtable_open_cache)の場合は、OSの上限までtable_cacheを増やしてください。また、table_cacheの値は、インストールしているモジュールとプラグインの数によっても変わることに注意してください。以下のMySQLステートメントを実行して、サーバに適した数値を確認してください。返された数値を確認し、table_cacheをこの値に設定してください。

mysql>SELECT COUNT(table_name) FROM information_schema.tables WHERE table_schema='yourmoodledbname';
  • スレッドキャッシュを正しく設定してください。次の計算式によるスレッドキャッシュ使用率ができるだけ100%に近づくように値を調整してください:
スレッドキャッシュ使用率 (%) = (threads_created / connections) * 100
  • キーバッファは、MoodleのSELECTクエリへのアクセス速度を改善できます。適切なサイズはインデックスファイル(.myi)のサイズに依存し、Moodle 1.6以降(追加のモジュールやプラグインなし)では、推奨値はkey_buffer_size = 32Mです。理想的には、データベースがディスクから読み取るのを100リクエストにつき1回にしたいところです。そのため、次の計算式が成り立つようにkey_buffer_sizeの値を調整して、その値がインストールに適しているかを監視してください:
key_read / key_read_requests < 0.01
key_write / key_write_requests <= 1.0
  • ユーザに「Too many connections」メッセージが表示されないように、最大接続数を設定してください。これが使用メモリの総量に影響する可能性があることに注意してください。MySQLの接続は通常数ミリ秒しか続かないため、負荷の高いサーバでもこの値が200を超えることはまれです。
  • 高負荷のバーストに対処してください。Moodleインストールで多くの小テストを使用していて、パフォーマンスの問題が発生している場合(threads_connectedの値を監視して確認してください。この値は増加し続けるべきではありません)は、back_logの値を増やすことを検討してください。
  • テーブルを毎週、およびMoodleのアップグレード後に最適化してください。大量のデータ削除作業を行った後、たとえば学期末や年度末にもテーブルを最適化するのがよい習慣です。これにより、インデックスファイルが最新の状態に保たれます。まずデータベースをバックアップしてから、次を使用してください:
mysql>CHECK TABLE mdl_tablename;
mysql>OPTIMIZE TABLE mdl_tablename;
確認すべきMoodleの一般的なテーブルは、mdl_course_sections、mdl_forum_posts、mdl_log、およびmdl_sessions(dbsessionsを使用している場合)です。エラーはREPAIR TABLEを使用して修正する必要があります(MySQLマニュアルおよびこのフォーラムのスクリプトを参照してください)。
  • キーの分布を維持してください。1か月に1回程度、MySQLサーバを停止して次のmyisamchkコマンドを実行するとよいでしょう。
#myisamchk -a -S /pathtomysql/data/moodledir/*.MYI
警告:myisamchkコマンドを実行する前に、必ずMySQLデータベースプロセス(mysqld)を停止してください。停止しないと、データが失われるおそれがあります。
  • ディスクに保存される一時テーブルの数を減らしてください。created_tmp_disk_tablesの値で確認します。この値が比較的大きい(>5%)場合は、減少が見られるまでtmp_table_sizeを増やしてください。これはRAMの使用量に影響することに注意してください。

PostgreSQLのパフォーマンス

PostgreSQLのチューニングについては優れた資料がいくつかあり(このページなど)、Moodleの場合も一般的な場合と違いはないようです。

まず認識すべきことは、本当にチューニングを気にする必要があるのであれば、データベースサーバには別のマシンを使用すべきだということです。別のマシンを使用していない場合、パフォーマンスに関する多くの疑問の答えは、アプリケーションの他の部分のメモリ要件によって大きく不明瞭になります。

何をしているのかよくわかっている場合を除き、おそらくautovacuumを有効にするべきです。多くのeラーニングサイトには予測可能な低利用期間があるため、autovacuumを無効にしてその時間帯に個別にvacuumを実行するのも良い選択肢です。あるいは、autovacuumは実行したままにして、利用の少ない時間帯に毎週フルvacuumを行うのもよいでしょう。

shared_buffersを適切な値に設定してください。バージョン8.1までは、筆者のテストではほぼ常にバッファ < 10000でピークパフォーマンスが得られたため、そのようなバージョンを使用していてRAMが512Mより多い場合は、shared_buffersを10,000(8MB)に設定するだけで十分です。

バッファ管理は8.2で大幅に見直され、「適切な」値は現在ではずっと大きな数値になっています。筆者は8.2でパフォーマンステストを行っていませんが、他の人々の推奨は一般的に、shared_buffersをメモリに応じてずっと大きくすべきであり、100,000(80MB)のような値まで上げても効果が得られ続ける可能性がある、というものです。システムRAMの1~2%を使用することを検討してください。

PostgreSQLは、オペレーティングシステムがそのファイルをキャッシュしていることも前提としているため、effective_cache_sizeを適切な値に設定することもお勧めです。適切な値は通常、(総RAM - プログラムが使用しているRAM)です。Linuxを使用していて、システムを1~2日稼働させたままにしておけば、「free」を見て「cached」列で現在の値を確認できます。その数値(kB単位)を10で割ることを検討してください(つまり、他のプログラムのキャッシュ用に20%を確保し、さらに8で割ってページ数を得ます)。専用のデータベースサーバを使用していない場合は、他のプログラムによる使用を考慮してこの値を減らす必要があります。

その他にも良い効果をもたらし得る有用なパラメータがいくつかあります。4GのRAMを搭載したマシンで筆者が通常設定する値は次のとおりです:

work_mem = 10240

これは、ディスク上でのソートなどの代わりに使用する10MのRAMです。速度が大幅に向上する可能性がありますが、接続ごとの値であり、200接続 * 10Mは2Gになるため、理論上は大量のRAMを消費する可能性があります。

maintenance_work_mem = 163840

これは、(たとえば)VACUUM、インデックスの再構築、クラスタ化などで使用される160MのRAMです。これは定期的にのみ使用され、それらのプロセスが終了すると解放されるはずなので、筆者は十分に価値があると考えています。

wal_buffers = 64

これらのバッファはライトアヘッドログに使用されます。PostgreSQLのメーリングリストでは、このレベルまで増やしたことによる改善が数多く報告されています。

これは現在では少し古くなっていますが(バージョン8.0)、それでも一読の価値があります: http://www.powerpostgresql.com/Docs

また、こちらにも役立つ情報がたくさんあります: http://www.varlena.com/GeneralBits/Tidbits/index.php

Tuning PostgreSQLフォーラムスレッドでのAndrew McMillanの投稿に基づいています。

  • mdl_logを複数のテーブルに分割し、UNIONを使用したVIEWでそれらを1つとして読み取ります(MoodleフォーラムでのTim Huntの説明を参照してください)。

リードレプリカ

Moodle 3.9以降では、可能な場合に使用されるリードレプリカを設定できます。非常に大規模なシステムでは、DB負荷の80~90%をプライマリから移すことができます。設定については、config-distを参照してください:

https://github.com/moodle/moodle/blob/master/config-dist.php#L84-L117

データベースのパフォーマンスに関するその他のリンク

さまざまなMoodleモジュールのパフォーマンス

Moodleの活動モジュール、フィルタ、その他のプラグインは有効化 / 無効化できます。必要に応じて、不要な機能(チャットなど)を無効にしてもかまいませんが、これは必須ではありません。以下は、特定のモジュールのパフォーマンスに関する注意点です:

  • チャットモジュールは、メインサーバへの頻繁なHTTPリクエストという点でリソースを大量に消費すると言われています。これは、モジュールでストリーム更新を使用するように設定するか、Unixベースのウェブサーバを使用している場合はチャットをデーモンモードで実行することで軽減できます。チャットモジュールを使用する場合は、設定を使用して想定される負荷に合わせてチューニングしてください。chat_old_pingおよびchat_refreshパラメータは、サーバ負荷に最も大きな影響を与える可能性があるため、特に注意してください。
  • Moodleのcronタスクは、スクリプトcron.phpを呼び出すことで起動されます。これを(例:wgetやcurlを使用して)HTTP経由で呼び出すと、大規模なインストールでは大量のメモリを消費する可能性があります。phpコマンドを直接実行して呼び出す場合(例:php -f /path/to/moodle/directory/admin/cli/cron.php)は、効率を大幅に改善できます。
  • 最近の活動ブロックは、mdl_logのレコード数が膨大な場合、リソースを過剰に消費します。SQLクエリを最適化するためのテストが行われています。
  • 小テストモジュールは、データベースのパフォーマンスに負担をかけることが知られています。ただし、最近のバージョンでは改善されてきており、最新の優れたパフォーマンス測定結果は把握していません。(こちらは300人の小テストユーザによる2007年のケーススタディです。)以下の提案は、このフォーラムスレッドでAl Rachelsが述べたものです:
    • Moodleとオペレーティングシステムの両方を必ずソリッドステートドライブにインストールしてください
    • PHP 7にアップグレードして使用してください
    • MySQLTunerを実行し、その推奨事項を実施してください

パフォーマンス関連のMoodle設定の詳細については、パフォーマンス設定を参照してください。

関連項目

moodle.orgではパフォーマンスについて多くのディスカッションが行われています。以下は、その中でも特に興味深く、(潜在的に)役立つものです: