Ajuste de las operaciones de XenMobile®

Last published : Oct 21, 2026
El rendimiento y la estabilidad de las operaciones de XenMobile implican muchas configuraciones en XenMobile y dependen de la configuración de su base de datos de Citrix ADC y SQL Server. Este artículo se centra en la configuración que los administradores suelen configurar con mayor frecuencia, relacionada con el ajuste y la optimización de XenMobile. Citrix recomienda que evalúe cada una de las configuraciones de este artículo antes de implementar XenMobile.
Importante:
Estas directrices asumen que la CPU y la RAM del servidor XenMobile son adecuadas para el número de dispositivos. Para obtener más información sobre la escalabilidad, consulte Escalabilidad y rendimiento.
Las siguientes propiedades del servidor se aplican globalmente a las operaciones, los usuarios y los dispositivos en toda una instancia de XenMobile. Un cambio en algunas propiedades del servidor requiere un reinicio de cada nodo del servidor XenMobile. XenMobile le notifica cuando se requiere un reinicio.
Estas directrices de ajuste se aplican tanto a entornos agrupados como no agrupados.
Related information
Implementación de XenMobile®

hibernate.c3p0.idle\_test\_period

Esta propiedad del servidor XenMobile, una clave personalizada, determina el tiempo de inactividad en segundos antes de que una conexión se valide automáticamente. Configure la clave de la siguiente manera. El valor predeterminado es 30.
  • Clave: Clave personalizada
  • Clave: hibernate.c3p0. idle\_test\_period
  • Valor: 120
  • Nombre para mostrar: hibernate.c3p0. idle\_test\_period
  • Descripción: Período de prueba de inactividad de Hibernate

hibernate.c3p0.max\_size

Esta clave personalizada determina el número máximo de conexiones que XenMobile puede abrir a la base de datos de SQL Server. XenMobile utiliza el valor que especifique para esta clave personalizada como límite superior. Las conexiones se abren solo si las necesita. Base su configuración en la capacidad de su servidor de bases de datos.
Tenga en cuenta la siguiente ecuación en una configuración en clúster. Su conexión c3p0 multiplicada por el número de nodos es igual a su número máximo real de conexiones que XenMobile puede abrir a la base de datos de SQL Server.
En configuraciones en clúster y sin clúster, establecer un valor demasiado alto con un SQL Server de tamaño insuficiente puede causar problemas de recursos en el lado de SQL durante la carga máxima. Establecer un valor demasiado bajo significa que es posible que no pueda aprovechar los recursos de SQL disponibles.
Configure la clave de la siguiente manera. El valor predeterminado es 1000.
  • Clave: hibernate.c3p0.max\_size
  • Valor: 1000
  • Nombre para mostrar: hibernate.c3p0.max\_size
  • Descripción: Conexiones de BD a SQL

hibernate.c3p0.min\_size

Esta clave personalizada determina el número mínimo de conexiones que XenMobile abre a la base de datos de SQL Server. Configure la clave de la siguiente manera. El valor predeterminado es 100.
  • Clave: hibernate.c3p0.min\_size
  • Valor: 100
  • Nombre para mostrar: hibernate.c3p0.min\_size
  • Descripción: Conexiones de BD a SQL

hibernate.c3p0.timeout

Esta clave personalizada determina el tiempo de inactividad. Si utiliza una conmutación por error de clúster de base de datos, Citrix recomienda que añada esta clave personalizada y la configure para reducir el tiempo de inactividad. El valor predeterminado es 120.
  • Clave: Clave personalizada
  • Clave: hibernate.c3p0.timeout
  • Valor: 120
  • Nombre para mostrar: hibernate.c3p0.timeout
  • Descripción: Tiempo de espera de inactividad de la base de datos

Intervalo de latido de los servicios push

Esta configuración determina la frecuencia con la que un dispositivo iOS comprueba si una notificación APNs no se ha entregado mientras tanto. Aumentar la frecuencia del latido de APNs puede optimizar las comunicaciones de la base de datos. Un valor demasiado grande puede añadir una carga innecesaria. Esta configuración se aplica solo a iOS. El valor predeterminado es de 20 horas.
Si tiene muchos dispositivos iOS en su entorno, el intervalo de latido puede generar una carga superior a la necesaria. Las acciones de seguridad, como el borrado selectivo, el bloqueo y el borrado completo, no dependen de este latido. La razón es que se envía una notificación APNs al dispositivo cuando se ejecutan estas acciones.
Este valor rige la rapidez con la que se actualiza una directiva después de los cambios en la pertenencia a grupos de Active Directory. Por lo tanto, a menudo es adecuado aumentar este valor a algo entre 12 y 20 horas para reducir la carga.

