Ajustar las operaciones de XenMobile
El rendimiento y la estabilidad de las operaciones de XenMobile implican muchas configuraciones en XenMobile y dependen de la configuración de Citrix ADC y la base de datos de SQL Server. Este artículo se centra en los parámetros que definen con mayor frecuencia los administradores, relacionadas con los ajustes y la optimización de XenMobile. Citrix recomienda que evalúe cada una de las configuraciones en este artículo antes de implementar XenMobile.
Importante:
En estas pautas se asume que la CPU y la RAM del servidor de XenMobile corresponden con la cantidad de dispositivos. Para obtener más información acerca de la escalabilidad, consulte Escalabilidad y rendimiento.
Las siguientes propiedades de servidor se aplican globalmente a operaciones, usuarios y dispositivos en toda la instancia de XenMobile. Un cambio en algunas propiedades de servidor requiere un reinicio de cada nodo de XenMobile Server. XenMobile le notifica cuando es necesario un reinicio.
Estas indicaciones de ajustes se aplican a entornos agrupados en clúster y no agrupados.
hibernate.c3p0.idle_test_period
Esta propiedad de XenMobile Server, una clave personalizada (Custom Key), determina el tiempo de inactividad, en segundos, antes de que se valide automáticamente una conexión. Configure la clave de este modo. El valor predeterminado es 30.
- Clave: Clave personalizada
- Clave: hibernate.c3p0. idle_test_period
- Valor: 120
- Nombre simplificado: hibernate.c3p0. idle_test_period
- Descripción: Período de prueba para el tiempo de espera antes de hibernar
hibernate.c3p0.max_size
Esta clave personalizada determina la cantidad máxima de conexiones a la base de datos de SQL Server que puede abrir XenMobile. XenMobile utiliza el valor que se especifica para esta clave personalizada como el límite máximo. Las conexiones se abren solo si las necesita. Debe establecer sus parámetros en función de la capacidad del servidor de la base de datos.
Tenga en cuenta la siguiente ecuación en una configuración en clúster. La conexión c3p0 multiplicada por la cantidad de nodos equivale a su cantidad máxima real de conexiones a la base de datos de SQL Server que XenMobile puede abrir.
En configuraciones agrupadas en clúster o sin clústeres, establecer el valor demasiado alto con un SQL Server demasiado pequeño puede causar problemas de recursos en el lado de SQL durante la carga máxima. Establecer un valor demasiado bajo puede derivar en que no aproveche los recursos SQL disponibles.
Configure la clave de este modo. El valor predeterminado es 1000.
- Clave: hibernate.c3p0.max_size
- Valor: 1000
- Nombre simplificado: hibernate.c3p0.max_size
- Descripción: Conexiones de base de datos a SQL
hibernate.c3p0.min_size
Esta clave personalizada determina la cantidad mínima de conexiones a la base de datos de SQL Server que puede abrir XenMobile. Configure la clave de este modo. El valor predeterminado es 100.
- Clave: hibernate.c3p0.min_size
- Valor: 100
- Nombre simplificado: hibernate.c3p0.min_size
- Descripción: Conexiones de base de datos a SQL
hibernate.c3p0.timeout
Esta clave personalizada determina el tiempo de espera por inactividad. Si usa la conmutación por error en los clústeres de la base de datos, Citrix recomienda agregar esta clave personalizada y definirla para reducir el tiempo de inactividad. El valor predeterminado es 120.
- Clave: Clave personalizada
- Clave: hibernate.c3p0.timeout
- Valor: 120
- Nombre simplificado: hibernate.c3p0.timeout
- Descripción: Tiempo de espera por inactividad que tiene la base de datos
Intervalo de latido de Push Services
Esta configuración determina la frecuencia con la que un dispositivo iOS verifica si una notificación de APNs se ha entregado en el intervalo. Aumentar la frecuencia de latidos del APNs puede optimizar las comunicaciones de la base de datos. Un valor demasiado grande puede agregar una carga innecesaria. Esta configuración solo se aplica a dispositivos iOS. El valor predeterminado es 20 horas.
Si tiene una gran cantidad de dispositivos iOS en su entorno, el intervalo de latidos puede generar una carga mayor de la necesaria. Las acciones de seguridad, como el borrado selectivo, el bloqueo y el borrado completo, no dependen de este latido. Esto se debe a que se envía una notificación de APNs al dispositivo cuando se ejecutan estas acciones.
Este valor determina la rapidez con la que se actualiza una directiva después de que cambien los miembros de los grupos de Active Directory. Como tal, a menudo es conveniente aumentar este valor a entre 12 y 20 horas para reducir la carga.
Tamaño de la agrupación de conexiones APNS de iOS MDM
Una agrupación de conexiones APNs que es demasiado pequeña puede afectar negativamente al rendimiento de las actividades APNs si dispone de más de 100 dispositivos. Los problemas de rendimiento incluyen una implementación más lenta de aplicaciones y directivas en los dispositivos y un registro más lento de los dispositivos. El valor predeterminado es 1. Le recomendamos aumentar este valor en 1 por cada 400 dispositivos aproximadamente.
auth.ldap.connect.timeout
Para compensar las respuestas LDAP lentas, Citrix recomienda que agregue propiedades de servidor a la siguiente clave personalizada.
- Clave: Clave personalizada
- Clave: auth.ldap.connect.timeout
- Valor: 60000
- Nombre simplificado: auth.ldap.connect.timeout
- Descripción: Tiempo de espera de la conexión LDAP
auth.ldap.read.timeout
Para compensar las respuestas LDAP lentas, Citrix recomienda que agregue propiedades de servidor a la siguiente clave personalizada.
- Clave: Clave personalizada
- Clave: auth.ldap.read.timeout
- Valor: 60000
- Nombre simplificado: auth.ldap.read.timeout
- Descripción: Tiempo de lectura de la conexión LDAP
Otras optimizaciones de servidor
Propiedad de servidor | Configuración predeterminada | ¿Por qué cambiar esta configuración? |
Implementación en segundo plano | 1440 minutos | La frecuencia de las implementaciones de directivas en segundo plano, en minutos. Se aplica solo a las conexiones permanentes de dispositivos Android. Aumentar la frecuencia de las implementaciones de directivas reduce la carga del servidor. La configuración recomendada es 1440 (24 horas). |
Inventario de hardware en segundo plano | 1440 minutos | La frecuencia del inventario de hardware en segundo plano, en minutos. Se aplica solo a las conexiones permanentes de dispositivos Android. Aumentar la frecuencia del inventario de hardware reduce la carga del servidor. La configuración recomendada es 1440 (24 horas). |
Intervalo de verificación de usuarios eliminados de AD | 15 minutos | El tiempo de sincronización estándar para Active Directory es 15 minutos. El valor 0 impide que XenMobile verifique si hay usuarios eliminados de Active Directory. La configuración recomendada es 15 minutos. |
MaxNumberOfWorker | 3 | La cantidad de subprocesos que se utilizan cuando se importa una gran cantidad de licencias de compras por volumen. El valor predeterminado es 3. Si necesita mayor optimización, puede aumentar la cantidad de subprocesos. No obstante, con una mayor cantidad de subprocesos (por ejemplo, 6), una importación de compras por volumen consume mucha CPU. |
Cómo consultar interbloqueos en una BD SQL y eliminar datos históricos
Cuando detecte interbloqueos, ejecute la siguiente consulta para verlos. A continuación, un administrador de bases de datos o un equipo de Microsoft SQL puede confirmar la información.
Consulta 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
<!--NeedCopy-->
Limpiar la base de datos
Importante:
Realice una copia de seguridad de la base de datos antes de modificar las tablas.
-
Ejecute la siguiente consulta para comprobar los datos históricos.
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-->
-
Elimine los datos de las tres tablas anteriores.
Nota:
Es posible que no vea datos históricos en una tabla. En tal caso, omita la ejecución de la consulta truncate para dicha tabla.
truncate TABLE dbo.EWDEPLOY_HISTO; truncate TABLE dbo.EWSESS; truncate TABLE dbo.EWAUDIT; <!--NeedCopy-->
-
Desbloquee las consultas SELECT que se bloquearon con los interbloqueos. Este paso se encarga de posteriores interbloqueos.
ALTER DATABASE <database_name> SET READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE <!--NeedCopy-->
-
De forma predeterminada, la limpieza de la base de datos se realiza cada siete días para conservar datos de retención de sesión y de retención de auditoría, un valor elevado para muchos usuarios. Cambie el valor de limpieza a 1 o 2 días. En las propiedades del servidor, realice el siguiente cambio:
zdm.dbcleanup.sessionRetentionTimeInDays = 1 day zdm.dbcleanup.deployHistRetentionTimeInDays = 1 day zdm.dbcleanup.auditRetentionTimeInDays=1 day <!--NeedCopy-->
Borrar huérfanos de la tabla KEYSTORE
Si los nodos de XenMobile no rinden como es debido, compruebe si la tabla KEYSTORE es demasiado grande. XenMobile Server almacena los certificados de inscripción en las tablas ENROLLMENT_CERTIFICATE y KEYSTORE. Cuando elimina o vuelve a inscribir dispositivos, se eliminan los certificados de la tabla ENROLLMENT_CERTIFICATE. Las entradas de la tabla KEYSTORE permanecen, lo que puede causar problemas de rendimiento. Siga este procedimiento para borrar los huérfanos de la tabla KEYSTORE.
Importante:
Realice una copia de seguridad de la base de datos antes de modificar las tablas.
-
Ejecute la siguiente consulta para comprobar los datos históricos.
select COUNT(*) from KEYSTORE <!--NeedCopy-->
-
Compruebe si hay huérfanos en la tabla KEYSTORE con la siguiente consulta.
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-->
-
Borre los huérfanos mediante la siguiente consulta.
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-->
-
Agregue un índice a la tabla KEYSTORE para mejorar la eficiencia de las búsquedas.
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-->
En este artículo
- hibernate.c3p0.idle_test_period
- hibernate.c3p0.max_size
- hibernate.c3p0.min_size
- hibernate.c3p0.timeout
- Intervalo de latido de Push Services
- Tamaño de la agrupación de conexiones APNS de iOS MDM
- auth.ldap.connect.timeout
- auth.ldap.read.timeout
- Otras optimizaciones de servidor
- Cómo consultar interbloqueos en una BD SQL y eliminar datos históricos