XenMobile Server

XenMobileの動作の調整

March 15, 2024

寄稿者:

C C

XenMobileの動作のパフォーマンスと安定性にはXenMobile全体にわたる多くの設定が関連しており、Citrix ADCとSQL Serverデータベースの構成によっても異なります。この記事では、XenMobileの調整と最適化に関連した代表的な構成を管理する設定に注目します。XenMobileを展開する前に、この記事の各設定を評価することをお勧めします。

重要：

これらのガイドラインでは、デバイス数に対してXenMobile ServerのCPUとRAMが適切であることを想定しています。スケーラビリティの詳細については、「スケーラビリティとパフォーマンス」を参照してください。

次のサーバープロパティは、XenMobileインスタンス全体の動作、ユーザー、およびデバイスにグローバルに適用されます。一部のサーバープロパティを変更すると、XenMobile Serverの各ノードの再起動が必要になります。再起動が必要なときにXenMobileによって通知されます。

これらの調整のガイドラインは、クラスター環境と非クラスター環境の両方に適用されます。

hibernate.c3p0.idle_test_period

この「カスタムキー」というXenMobile Serverプロパティでは、接続が自動的に検証されるまでのアイドル時間を秒単位で指定します。このキーは次のように構成します。デフォルトは30です。

キー：カスタムキー
キー：hibernate.c3p0. idle_test_period
値：120
表示名：hibernate.c3p0. idle_test_period
説明：Hibernate idle test period

hibernate.c3p0.max_size

このカスタムキーでは、XenMobileでSQL Serverデータベースに対して開くことのできる最大接続数を指定します。XenMobileでは、このカスタムキーに指定した値が上限として使用されます。接続は必要な場合のみ開かれます。値は、データベースサーバーの処理能力に合わせて設定します。

クラスター構成では、次の式に注意してください。c3p0接続にノード数を掛けた値は、XenMobileがSQL Serverデータベースに対して開くことができる実際の最大接続数と等しくなります。

クラスター構成と非クラスター化構成では、小型のSQL Serverに対してこの設定値が大きすぎると、ピーク負荷時にSQL側でリソースの問題が発生する場合があります。設定値が小さすぎると、使用可能なSQLリソースを利用できなくなる場合があります。

このキーは次のように構成します。デフォルト値は1000です。

キー：hibernate.c3p0.max_size
値：1000
表示名：hibernate.c3p0.max_size
説明：DB connections to SQL

hibernate.c3p0.min_size

このカスタムキーでは、XenMobileがSQL Serverデータベースに対して開く最小接続数を指定します。このキーは次のように構成します。デフォルトは100です。

キー：hibernate.c3p0.min_size
値：100
表示名：hibernate.c3p0.min_size
説明：DB connections to SQL

hibernate.c3p0.timeout

このカスタムキーでは、アイドル状態のタイムアウトを指定します。データベースクラスターフェールオーバーを使用する場合は、このカスタムキーを追加し、アイドルタイムアウトの時間が短くなるように設定することをお勧めします。デフォルトは120です。

キー：カスタムキー
キー：hibernate.c3p0.timeout
値：120
表示名：hibernate.c3p0.timeout
説明：Database idle timeout

プッシュサービスのハートビート間隔

この設定では、APNs（Appleプッシュ通知サービス）通知が一時的に配信されない場合に、iOSデバイスでチェックする頻度を指定します。APNsのハートビートの頻度を増やすと、データベース通信が最適化される場合があります。値が大きすぎると、不必要な負荷が加わる場合があります。この設定は、iOSにのみ適用されます。デフォルトは20時間です。

ご使用の環境に多数のiOSデバイスがある場合、ハートビートの間隔により必要以上に負荷が高くなる場合があります。選択的なワイプ、ロック、完全なワイプなどのセキュリティ操作はこのハートビートに依存しません。これらの操作が実行されると、APNs通知がデバイスに送信されるためです。

この値は、Active Directoryグループのメンバーシップが変更された後、ポリシーをどれだけ早く更新するかを管理します。そのため、多くの場合、負荷を軽減するにはこの値を12〜20時間に増やすのが適しています。

iOS MDM APNS接続プールのサイズ

APNs接続プールが小さすぎると、100を超えるデバイスを使用する場合、APNsアクティビティのパフォーマンスに悪影響を及ぼすことがあります。パフォーマンスの問題としては、アプリやポリシーのデバイスへの展開が遅くなったり、デバイスの登録が遅くなったりするといった問題があります。デフォルトは1です。デバイスが約400台が追加されるごとに、この値を1増やすことをお勧めします。

auth.ldap.connect.timeout

LDAPの反応が遅い場合に対処するには、次のカスタムキーのサーバープロパティを追加することをお勧めします。