Tamaño del grupo de conexiones APNS de MDM de iOS

Un grupo de conexiones APNs demasiado pequeño puede afectar negativamente al rendimiento de la actividad de APNs cuando tiene 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 de dispositivos más lento. El valor predeterminado es 1. Recomendamos que aumente este valor en 1 por cada 400 dispositivos aproximadamente.

auth.ldap.connect.timeout

Para compensar las respuestas lentas de LDAP, Citrix recomienda que agregue propiedades de servidor para la siguiente Clave personalizada.
  • Clave: Clave personalizada
  • Clave: auth.ldap.connect.timeout
  • Valor: 60000
  • Nombre para mostrar: auth.ldap.connect.timeout
  • Descripción: Tiempo de espera de conexión LDAP

auth.ldap.read.timeout

Para compensar las respuestas lentas de LDAP, Citrix recomienda que agregue propiedades de servidor para la siguiente clave personalizada.
  • Clave: Clave personalizada
  • Clave: auth.ldap.read.timeout
  • Valor: 60000
  • Nombre para mostrar: auth.ldap.read.timeout
  • Descripción: Tiempo de espera de lectura de LDAP

Otras optimizaciones del servidor
Propiedad del servidor Configuración predeterminada ¿Por qué cambiar esta configuración?
Implementación en segundo plano 1.440 minutos La frecuencia de las implementaciones de políticas en segundo plano, en minutos. Se aplica solo a las conexiones siempre activas para dispositivos Android. Aumentar la frecuencia de las implementaciones de políticas reduce la carga del servidor. La configuración recomendada es 1440 (24 horas).
Inventario de hardware en segundo plano 1.440 minutos La frecuencia del inventario de hardware en segundo plano, en minutos. Se aplica solo a las conexiones siempre activas para dispositivos Android. Aumentar la frecuencia del inventario de hardware reduce la carga del servidor. La configuración recomendada es 1440 (24 horas).
Intervalo para comprobar usuarios eliminados de Active Directory 15 minutos El tiempo de sincronización estándar para Active Directory es de 15 minutos. El valor 0 evita que XenMobile compruebe si hay usuarios de Active Directory eliminados. La configuración recomendada es de 15 minutos.
MaxNumberOfWorker 3 El número de subprocesos utilizados al importar muchas licencias de compra por volumen. El valor predeterminado es 3. Si necesita una mayor optimización, puede aumentar el número de subprocesos. Sin embargo, con un número mayor de subprocesos, como 6, una importación de compra por volumen da como resultado un alto uso de la CPU.

Cómo comprobar interbloqueos en una base de datos SQL y eliminar datos históricos

Cuando vea interbloqueos, ejecute la siguiente consulta para verlos. Luego, un administrador de bases de datos o el equipo de Microsoft SQL pueden 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

Limpiar la base de datos

Importante:
Haga una copia de seguridad de la base de datos antes de realizar cambios en las tablas.
  1. 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;
  2. Elimine los datos de las tres tablas anteriores.
    Nota:
    Es posible que no vea datos históricos en una tabla. Si es así, omita la ejecución de la consulta de truncamiento para esa tabla en particular.
    truncate TABLE dbo.EWDEPLOY_HISTO;
    truncate TABLE dbo.EWSESS;
    truncate TABLE dbo.EWAUDIT;
  3. Desbloquee las consultas SELECT que se bloquearon debido a interbloqueos. Este paso se encarga de evitar interbloqueos futuros.
    ALTER DATABASE <database_name> SET       READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE
  4. De forma predeterminada, la limpieza de la base de datos es de siete días para retener los datos de retención de sesión y retención de auditoría, lo cual es un valor alto 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

Limpiar huérfanos en la tabla KEYSTORE

Si los nodos de XenMobile tienen un rendimiento deficiente, 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, los certificados de la tabla ENROLLMENT_CERTIFICATE se eliminan. Las entradas de la tabla KEYSTORE permanecen, lo que puede causar problemas de rendimiento. Realice el siguiente procedimiento para limpiar los huérfanos de la tabla KEYSTORE.
Importante:
Haga una copia de seguridad de la base de datos antes de realizar cambios en las tablas.
  1. Ejecute la siguiente consulta para comprobar los datos históricos.
    select COUNT(*) from KEYSTORE
  2. 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;
  3. Borre los huérfanos 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)
        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'
        );
  4. Añada un índice a la tabla KEYSTORE para mejorar la eficiencia de búsqueda.
    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");