XenMobile® Server

Optimierung von XenMobile®-Operationen

Die Leistung und Stabilität von XenMobile-Operationen hängt von vielen Einstellungen innerhalb von XenMobile sowie von Ihrer Citrix ADC- und SQL Server-Datenbankkonfiguration ab. Dieser Artikel konzentriert sich auf die Einstellungen, die Administratoren am häufigsten konfigurieren, im Zusammenhang mit der Abstimmung und Optimierung von XenMobile. Citrix empfiehlt, jede der Einstellungen in diesem Artikel vor der Bereitstellung von XenMobile zu bewerten.

Wichtig:

Diese Richtlinien setzen voraus, dass CPU und RAM des XenMobile Servers für die Anzahl der Geräte ausreichend sind. Weitere Informationen zur Skalierbarkeit finden Sie unter Skalierbarkeit und Leistung.

Die folgenden Servereigenschaften gelten global für Operationen, Benutzer und Geräte in einer gesamten XenMobile-Instanz. Eine Änderung einiger Servereigenschaften erfordert einen Neustart jedes XenMobile Server-Knotens. XenMobile benachrichtigt Sie, wenn ein Neustart erforderlich ist.

Diese Optimierungsrichtlinien gelten sowohl für Cluster- als auch für Nicht-Cluster-Umgebungen.

hibernate.c3p0.idle_test_period

Diese XenMobile Server-Eigenschaft, ein benutzerdefinierter Schlüssel, bestimmt die Leerlaufzeit in Sekunden, bevor eine Verbindung automatisch validiert wird. Konfigurieren Sie den Schlüssel wie folgt. Der Standardwert ist 30.

  • Schlüssel: Benutzerdefinierter Schlüssel
  • Schlüssel: hibernate.c3p0. idle_test_period
  • Wert: 120
  • Anzeigename: hibernate.c3p0. idle_test_period
  • Beschreibung: Hibernate idle test period

hibernate.c3p0.max_size

Dieser benutzerdefinierte Schlüssel bestimmt die maximale Anzahl von Verbindungen, die XenMobile zur SQL Server-Datenbank öffnen kann. XenMobile verwendet den von Ihnen für diesen benutzerdefinierten Schlüssel angegebenen Wert als Obergrenze. Die Verbindungen werden nur bei Bedarf geöffnet. Basieren Sie Ihre Einstellungen auf der Kapazität Ihres Datenbankservers.

Beachten Sie die folgende Gleichung in einer Clusterkonfiguration. Ihre c3p0-Verbindung multipliziert mit der Anzahl der Knoten ergibt die tatsächliche maximale Anzahl von Verbindungen, die XenMobile zur SQL Server-Datenbank öffnen kann.

In Cluster- und Nicht-Cluster-Konfigurationen kann ein zu hoher Wert bei einem unterdimensionierten SQL Server zu Ressourcenproblemen auf der SQL-Seite während der Spitzenlast führen. Ein zu niedriger Wert bedeutet, dass Sie die verfügbaren SQL-Ressourcen möglicherweise nicht nutzen können.

Konfigurieren Sie den Schlüssel wie folgt. Der Standardwert ist 1000.

  • Schlüssel: hibernate.c3p0.max_size
  • Wert: 1000
  • Anzeigename: hibernate.c3p0.max_size
  • Beschreibung: DB-Verbindungen zu SQL

hibernate.c3p0.min_size

Dieser benutzerdefinierte Schlüssel bestimmt die minimale Anzahl von Verbindungen, die XenMobile zur SQL Server-Datenbank öffnet. Konfigurieren Sie den Schlüssel wie folgt. Der Standardwert ist 100.

  • Schlüssel: hibernate.c3p0.min_size
  • Wert: 100
  • Anzeigename: hibernate.c3p0.min_size
  • Beschreibung: DB-Verbindungen zu SQL

hibernate.c3p0.timeout

