XenMobile Server: Aktuelles Release

XenMobile-Prozesse optimieren

Die Leistung und Stabilität von XenMobile-Prozessen basiert auf vielen Einstellungen in XenMobile und wird durch die Konfiguration von Citrix ADC und der SQL Server-Datenbank beeinflusst. In diesem Artikel werden die Einstellungen beschrieben, die für eine Optimierung von XenMobile am häufigsten zu konfigurieren sind. Citrix empfiehlt, dass Sie jede der im Artikel beschriebenen Einstellungen überprüfen, bevor Sie XenMobile bereitstellen.

Wichtig:

In diesen Richtlinien wird davon ausgegangen, dass CPU und Arbeitsspeicher des XenMobile-Servers für die Anzahl der Geräte angemessen sind. Weitere Informationen zur Skalierbarkeit finden Sie unter Skalierbarkeit und Leistung.

Die folgenden Servereigenschaften gelten global für alle Vorgänge, Benutzer und Geräte einer XenMobile-Instanz. Bei Änderung einiger Servereigenschaften ist ein Neustart jedes XenMobile-Serverknotens erforderlich. XenMobile benachrichtigt Sie, wenn ein Neustart erforderlich ist.

Diese Richtlinien zur Optimierung gelten für geclusterte und nicht geclusterte Umgebungen.

hibernate.c3p0.idle_test_period

Diese XenMobile Server-Eigenschaft ist ein benutzerdefinierter Schlüssel, mit dem die Leerlaufzeit (in Sekunden) festgelegt wird, bevor eine Verbindung automatisch überprüft wird. Konfigurieren Sie den Schlüssel wie im Folgenden beschrieben. Die Standardeinstellung ist 30.

  • Schlüssel: Benutzerdefinierter Schlüssel
  • Schlüssel: hibernate.c3p0. idle_test_period
  • Wert: 120
  • Anzeigename: hibernate.c3p0. idle_test_period
  • Beschreibung: Leerlaufzeit vor Ruhezustand

hibernate.c3p0.max_size

Dieser benutzerdefinierte Schlüssel legt fest, wie viele Verbindungen zur SQL Server-Datenbank von XenMobile maximal geöffnet werden können. XenMobile verwendet den für diesen benutzerdefinierten Schlüssel eingegebenen Wert als Obergrenze. Die Verbindungen werden nur bei Bedarf geöffnet. Wählen Sie Ihre Einstellungen je nach Kapazität des Datenbankservers.

Berücksichtigen Sie die folgende Gleichung in einer Clusterkonfiguration. Ihre c3p0-Verbindung multipliziert mit der Anzahl der Knoten entspricht der tatsächlichen Höchstanzahl an Verbindungen zur SQL Server-Datenbank, die XenMobile öffnen kann.

Wird dieser Wert in geclusterten und nicht geclusterten Konfigurationen mit zu kleinem SQL Server zu hoch angesetzt, kann dies bei Spitzenlast zu Problemen führen. Ein zu niedrig eingestellter Wert bedeutet, dass verfügbare SQL-Ressourcen möglicherweise ungenutzt bleiben.

Konfigurieren Sie den Schlüssel wie im Folgenden beschrieben. Der Standardwert ist 1000.

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

hibernate.c3p0.min_size

Dieser benutzerdefinierte Schlüssel legt fest, wie viele Verbindungen zur SQL Server-Datenbank von XenMobile mindestens geöffnet werden. Konfigurieren Sie den Schlüssel wie im Folgenden beschrieben. Der Standardwert ist 100.

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

hibernate.c3p0.timeout

Dieser benutzerdefinierte Schlüssel definiert den Wert für Leerlauftimeouts. Bei einem Datenbankcluster mit Failover empfiehlt Citrix, diesen benutzerdefinierten Schlüssel hinzuzufügen und einzurichten, um Leerlauftimeouts zu reduzieren. Die Standardeinstellung ist 120.

  • Schlüssel: Benutzerdefinierter Schlüssel
  • Schlüssel: hibernate.c3p0.timeout
  • Wert: 120
  • Anzeigename: hibernate.c3p0.timeout
  • Beschreibung: Timeout bei Datenbankleerlauf

Taktintervall der Pushdienste

Diese Einstellung legt fest, wie häufig ein iOS-Gerät prüft, ob zwischenzeitlich eine APNs-Benachrichtigung nicht zugestellt wurde. Eine Erhöhung der APNs-Taktfrequenz kann die Datenbankkommunikation optimieren. Ein zu hoher Wert kann die Arbeitslast unnötig erhöhen. Diese Einstellung gilt nur für iOS-Geräte. Der Standardwert ist 20 Stunden.

Bei sehr vielen iOS-Geräten in Ihrer Umgebung kann das Taktintervall zu einer unnötigen Erhöhung der Arbeitslast führen. Sicherheitsaktionen wie Selektives Löschen, Sperren und Vollständiges Löschen agieren unabhängig vom Heartbeat: Wenn diese Aktionen ausgeführt werden, wird eine APNs-Benachrichtigung an das Gerät gesendet.

Dieser Wert legt fest, wie schnell eine Richtlinie nach Änderungen an einer Active Directory-Gruppenmitgliedschaft aktualisiert wird. Daher ist es oft sinnvoll, einen Wert zwischen 12 und 20 Stunden zu verwenden, um die Last zu reduzieren.

