XenMobileの動作の調整
XenMobileの動作のパフォーマンスと安定性にはXenMobile全体にわたる多くの設定が関連しており、Citrix ADCとSQL Serverデータベースの構成によっても異なります。この記事では、XenMobileの調整と最適化に関連した代表的な構成を管理する設定に注目します。XenMobileを展開する前に、この記事の各設定を評価することをお勧めします。
重要:
これらのガイドラインでは、デバイス数に対してXenMobile ServerのCPUとRAMが適切であることを想定しています。スケーラビリティの詳細については、「スケーラビリティとパフォーマンス」を参照してください。
次のサーバープロパティは、XenMobileインスタンス全体の動作、ユーザー、およびデバイスにグローバルに適用されます。一部のサーバープロパティを変更すると、XenMobile Serverの各ノードの再起動が必要になります。再起動が必要なときにXenMobileによって通知されます。
これらの調整のガイドラインは、クラスター環境と非クラスター環境の両方に適用されます。
hibernate.c3p0.idle_test_period
この「カスタムキー」というXenMobileのサーバープロパティでは、接続が自動的に検証されるまでのアイドル時間を秒単位で指定します。このキーは次のように構成します。デフォルトは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
- 説明:データベースアイドルタイムアウト
プッシュサービスのハートビート間隔
この設定では、比例导引(苹果プッシュ通知サービス)通知が一時的に配信されない場合に,iOSデバイスでチェックする頻度を指定します。APNsのハートビートの頻度を増やすと、データベース通信が最適化される場合があります。値が大きすぎると、不必要な負荷が加わる場合があります。この設定は、iOSにのみ適用されます。デフォルトは20時間です。
ご使用の環境に多数のiOSデバイスがある場合、ハートビートの間隔により必要以上に負荷が高くなる場合があります。選択的なワイプ、ロック、完全なワイプなどのセキュリティ操作はこのハートビートに依存しません。これらの操作が実行されると、APNs通知がデバイスに送信されるためです。この値は、Active Directoryグループのメンバーシップが変更された後、ポリシーをどれだけ早く更新するかを管理します。そのため、多くの場合、負荷を軽減するにはこの値を12〜20時間に増やすのが適しています。
iOSMDM 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
データベースのクリーンアップ
重要:
テーブルに変更を加える前にデータベースをバックアップしてください。
次のクエリを実行して履歴データを確認します。
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;
上記の3つのテーブルからデータを削除します。
注:
履歴データがテーブルに表示されないことがあります。その場合は、その特定のテーブルでのTRUNCATEクエリの実行をスキップします。
truncate TABLE dbo.EWDEPLOY_HISTO; truncate TABLE dbo.EWSESS; truncate TABLE dbo.EWAUDIT;
デッドロックが発生したためにブロックされたSELECTクエリのブロックを解除します。この手順ではさらに、そのほかのデッドロックも処理されます。
ALTER DATABASE
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は、登録証明書を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;
次のクエリを使用して、孤立したファイルをクリアします。
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' );
検索効率が向上するように、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");