高度なデータベース構成プロパティ
このページでは、Alfresco Content Services で使用しているデータベースの設定可能なプロパティについて記載します
概要
管理者は、データベース構成をカスタマイズするために、いくつかの詳細プロパティを編集する必要があります。ただし、多くのプロパティを編集する必要はありません。
一覧
Alfresco Content Services は、Oracle、Microsoft SQL Server、および MySQL と PostgreSQL をサポートしています。
高度なデータベース構成プロパティは、関連性に基づいて2つのグループに分類されます。
編集すべきプロパティ
編集できるプロパティ
次の表では、編集すべきプロパティについて説明します。
プロパティ名 | 説明 | デフォルト値 | |
|---|---|---|---|
| 1 | db.txn.isolation | java.sql.Connection クラスのコードに対応する、トランザクション分離レベルの JDBC コード番号。値 -1 は、データベースのデフォルトのトランザクション分離レベルを使用する必要があることを示します。Microsoft SQL Server JDBC ドライバーの場合、スナップショット分離を有効にするには、特別な値 4096 を使用する必要があります。 | -1 |
| 2 | db.pool.initial | プールの初期化時に開かれた接続の数。 | 10 |
| 3 | db.pool.validate.query | 接続がまだ存続していることを確認するために使用されるSQLクエリ。これは、非アクティブな状態が続いた後にデータベースが長時間実行されている接続を閉じる場合に役立ちます。 | Oracle データベースの場合は、SELECT 1 from dual。MySQL データベースの場合は、SELECT 1。SQL Server データベースの場合は、SELECT 1。PostgreSQL データベースの場合は、SELECT 1 |
次の表は、編集できるプロパティについて説明しています。
プロパティ名 | 説明 | デフォルト値 | |
|---|---|---|---|
| 1 | db.pool.statements.enable | ブールプロパティ。true に設定されている場合、接続で使用されるすべてのコンパイル済みステートメントが開いたままになり、再利用のためにキャッシュされることを示します。 | TRUE |
| 2 | db.pool.statements.max | 接続ごとにキャッシュする事前コンパイル済みステートメントの最大数。デフォルトは40です。Oracle では、デフォルトで50を超える数は許可されていません。 | 40 |
| 3 | db.pool.idle | 開いたまま使用されていない接続の最大数。 | 10 |
| 4 | db.pool.max | プール内の最大接続数。このプロパティの詳細については、以下の注を参照してください。 | 275 |
| 5 | db.pool.min | プール内の接続の最小数。 | 10 |
| 6 | db.pool.wait.max | 接続が使用できない場合に例外が生成される前に、接続が返されるのを待つ時間 (ミリ秒単位)。値0または-1は、例外が生成されないことを示します。 | 5000 |
| 7 | db.pool.validate.borrow | ブールプロパティ。true に設定されている場合、接続はプールから借用される前に検証されることを示します。 | TRUE |
| 8 | db.pool.validate.return | ブールプロパティ。true に設定されている場合、プールに返される前に接続が検証されることを示します。 | FALSE |
| 9 | db.pool.evict.interval | エビクションの実行間隔 (ミリ秒) を示します。このプロパティの値が0以下の場合、アイドル状態のオブジェクトはバックグラウンドで削除されません。 | 600000 |
| 10 | db.pool.evict.idle.min | 接続が追い出しの対象になる前にアイドル状態を維持できる最小ミリ秒数。 | 1800000 |
| 11 | db.pool.evict.validate | ブールプロパティ。true に設定されている場合、立ち退きの実行中にアイドル接続が検証されることを示します。 | FALSE |
| 12 | db.pool.abandoned.detect | ブールプロパティ。true に設定されている場合、接続が db.pool.abandoned.time よりも長い間アイドル状態であった場合、その接続は破棄され、削除の対象と見なされることを示します。 | FALSE |
| 13 | db.pool.abandoned.time | 放棄された接続が削除されるまでの秒数。 | 300 |
db.pool.max プロパティが最も重要です。デフォルトでは、各 Alfresco Content Services インスタンスは最大で 275 を使用するように構成されています。すべての操作にはデータベース接続が必要です。これにより、デフォルトで、すべてのプロトコルから単一のインスタンスが処理できる同時要求の量に厳しい上限 (つまり40) が設定されます。
ほとんどの Java アプリケーションサーバでは、同時アクセスのデフォルト設定が高くなっています (Tomcat では、デフォルトで最大 200 の同時 HTTP リクエストが許可されています)。これは、Alfresco Content Services の他のスレッド(非 HTTP プロトコルスレッド、バックグラウンドジョブなど) と相まって、すぐにデータベース接続の過剰な競合を引き起こし、ユーザのパフォーマンスの低下として現れます。
Alfresco Content Services をシングルユーザ評価モード以外で使用している場合は、データベース接続プールの最大サイズを少なくとも次の設定に増やします。
[アプリケーションサーバのワーカースレッドの数] + 75Tomcat のデフォルトの HTTP ワーカースレッド構成で、他のすべてのスレッドプールがデフォルトのままになっている場合、これはこのプロパティを少なくとも275に設定する必要があることを意味します。 データベース接続プールを増やすには、db.pool.max プロパティを alfresco-global.properties ファイルに追加し、それを推奨値の 275 に設定します。次に例を示します。
db.pool.max=275わかりやすくするために、このプロパティを他のデータベースプロパティの直後に追加します。
データベース接続プールのサイズを増やした後、データベースが処理できる同時接続数を少なくとも累積接続プールのサイズまで増やす必要があります。クラスタでは、各ノードに独自の独立したデータベース接続プールがあります。すべてのクラスターノードが同時に接続できるようにするには、十分なデータベース接続を構成する必要があります。Alfresco Content Services が独自の接続プールを飽和させた場合でもデータベースに接続できるようにするには、データベースへの接続をすべての接続プールで累積的に構成するよりも少なくとも10多い構成にすることをお勧めします。クラスタノード (それぞれ最大 275 のデータベース接続を使用できます) と、Alfresco Content Services と同じデータベースサーバを使用している他のアプリケーションが必要とする接続を考慮に入れてください。
データベースの接続制限を再構成するための正確なメカニズムは、使用しているリレーショナルデータベース製品によって異なります。構成の詳細については、自社の DBA にお問い合わせください。
参考: Advanced database configuration properties
なお、Alfresco Content Services 内ではその他にもデフォルトで次のプロパティが設定されています。
プロパティ名 | デフォルト値 | |
|---|---|---|
| 1 | db.schema.name |
|
| 2 | db.schema.stopAfterSchemaBootstrap |
|
| 3 | db.schema.update | TRUE |
| 4 | db.schema.update.lockRetryCount | 24 |
| 5 | db.schema.update.lockRetryWaitSeconds | 5 |
| 6 | db.driver | org.gjt.mm.mysql.Driver |
| 7 | db.name | alfresco |
| 8 | db.url | jdbc:mysql:///${db.name} |
| 9 | db.username | alfresco |
| 10 | db.password | alfresco |
| 11 | db.pool.evict.num.tests | -1 |
| 12 | db.pool.abandoned.log | FALSE |