XenMobile®運用のチューニング

最終公開日 : Oct 21, 2026
XenMobileの運用におけるパフォーマンスと安定性には、XenMobile全体にわたる多くの設定が関係し、Citrix ADCおよびSQL Serverデータベースの構成に依存します。この記事では、XenMobileのチューニングと最適化に関連して、管理者が最も頻繁に構成する設定に焦点を当てています。Citrixは、XenMobileを展開する前に、この記事の各設定を評価することを推奨します。
重要:
これらのガイドラインは、XenMobile ServerのCPUとRAMがデバイス数に対して十分であることを前提としています。スケーラビリティの詳細については、「スケーラビリティとパフォーマンス」を参照してください。
次のサーバープロパティは、XenMobileインスタンス全体の運用、ユーザー、デバイスにグローバルに適用されます。一部のサーバープロパティを変更すると、各XenMobile Serverノードの再起動が必要です。XenMobileは、再起動が必要な場合に通知します。
これらのチューニングガイドラインは、クラスター環境と非クラスター環境の両方に適用されます。
Related information
XenMobile® の展開

hibernate.c3p0.idle\_test\_period

このXenMobile Serverプロパティ（カスタムキー）は、接続が自動的に検証されるまでのアイドル時間を秒単位で決定します。キーは次のように構成します。デフォルトは30です。
  • キー: カスタムキー
  • キー: hibernate.c3p0. idle\_test\_period
  • 値: 120
  • 表示名: hibernate.c3p0. idle\_test\_period
  • 説明: Hibernateアイドルテスト期間

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
  • 説明: SQLへのDB接続

hibernate.c3p0.min\_size

このカスタムキーは、XenMobileがSQL Serverデータベースに開く最小接続数を決定します。キーを次のように構成します。デフォルトは 100 です。
  • キー: hibernate.c3p0.min\_size
  • 値: 100
  • 表示名: hibernate.c3p0.min\_size
  • 説明: SQLへのDB接続

hibernate.c3p0.timeout

このカスタムキーはアイドルタイムアウトを決定します。データベースクラスターフェールオーバーを使用する場合、Citrixではこのカスタムキーを追加し、アイドルタイムアウトを短縮するように設定することをお勧めします。デフォルトは 120 です。
  • キー: カスタムキー
  • キー: hibernate.c3p0.timeout
  • 値: 120
  • 表示名: hibernate.c3p0.timeout
  • 説明: データベースアイドルタイムアウト

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

この設定は、iOSデバイスがAPNs通知がその間に配信されなかったかどうかをチェックする頻度を決定します。APNsハートビートの頻度を増やすと、データベース通信を最適化できます。値が大きすぎると、不要な負荷が増加する可能性があります。この設定はiOSにのみ適用されます。デフォルトは20時間です。
環境内に多数のiOSデバイスがある場合、ハートビート間隔は必要以上の負荷を引き起こす可能性があります。選択的ワイプ、ロック、完全ワイプなどのセキュリティアクションは、このハートビートに依存しません。その理由は、これらのアクションが実行されると、APNs通知がデバイスに送信されるためです。
この値は、Active Directoryグループメンバーシップの変更後にポリシーが更新される速度を制御します。そのため、負荷を軽減するために、この値を12時間から20時間の間で増やすことがよく適切です。

iOS MDM APNS接続プールサイズ

APNs接続プールが小さすぎると、100台を超えるデバイスがある場合にAPNsアクティビティのパフォーマンスに悪影響を及ぼす可能性があります。パフォーマンスの問題には、デバイスへのアプリとポリシーの展開の遅延、およびデバイス登録の遅延が含まれます。デフォルトは1です。約400台のデバイスごとにこの値を1ずつ増やすことをお勧めします。

auth.ldap.connect.timeout

LDAP応答の遅延を補うために、Citrixでは、以下のカスタムキーのサーバープロパティを追加することをお勧めします。
  • キー: カスタムキー
  • キー: auth.ldap.connect.timeout
  • 値: 60000
  • 表示名: auth.ldap.connect.timeout
  • 説明: LDAP接続タイムアウト

auth.ldap.read.timeout

低速なLDAP応答を補うため、Citrixは、以下のカスタムキーのサーバープロパティを追加することを推奨します。
  • キー: カスタムキー
  • キー: 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

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

重要:
テーブルに変更を加える前に、データベースをバックアップしてください。
  1. 履歴データを確認するには、次のクエリを実行します。
    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;
  2. 前述の3つのテーブルからデータを削除します。
    注:
    テーブルに履歴データが表示されない場合があります。その場合は、その特定のテーブルのtruncateクエリの実行をスキップしてください。
    truncate TABLE dbo.EWDEPLOY_HISTO;
    truncate TABLE dbo.EWSESS;
    truncate TABLE dbo.EWAUDIT;
  3. デッドロックが原因でブロックされていたSELECTクエリのブロックを解除します。この手順により、それ以上のデッドロックが処理されます。
    ALTER DATABASE <database_name> SET       READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE
  4. デフォルトでは、データベースのクリーンアップはセッション保持データと監査保持データを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テーブルから孤立したエントリをクリーンアップするには、次の手順を実行します。
重要:
テーブルに変更を加える前に、データベースをバックアップしてください。
  1. 履歴データを確認するには、次のクエリを実行します。
    select COUNT(*) from KEYSTORE
  2. 次のクエリを使用して、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;
  3. 次のクエリを使用して、孤立したエントリをクリアします。
    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'
        );
  4. 検索効率を向上させるために、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");