iOS MDM APNs - Verbindungspoolgröße

Ein zu kleiner APNs-Verbindungpool kann sich negativ auf die APNs-Aktivität auswirken, wenn Sie mehr als 100 Geräte verwenden. Auftretende Leistungsprobleme können eine langsame Bereitstellung von Apps und Richtlinien auf Geräten und eine verzögerte Geräteregistrierung sein. Die Standardeinstellung ist 1. Wir empfehlen, diesen Wert für etwa alle 400 Geräte um 1 zu erhöhen.

auth.ldap.connect.timeout

Bei einer langsamen LDAP-Antwort empfiehlt Citrix das Hinzufügen von Servereigenschaften für den folgenden benutzerdefinierten Schlüssel.

  • Schlüssel: Benutzerdefinierter Schlüssel
  • Schlüssel: auth.ldap.connect.timeout
  • Wert: 60000
  • Anzeigename: auth.ldap.connect.timeout
  • Beschreibung: Zeitlimit für LDAP-Verbindung

auth.ldap.read.timeout

Bei einer langsamen LDAP-Antwort empfiehlt Citrix das Hinzufügen von Servereigenschaften für den folgenden benutzerdefinierten Schlüssel.

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

Weitere Serveroptimierungen

     
Servereigenschaft Standardeinstellung Gründe für ein Ändern dieser Einstellung
Hintergrundbereitstellung 1440 Minuten Die Häufigkeit der Hintergrundbereitstellung von Richtlinien, in Minuten. Gilt nur für immer aktive Verbindungen bei Android-Geräten. Eine häufigere Bereitstellung von Richtlinien verringert die Serverlast. Die empfohlene Einstellung ist 1440 (24 Stunden).
Hardwareinventur im Hintergrund 1440 Minuten Die Häufigkeit von Hardwareinventuren im Hintergrund, in Minuten. Gilt nur für immer aktive Verbindungen bei Android-Geräten. Ein häufigeres Durchführen von Hardwareinventuren verringert die Serverlast. Die empfohlene Einstellung ist 1440 (24 Stunden).
Intervall zur Suche nach gelöschten Active Directory-Benutzern 15 Minuten Die standardmäßige Synchronisierungszeit für Active Directory ist 15 Minuten. Der Wert 0 deaktiviert in XenMobile die Suche nach gelöschten Active Directory-Benutzern. Die empfohlene Einstellung ist 15 Minuten.
MaxNumberOfWorker 3 Zahl der beim Importieren eine großen Anzahl von Volume Purchase-Lizenzen verwendeten Threads. Der Standardwert ist 3. Ist eine weitere Optimierung erforderlich, können Sie die Zahl der Threads erhöhen. Bei einer größeren Anzahl von Threads (z. B. 6) führt ein Volume Purchase-Import jedoch zu einer hohen CPU-Auslastung.

Überprüfen von Deadlocks in einer SQL-Datenbank und Löschen von Verlaufsdaten

Bei vorhandenen Deadlocks führen Sie die folgende Abfrage aus, um die Deadlocks anzuzeigen. Anschließend kann ein Datenbankadministrator oder Microsoft SQL-Teammitglied 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-->

Bereinigen der Datenbank

Wichtig:

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

  1. Führen Sie die folgende Abfrage aus, um die Verlaufsdaten 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 vorangegangenen drei Tabellen.

    Hinweis:

    Unter Umständen sehen Sie keine Verlaufsdaten in einer Tabelle. Überspringen Sie in diesem Fall die TRUNCATE-Abfrage für diese spezielle Tabelle.

    truncate TABLE dbo.EWDEPLOY_HISTO;
    truncate TABLE dbo.EWSESS;
    truncate TABLE dbo.EWAUDIT;
    <!--NeedCopy-->
    
  3. Entsperren Sie die SELECT-Abfragen, die durch die Deadlocks blockiert wurden. Dieser Schritt behebt alle weiteren Deadlocks.

    ALTER DATABASE <database_name> SET       READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE
    <!--NeedCopy-->
    
  4. Standardmäßig erfolgt die Datenbankbereinigung alle sieben Tage für aufzubewahrende Sitzungs- und Auditprotokolldaten, deren Datenmenge bei vielen Benutzern hoch ist. Ändern Sie den Bereinigungswert in 1 oder 2 Tage. Ändern Sie die Servereigenschaften wie folgt:

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

Verwaiste Einträge in der KEYSTORE-Tabelle bereinigen

Wenn XenMobile-Knoten eine schlechte Leistung zeigen, überprüfen Sie, ob die KEYSTORE-Tabelle zu groß ist. XenMobile Server speichert Registrierungszertifikate in den Tabellen ENROLLMENT_CERTIFICATE und KEYSTORE. Wenn Sie Geräte löschen oder neu 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 verwaisten Einträge aus der KEYSTORE-Tabelle zu löschen.

Wichtig:

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

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

    select COUNT(*) from KEYSTORE
    <!--NeedCopy-->
    
  2. Suchen Sie mit der folgenden Abfrage nach verwaisten Einträgen 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 verwaisten Einträge 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-->