キー：カスタムキー
キー：auth.ldap.connect.timeout
値：60000
表示名：auth.ldap.connect.timeout
説明：LDAP接続のタイムアウト

auth.ldap.read.timeout

LDAPの反応が遅い場合に対処するには、次のカスタムキーのサーバープロパティを追加することをお勧めします。

キー：カスタムキー
キー：auth.ldap.read.timeout
値：60000
表示名：auth.ldap.read.timeout
説明：LDAP読み取りのタイムアウト

その他のサーバーの最適化


サーバープロパティ	デフォルト設定	この設定を変更する理由
バックグラウンド展開	1,440分	バックグラウンドポリシーの展開の頻度（分）。Androidデバイスの常時接続にのみ適用されます。ポリシー展開の頻度を増やすと、サーバーの負荷が軽減されます。推奨の設定値は 1440（24時間）です。
バックグラウンドハードウェアインベントリ	1,440分	バックグラウンドハードウェアインベントリの頻度（分）。Androidデバイスの常時接続にのみ適用されます。ハードウェアインベントリの頻度を増やすと、サーバーの負荷が軽減されます。推奨の設定値は 1440（24時間）です。
削除されたActive Directoryユーザーのチェック間隔	15分	Active Directoryの標準同期時間は15分です。値0を指定すると、XenMobileは削除されたActive Directoryユーザーをチェックしません。推奨の設定値は15分です。
MaxNumberOfWorker	3	多数の一括購入ライセンスをインポートするときに使用するスレッド数です。デフォルトは3です。さらに最適化が必要な場合は、スレッド数を増やすことができます。ただし、スレッド数を大きくする（6など）と、一括購入ライセンスのインポートによりCPU使用率が非常に高くなります。

SQL DB内のデッドロックをチェックし、履歴データを削除する方法

デッドロックが発生したら、次のクエリを実行してデッドロックを確認してください。その後、データベース管理者またはMicrosoft SQLチームがその情報を確認できます。

SQLクエリ

SELECT

db.name DB_Service,

tl.request_session_id,

wt.blocking_session_id,

OBJECT_NAME(p.OBJECT_ID) BlockedObjectName,

tl.resource_type,

h1.TEXT AS RequestingText,

h2.TEXT AS BlockingTest,

tl.request_mode

FROM sys.dm_tran_locks AS tl

INNER JOIN sys.databases db ON db.database_id = tl.resource_database_id

INNER JOIN sys.dm_os_waiting_tasks AS wt ON tl.lock_owner_address = wt.resource_address

INNER JOIN sys.partitions AS p ON p.hobt_id = tl.resource_associated_entity_id

INNER JOIN sys.dm_exec_connections ec1 ON ec1.session_id = tl.request_session_id

INNER JOIN sys.dm_exec_connections ec2 ON ec2.session_id = wt.blocking_session_id

CROSS APPLY sys.dm_exec_sql_text(ec1.most_recent_sql_handle) AS h1

CROSS APPLY sys.dm_exec_sql_text(ec2.most_recent_sql_handle) AS h2

GO
<!--NeedCopy-->

データベースのクリーンアップ

重要：

テーブルに変更を加える前にデータベースをバックアップしてください。

次のクエリを実行して履歴データを確認します。

select COUNT(*) as total_record from dbo.EWDEPLOY_HISTO;
select COUNT(*) as total_record from dbo.EWSESS;
select COUNT(*) as total_record from dbo.EWAUDIT;
<!--NeedCopy-->

上記の3つのテーブルからデータを削除します。

注：

履歴データがテーブルに表示されないことがあります。その場合は、その特定のテーブルでのTRUNCATEクエリの実行をスキップします。
```
truncate TABLE dbo.EWDEPLOY_HISTO;
truncate TABLE dbo.EWSESS;
truncate TABLE dbo.EWAUDIT;

```
デッドロックが発生したためにブロックされたSELECTクエリのブロックを解除します。この手順ではさらに、そのほかのデッドロックも処理されます。
```
ALTER DATABASE <database_name> SET       READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE

```
デフォルトのデータベースクリーンアップ設定では、セッションおよび監査ログの保持データは7日間保持されます。これは、多くのユーザーにとって長すぎます。そのため、クリーンアップ値を1日または2日に変更します。サーバープロパティで、次の変更を行います：
```
zdm.dbcleanup.sessionRetentionTimeInDays = 1 day
zdm.dbcleanup.deployHistRetentionTimeInDays = 1 day
zdm.dbcleanup.auditRetentionTimeInDays=1 day

```

KEYSTOREテーブルの孤立したファイルのクリーンアップ