Dieser benutzerdefinierte Schlüssel bestimmt das Leerlauf-Timeout. Wenn Sie ein Datenbank-Cluster-Failover verwenden, empfiehlt Citrix, diesen benutzerdefinierten Schlüssel hinzuzufügen und ihn so einzustellen, dass das Leerlauf-Timeout reduziert wird. Der Standardwert ist 120.

  • Schlüssel: Benutzerdefinierter Schlüssel
  • Schlüssel: hibernate.c3p0.timeout
  • Wert: 120
  • Anzeigename: hibernate.c3p0.timeout
  • Beschreibung: Datenbank-Leerlauf-Timeout

Push Services Heartbeat Interval

Diese Einstellung bestimmt, wie häufig ein iOS-Gerät prüft, ob eine APNs-Benachrichtigung in der Zwischenzeit nicht zugestellt wurde. Eine Erhöhung der APNs-Heartbeat-Frequenz kann die Datenbankkommunikation optimieren. Ein zu großer Wert kann unnötige Last verursachen. Diese Einstellung gilt nur für iOS. Der Standardwert ist 20 Stunden.

Wenn Sie viele iOS-Geräte in Ihrer Umgebung haben, kann das Heartbeat-Intervall zu einer höheren als der notwendigen Last führen. Sicherheitsaktionen wie selektives Löschen, Sperren und vollständiges Löschen sind nicht auf diesen Heartbeat angewiesen. Der Grund dafür ist, dass eine APNs-Benachrichtigung an das Gerät gesendet wird, wenn diese Aktionen ausgeführt werden.

Dieser Wert steuert, wie schnell eine Richtlinienaktualisierung nach Änderungen der Active Directory-Gruppenmitgliedschaft erfolgt. Daher ist es oft ratsam, diesen Wert auf 12 bis 20 Stunden zu erhöhen, um die Last zu reduzieren.

iOS MDM APNS-Verbindungspoolgröße

Ein zu kleiner APNs-Verbindungspool kann die Leistung der APNs-Aktivität negativ beeinflussen, wenn Sie mehr als 100 Geräte haben. Leistungsprobleme umfassen eine langsamere Bereitstellung von Apps und Richtlinien auf Geräten und eine langsamere Geräteregistrierung. Der Standardwert ist 1. Wir empfehlen, diesen Wert für etwa alle 400 Geräte um 1 zu erhöhen.

auth.ldap.connect.timeout

Um langsame LDAP-Antworten zu kompensieren, empfiehlt Citrix, Servereigenschaften für den folgenden benutzerdefinierten Schlüssel hinzuzufügen.

  • Schlüssel: Benutzerdefinierter Schlüssel
  • Schlüssel: auth.ldap.connect.timeout
  • Wert: 60000
  • Anzeigename: auth.ldap.connect.timeout
  • Beschreibung: LDAP-Verbindungs-Timeout

auth.ldap.read.timeout

Um langsame LDAP-Antworten zu kompensieren, empfiehlt Citrix, Servereigenschaften für den folgenden benutzerdefinierten Schlüssel hinzuzufügen.

  • Schlüssel: Benutzerdefinierter Schlüssel
  • Schlüssel: auth.ldap.read.timeout
  • Wert: 60000
  • Anzeigename: auth.ldap.read.timeout
  • Beschreibung: LDAP-Lese-Timeout

Weitere Serveroptimierungen

Servereigenschaft Standardeinstellung Warum diese Einstellung ändern?
Hintergrundbereitstellung 1.440 Minuten Die Häufigkeit für Hintergrundrichtlinienbereitstellungen in Minuten. Gilt nur für Always-On-Verbindungen für Android-Geräte. Eine Erhöhung der Häufigkeit von Richtlinienbereitstellungen reduziert die Serverlast. Die empfohlene Einstellung ist 1440 (24 Stunden).
Hintergrund-Hardwareinventur 1.440 Minuten Die Häufigkeit für die Hintergrund-Hardwareinventur in Minuten. Gilt nur für Always-On-Verbindungen für Android-Geräte. Eine Erhöhung der Häufigkeit der Hardwareinventur reduziert die Serverlast. Die empfohlene Einstellung ist 1440 (24 Stunden).
Intervall für die Überprüfung gelöschter Active Directory-Benutzer 15 Minuten Die Standard-Synchronisierungszeit für Active Directory beträgt 15 Minuten. Der Wert 0 verhindert, dass XenMobile nach gelöschten Active Directory-Benutzern sucht. Die empfohlene Einstellung ist 15 Minuten.
MaxNumberOfWorker 3 Die Anzahl der Threads, die beim Importieren vieler Volumenlizenzkäufe verwendet werden. Standardwert ist 3. Wenn Sie weitere Optimierungen benötigen, können Sie die Anzahl der Threads erhöhen. Bei einer größeren Anzahl von Threads, z. B. 6, führt ein Volumenlizenzimport jedoch zu einer hohen CPU-Auslastung.

