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.
-
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--> -
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--> -
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--> -
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.
-
Führen Sie die folgende Abfrage aus, um die Verlaufsdaten zu überprüfen.
select COUNT(*) from KEYSTORE <!--NeedCopy--> -
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--> -
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--> -
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-->
In diesem Artikel
- hibernate.c3p0.idle_test_period
- hibernate.c3p0.max_size
- hibernate.c3p0.min_size
- hibernate.c3p0.timeout
- Taktintervall der Pushdienste
- iOS MDM APNs - Verbindungspoolgröße
- auth.ldap.connect.timeout
- auth.ldap.read.timeout
- Weitere Serveroptimierungen
- Überprüfen von Deadlocks in einer SQL-Datenbank und Löschen von Verlaufsdaten