ColdFusion のパフォーマンスに関する問題とトラブルシューティング

パフォーマンスに関する問題は、Web アプリケーションの設計と実装を行う際に予想される最大の課題の 1 つです。パフォーマンスに関する問題でビジネスに混乱が生じる可能性があり、その結果として収益に短期的および長期的な損失をもたらすこともあります。

パフォーマンスに関する主な問題は、CPU 使用率の急増、Web サイトのクラッシュ、低速なリクエストの処理、メモリに関する問題(OutOFMemory、メモリリークなど)、エラー 503/サービス利用不能エラー、データベースクエリの実行中のパフォーマンスの低下、一部の Linux サーバー上の SecureRandom シードの生成、ネットワークレイテンシ、その他の類似問題などに分類できます。

ColdFusion は Java ベースのアプリケーションサーバーです。Java 関連の変更はいずれも ColdFusion に直接影響します。 Java 1.8 の導入により、ColdFusion は Java 1.8 向けに最適化しなければなりませんでした。最適化を行っても、ColdFusion サーバーでパフォーマンスが低下する可能性のあるパラメーターはほとんどありません。

CPU スパイク

CPU 使用率の急増(CPU スパイク)は、ユーザーが経験した最も一般的なパフォーマンスに関する問題です。通常、負荷とパフォーマンスのテストを行わないと、既存の CPU 使用率への影響を予測できません。CPU 使用率の急増は、次のような様々な理由で発生することがあります。

  • メモリ不足の問題
  • 過度のガベージコレクション
  • 低速のデータベースクエリ処理
  • ネットワークレイテンシ
  • Linux の乱数生成
  • セキュリティスキャナー

メモリ不足の問題

ColdFusion アプリケーションで CPU サージ/スパイクが発生した場合、ColdFusion ログをチェックして OutOfMemory エントリを確認します。さらに次の 2 つのシナリオが考えられます。

OutOfMemoryError: Heap

一般に OutOfMemory :ヒープ は、指定された上限値よりもアプリケーションの使用量が多いために発生する だけでなく、 ヒープ値が実際の使用量よりも低いために jvm 。

また、OutOfMemory の問題は、ガベージコレクタがメモリを要求できないために発生します。これは、古いオブジェクトや積極的な負荷に対して強い参照を行うために発生する可能性があります。そのため、GC をクリーンアップする前に OOM がスローされます。ColdFusion (2016年リリース)では、最大 JVM ヒープサイズのデフォルト値は 1GB です。

アプリケーションのメモリ使用量に基づいて、最大ヒープ値をアップデートします。ColdFusion Administrator または jvm .config (ColdFusionXXXX/instance_name/bin)でこの値を変更します。

OutOfMemoryError: Metaspace

1.8 (MaxMetaspaceSize) で新しいフラグを使用できます。これによりクラスメタデータに使用するネイティブメモリの量を制限できます。

メタスペースでは、クラスメタデータのほとんどの割り当てがネイティブメモリから割り当てることができます。デフォルトでは、クラスメタデータの割り当ては、使用可能なネイティブメモリの量によって制限されます。クラスメタデータの使用量が「MaxMetaspaceSize」に達すると、デッドクラスとクラスローダーのガベージコレクションがトリガーされます。

このようなガベージコレクションの頻度や遅延を制限するためには当然、Metaspace の適切な監視と調整が必要です。過度の Metaspace ガベージコレクションは、ご使用のアプリケーションに関するクラス、クラスローダのメモリリーク、不適切なサイジングの症状である可能性があります。このフラグを指定しないと、Metaspace は、実行時のアプリケーションの要求に応じて動的にサイズ変更されます。

過度のガベージコレクション

サーバー上の余分な負荷は、GC を増大させて、CPU スパイクを引き起こします。ガベージコレクタは、4 種類あります。 

ガベージコレクションの詳細は、
http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html を参照してください。

デフォルトでは、ColdFusion はパラレル GC を使用します。jvm.config (ColdFusionXXXX/instance_name/bin)でこの値を変更できます。

-XX:+UseConcMarkSweepGC
-XX:+UseParallelGC
-XX:+UseSerialGC
-XX:+UseG1GC - これは、ヒープサイズが大きい(少なくとも 4GB を超える)際に推奨されます。