So überprüfen Sie Deadlocks in einer SQL-Datenbank und löschen historische Daten

Wenn Sie Deadlocks sehen, führen Sie die folgende Abfrage aus, um die Deadlocks anzuzeigen. Anschließend kann ein Datenbankadministrator oder das Microsoft SQL-Team die Informationen bestätigen.

SQL-Abfrage

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-->

Datenbank bereinigen

Wichtig:

Sichern Sie Ihre Datenbank, bevor Sie Änderungen an den Tabellen vornehmen.

  1. Führen Sie die folgende Abfrage aus, um die historischen Daten zu überprüfen.

    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-->
    
  2. Löschen Sie die Daten aus den drei vorhergehenden Tabellen.

    Hinweis:

    Möglicherweise sehen Sie keine historischen Daten in einer Tabelle. Überspringen Sie in diesem Fall die Ausführung der Truncate-Abfrage für diese bestimmte Tabelle.

    truncate TABLE dbo.EWDEPLOY_HISTO;
    truncate TABLE dbo.EWSESS;
    truncate TABLE dbo.EWAUDIT;
    <!--NeedCopy-->
    
  3. Heben Sie die Blockierung der SELECT-Abfragen auf, die aufgrund von Deadlocks blockiert waren. Dieser Schritt verhindert weitere Deadlocks.

    ALTER DATABASE <database_name> SET       READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE
    <!--NeedCopy-->
    
  4. Standardmäßig beträgt die Datenbankbereinigung sieben Tage für die Aufbewahrung von Sitzungs- und Auditdaten, was für viele Benutzer hoch ist. Ändern Sie den Bereinigungswert auf 1 oder 2 Tage. Nehmen Sie in den Servereigenschaften die folgende Änderung vor:

    zdm.dbcleanup.sessionRetentionTimeInDays = 1 day
    zdm.dbcleanup.deployHistRetentionTimeInDays = 1 day
    zdm.dbcleanup.auditRetentionTimeInDays=1 day
    <!--NeedCopy-->
    

Waisen in der KEYSTORE-Tabelle bereinigen

Wenn XenMobile-Knoten eine schlechte Leistung aufweisen, überprüfen Sie, ob die KEYSTORE-Tabelle zu groß ist. Der XenMobile Server speichert Registrierungszertifikate in den Tabellen ENROLLMENT_CERTIFICATE und KEYSTORE. Wenn Sie Geräte löschen oder erneut registrieren, werden die Zertifikate in der Tabelle ENROLLMENT_CERTIFICATE gelöscht. Einträge in der KEYSTORE-Tabelle bleiben erhalten, was zu Leistungsproblemen führen kann. Führen Sie das folgende Verfahren aus, um die Waisen aus der KEYSTORE-Tabelle zu bereinigen.

Wichtig:

Sichern Sie Ihre Datenbank, bevor Sie Änderungen an den Tabellen vornehmen.

  1. Führen Sie die folgende Abfrage aus, um die historischen Daten zu überprüfen.

    select COUNT(*) from KEYSTORE
    <!--NeedCopy-->
    
  2. Suchen Sie mit der folgenden Abfrage nach Waisen in der KEYSTORE-Tabelle.

    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-->
    
  3. Löschen Sie die Waisen mit der folgenden Abfrage.

    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-->
    
  4. Fügen Sie der KEYSTORE-Tabelle einen Index hinzu, um die Sucheffizienz zu verbessern.

    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-->