XenMobileノードのパフォーマンスが低い場合は、KEYSTOREテーブルが大きすぎないかを確認します。XenMobile Serverは、登録証明書をENROLLMENT_CERTIFICATEテーブルおよびKEYSTOREテーブルに保存します。デバイスを削除または再登録すると、証明書がENROLLMENT_CERTIFICATEテーブルから削除されます。一方、KEYSTOREテーブルのエントリは保持され、パフォーマンスの問題を引き起こす可能性があります。次の手順を実行して、KEYSTOREテーブルの孤立したファイルをクリーンアップします。

重要：

テーブルに変更を加える前にデータベースをバックアップしてください。

次のクエリを実行して履歴データを確認します。
```
select COUNT(*) from KEYSTORE

```

次のクエリを使用して、KEYSTOREテーブル内で孤立したファイルを確認します。

WITH cte(KEYSTORE_ID)
AS (SELECT KEYSTORE_ID
    FROM ENROLLMENT_CERTIFICATE
    UNION
    SELECT CA_KEYSTORE_ID
    FROM LDAP_CONFIG
    UNION
    SELECT CLIENT_KEYSTORE_ID
    FROM LDAP_CONFIG
    UNION
    SELECT KEYSTORE_ID
    FROM SAML_SERVICE_PROVIDER
    UNION
    SELECT KEYSTORE_ID
    FROM SERVER_CERTIFICATE)
SELECT keystore.id
FROM keystore
    LEFT JOIN cte ON keystore.id = cte.KEYSTORE_ID
WHERE KEYSTORE_ID IS NULL;
<!--NeedCopy-->

次のクエリを使用して、孤立したファイルをクリアします。

WITH cte(KEYSTORE_ID)
    AS (SELECT KEYSTORE_ID
        FROM ENROLLMENT_CERTIFICATE
        UNION
        SELECT CA_KEYSTORE_ID
        FROM LDAP_CONFIG
        UNION
        SELECT CLIENT_KEYSTORE_ID
        FROM LDAP_CONFIG
        UNION
        SELECT KEYSTORE_ID
        FROM SAML_SERVICE_PROVIDER
        UNION
        SELECT KEYSTORE_ID
        FROM SERVER_CERTIFICATE)
    DELETE FROM keystore
    WHERE id IN
    (
        SELECT keystore.id
        FROM keystore
            LEFT JOIN cte ON keystore.id = cte.KEYSTORE_ID
        WHERE KEYSTORE_ID IS NULL AND keystore.TYPE = 'X_509'
    );
<!--NeedCopy-->

検索効率が向上するように、KEYSTOREテーブルにインデックスを追加します。

DROP INDEX "KEYSTORE_NAME_IDX" ON "KEYSTORE";
ALTER TABLE "KEYSTORE" ALTER COLUMN "NAME" NVARCHAR(255) NULL;
CREATE INDEX "KEYSTORE_NAME_IDX" ON "KEYSTORE"("NAME") INCLUDE ("ID", "TYPE", "CONTENT", "PASSWORD", "PUBLICLY_TRUSTED", "DESCRIPTION", "ALIAS", "MODIFICATION_DATE");
<!--NeedCopy-->

このコンテンツの正式なバージョンは英語で提供されています。Cloud Software Groupドキュメントのコンテンツの一部は、お客様の利便性のみを目的として機械翻訳されています。Cloud Software Groupは機械翻訳されたコンテンツを管理していないため、誤り、不正確な情報、不適切な用語が含まれる場合があります。英語の原文から他言語への翻訳について、精度、信頼性、適合性、正確性、またはお使いのCloud Software Group製品またはサービスと機械翻訳されたコンテンツとの整合性に関する保証、該当するライセンス契約書またはサービス利用規約、あるいはCloud Software Groupとのその他すべての契約に基づき提供される保証、および製品またはサービスのドキュメントとの一致に関する保証は、明示的か黙示的かを問わず、かかるドキュメントの機械翻訳された範囲には適用されないものとします。機械翻訳されたコンテンツの使用に起因する損害または問題について、Cloud Software Groupは責任を負わないものとします。

この情報は役に立ちましたか?

XenMobileの動作の調整

March 15, 2024

寄稿者:

C C

March 15, 2024

寄稿者:

C C

この情報は役に立ちましたか?

XenMobileの動作の調整

hibernate.c3p0.idle_test_period

hibernate.c3p0.max_size

hibernate.c3p0.min_size

hibernate.c3p0.timeout

プッシュ サービスのハートビート間隔

iOS MDM APNS接続プールのサイズ

auth.ldap.connect.timeout

auth.ldap.read.timeout

その他のサーバーの最適化

SQL DB内のデッドロックをチェックし、履歴データを削除する方法

SQLクエリ

データベースのクリーンアップ

KEYSTOREテーブルの孤立したファイルのクリーンアップ

この記事の概要

プッシュサービスのハートビート間隔