メモリリークやメモリ不足エラーの詳細な調査については、ヒープダンプ解析が非常に有効です。ヒープダンプを取得するには、jvm.config (ColdFusionXXXX/instance_name/bin)で次の jvm 引数を追加します。
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath= <path_to_dump_file>

JDK がインストールされている場合は、\jdk\bin ディレクトリから次のコマンドを実行します。
jmap -dump:format=b,file=dump.hprof。ここで、pid は ColdFusion プロセス ID です。
Eclipse Memory Analyzer Tool (MAT)を使用して、ヒープダンプを確認できます。

低速のデータベースクエリ処理

ColdFusion ログ(アプリケーション、例外、エラーログ)には、クエリのタイムアウトの有無が示されることがあります。続いて、低速のクエリを特定して修正できます。

ColdFusion は、タイムアウト後に接続を閉じます。CF は、アイドル/閉じていない接続を再利用します。接続がまだクエリを実行中である場合を除いて、必要に応じて行います。クエリの実行に時間がかかりすぎる場合は、アプリケーションまたはデータベースのいずれかに問題が発生しています。必要に応じて、アイドル接続が再使用されます。

タイムアウトに関する技術的な詳細情報:
これについては、admin で 2 つのパラメータ(タイムアウトと間隔)を取得します。
CF は、間隔ごとに最大 5 つのタイムアウト接続を閉じます。例えば、タイムアウトが 10 に設定され、間隔が 5 に 設定されている オープン接続が 20 個ある場合、CF は以下を閉じます。

  • 5 分後に 0 個の接続
  • さらに 5 分後に 5 個の接続
  • さらに 5 分後にさらに 5 個の接続
  • さらに 5 分後にさらに 5 個の接続
  • さらに 5 分後にさらに 5 個の接続

したがって、すべての接続を閉じるには(上記の計算のとおり)、ColdFusion はすべてのオープン接続を閉じるのに少なくとも 25 分かかります。5 個のタイムアウト接続を閉じる最大制限は設定できません。これは仕様によるものです。

タイムアウトの最適化値は 5 に、間隔は 1 に設定できます。これらの値は、ご使用のアプリケーション要件に応じてさらに構成することができます。データとサービス/データソースの詳細設定で、CF 管理者のデータベースタイムアウト値を変更して、アイドル/閉じていない接続を最適化できます。

ネットワークレイテンシ

アプリケーションコードが常駐し、ColdFusion アプリケーションの共有ドライブからアクセスされる場合、ネットワークレイテンシが原因でリクエスト処理が遅くなり、パフォーマンス上の問題が生じる可能性があります。これは、サーバーのクラッシュや無応答を生じさせることさえあります。内部ネットワークのスループットのチェックをお勧めします。また、以下のブログにある情報も参照できます。

http://blogs.coldfusion.com/source-code-deployed-on-network-path-identifying-network-latency/

次をお試しください。
以下の jvm 引数を追加して、ネットワーク/ 共有場所 ディレクトリ cfm ページの処理速度を上げます。
-Dsun.io.useCanonPrefixCache=true -Dsun.io.useCanonCaches=true。

デフォルトのタイムアウトは 30 秒です

これで、ファイルの標準パスをキャッシュする標準キャッシュが有効になります。これは、WinNTFileSystem からの path の取得を待機するスレッドがたくさんある場合に役立ちます。ネットワークドライブからファイルにアクセスする際に、各「getCanonicalPath」は結局ネットワークにつながるため、非常に高価なタスクになります。このキャッシュを有効にするということは、同じファイルに対して、JVM がディスクに戻ってパスを見つけることは決してありません(キャッシュに入るときまで)。

Linux の乱数生成

一部のサーバー が Unix プラットフォーム上で乱数生成とサーバーの起動が遅くなります。これは、乱数生成に対して、Unix プラットフォーム上で /dev/random が使用されるためです。
java.security.SecureRandom は、暗号を安全にするように設計されています。

強固で安全な乱数を提供します。SecureRandom は、高品質のランダム性が重要で、CPU の消費価値がある場合に使用する必要があります。以下の jvm 引数を追加して、乱数生成によるパフォーマンス上の問題を解消できます。

-Djava.security.egd=file:/dev/./urandom

セキュリティスキャナー

日/週の特定の時刻に CPU スパイク が発生する場合は、サードパーティ製のセキュリティスキャナーが ColdFusion アプリケーションを妨害している可能性があります。スキャナーはサーバー監視ポート 5500 (デフォルト)を 0.0.0.0 でヒットすることで無限ループに入り、サーバークラッシュを引き起こします。

この問題を解決するには、ColdFusionXXXX\cfusion\lib の jetty.xml を修正する必要があります。サーバー監視用 IP アドレスを 0.0.0.0 から 127.0.0.1 に変更し、ColdFusion を再起動します。

コードキャッシュ:
プログラムに -XX:ReservedCodeCacheSize を介して設定されたハイコードキャッシュメモリがある場合、コードキャッシュフラッシングを無効にして制限できます。フラッシングが無効になっている場合、JIT はコーデックキャッシュが満杯になった後にメソッドをコンパイルしないため、CPU 使用率の急増は発生しません。以下の jvm 引数を追加できます。これは、コードキャッシュのフラッシュに使用できます。

XX:-UseCodeCacheFlushing
また、以下の引数を使用して階層化コンパイルを無効にすることもできます。
-XX:-TieredCompilation (Java 1.8 でのみ適用できます。バージョン 8 より前の Java バージョンでは、階層化コンパイルはデフォルトでは有効になっていません。

サービス利用不能エラー

503 - サービス利用不能は一般的なエラーです。このエラーが発生するたびに、まず、ColdFusion の起動および実行の有無を確認します。503 が断続的に発生する場合は、レスポンスの遅いサーバーを調査します(リクエストが撤回される可能性があります)。これは、長い GC の一時停止のため、または ColdFusion サーバーからの応答を遅らせるためと考えられます。ColdFusion コネクタの調整は、サービス利用不能エラーの解決に役立ちます。以下のブログ投稿は、ColdFusion コネクタの調整やそのようなエラーの回避に使用できます。

http://blogs.coldfusion.com/coldfusion-11-iis-connector-tuning/

また、特定のアップデートレベルの Java におけるバグが原因で発生する問題もあります。ColdFusion Java を最新バージョンにアップデートしておくことをお勧めします。以下のブログを使用して、Java を最新の状態に保ちます。

http://blogs.coldfusion.com/installing-and-troubleshooting-java-updates-in-coldfusion/

ColdFusion スレッドダンプ

ColdFusion スレッドダンプを使用して、New、Runnable、Blocked、Waiting、Timed_Waiting、および
Running スレッドを分析できます。
Thread race、Deadlock、Hang IO コール、GC/OutOfMemory 例外、Infinite Loop などの問題は、スレッドダンプを使用して判定できます。次のブログを使用して、ColdFusion サーバー上のスレッドダンプを取得できます。

http://blogs.coldfusion.com/taking-thread-dumps-from-coldfusion-server-programmatically/

ColdFusion 11 アップデート 12 および ColdFusion (2016年リリース)を使用している場合は、threaddump.jar のコピーをスキップできます。用途 takethreaddump . cfm ファイルを使用して、スレッドダンプを取得します。

1 つまたは 2 つの事例に別の問題が発生しました。XML 解析によってパフォーマンスに影響が出る場合は、以下の jvm 引数で修正できます。
-Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true

パフォーマンス上の問題のその他の原因には、以下があります。

  • 適切なデータベース SQL 調整とキャパシティ計画の欠如
  • アプリケーション固有のパフォーマンス上の問題
  • 適切なデータキャッシングの欠如
  • 過度のデータキャッシング
  • 過度のロギング

上記の手順で問題が解決しない場合は、アドビサポート(https://helpx.adobe.com/jp/support/coldfusion.html)に連絡して問題の分析と解決を依頼してください。

ヘルプをすばやく簡単に入手

新規ユーザーの場合

Adobe MAX 2025

Adobe MAX Japan
クリエイターの祭典

2025 年 2 月 13 日
東京ビッグサイト