Ajuste das operações do XenMobile
O desempenho e a estabilidade das operações do XenMobile envolvem muitas configurações no XenMobile e dependem da configuração do banco de dados do Citrix ADC e do SQL Server. Este artigo enfoca nas configurações mais frequentemente definidas pelos administradores, relacionadas ao ajuste e à otimização do XenMobile. A Citrix recomenda que você avalie cada uma das configurações deste artigo antes de implantar o XenMobile.
Importante:
Essas diretrizes pressupõem que a CPU e a RAM do XenMobile Server são adequadas para o número de dispositivos. Para obter mais informações sobre escalabilidade, consulte Escalabilidade e desempenho.
As seguintes propriedades do servidor se aplicam globalmente a operações, usuários e dispositivos a uma instância inteira do XenMobile. A alteração em algumas propriedades do servidor requer uma reinicialização de cada nó do XenMobile Sever. O XenMobile avisa quando uma reinicialização é necessária.
Essas diretrizes de ajuste se aplicam a ambientes em cluster e não-cluster.
hibernate.c3p0.idle_test_period
Essa propriedade do XenMobile Server, uma chave personalizada, determina o tempo ocioso em segundos antes de uma conexão ser validada automaticamente. Configure a chave da seguinte maneira. O padrão é 30.
- Chave: chave personalizada
- Chave: hibernate.c3p0. idle_test_period
- Valor: 120
- Nome de exibição: hibernate.c3p0. idle_test_period
- Descrição: período de teste de inatividade de hibernação
hibernate.c3p0.max_size
Essa chave personalizada determina o número máximo de conexões que o XenMobile pode abrir no banco de dados do SQL Server. O XenMobile usa o valor que você especificou para esta chave personalizada como um limite superior. As conexões abrem somente se você precisar delas. Baseie suas configurações na capacidade do seu servidor de banco de dados.
Observe a seguinte equação em uma configuração em cluster. Sua conexão c3p0 multiplicada pelo número de nós é igual ao número máximo real de conexões que o XenMobile pode abrir para o banco de dados do SQL Server.
Na configuração em cluster e não-cluster, definir um valor muito alto com um SQL Server subdimensionado pode causar problemas de recursos no lado do SQL durante o pico de carga. Configurar um valor muito baixo poderá afetar o bom-aproveitamento dos recursos SQL disponíveis.
Configure a chave da seguinte maneira. O padrão é 1000.
- Chave: hibernate.c3p0.max_size
- Valor: 1000
- Nome de exibição: hibernate.c3p0.max_size
- Descrição: conexões de banco de dados ao SQL
hibernate.c3p0.min_size
Essa chave personalizada determina o número mínimo de conexões que o XenMobile abre no banco de dados do SQL Server. Configure a chave da seguinte maneira. O padrão é 100.
- Chave: hibernate.c3p0.min_size
- Valor: 100
- Nome de exibição: hibernate.c3p0.min_size
- Descrição: conexões de banco de dados ao SQL
hibernate.c3p0.timeout
Essa chave personalizada determina o tempo limite de ociosidade. Se você usar o failover de cluster do banco de dados, a Citrix recomenda que você adicione essa chave personalizada e defina-a para reduzir o tempo limite de inatividade. O padrão é 120.
- Chave: chave personalizada
- Chave: hibernate.c3p0.timeout
- Valor: 120
- Nome de exibição: hibernate.c3p0.timeout
- Descrição: tempo limite de inatividade do banco de dados
Intervalo de pulsação de serviços push
Esta configuração determina com que frequência um dispositivo iOS verifica se uma notificação de APNs não foi entregue nesse ínterim. Aumentar a frequência de pulsação dos APNs pode otimizar as comunicações do banco de dados. Um valor muito grande pode adicionar carga desnecessária. Essa configuração se aplica apenas ao iOS. O padrão é 20 horas.
Se você tiver vários dispositivos iOS em seu ambiente, o intervalo de pulsação pode levar a uma carga maior do que a necessária. As ações de segurança, como apagamento seletivo, bloqueio e apagamento completo, não dependem dessa pulsação. O motivo é que uma notificação de APNs é enviada ao dispositivo quando essas ações são executadas.
Esse valor determina a rapidez com que uma política é atualizada depois que a associação ao Grupo do Active Directory é alterada. Como tal, muitas vezes é adequado aumentar esse valor para algo entre 12 e 20 horas para reduzir a carga.
Tamanho do pool de conexões APNS de iOS MDM
Um pool de conexões APNs muito pequeno pode afetar negativamente o desempenho das atividades de APNs quando você tem mais de 100 dispositivos. Os problemas de desempenho incluem a implantação mais lenta de aplicativos e políticas em dispositivos e o registro mais lento de dispositivos. O padrão é 1. Recomendamos que você aumente esse valor em 1 a cada cerca de 400 dispositivos.
auth.ldap.connect.timeout
Para compensar lentas respostas LDAP, a Citrix recomenda que você adicione as propriedades do servidor para as seguintes chaves personalizadas.
- Chave: chave personalizada
- Chave: auth.ldap.connect.timeout
- Valor: 60000
- Nome de exibição: auth.ldap.connect.timeout
- Descrição: tempo limite da conexão LDAP
auth.ldap.read.timeout
Para compensar lentas respostas LDAP, a Citrix recomenda que você adicione as propriedades do servidor para as seguintes chaves personalizadas.
- Chave: chave personalizada
- Chave: auth.ldap.read.timeout
- Valor: 60000
- Nome de exibição: auth.ldap.read.timeout
- Descrição: tempo limite de leitura do LDAP
Outras otimizações de servidores
| Propriedade do servidor | Configuração padrão | Por que mudar essa configuração? |
| Implementação em segundo plano | 1.440 minutos | A frequência de implantações de políticas em segundo plano, em minutos. Aplica-se apenas a conexões permanentes de dispositivos Android. Aumentar a frequência de implantações de políticas reduz a carga do servidor. A configuração recomendada é 1440 (24 horas). |
| Inventário de hardware em segundo plano | 1.440 minutos | A frequência do inventário de hardware em segundo plano, em minutos. Aplica-se apenas a conexões permanentes de dispositivos Android. Aumentar a frequência do inventário de hardware reduz a carga do servidor. A configuração recomendada é 1440 (24 horas). |
| Intervalo para verificação de usuário do Active Directory excluído | 15 minutos | O tempo de sincronização padrão do Active Directory é de 15 minutos. O valor 0 impede que o XenMobile verifique usuários do Active Directory excluídos. A configuração recomendada é de 15 minutos. |
| MaxNumberOfWorker | 3 | O número de threads utilizados ao importar várias licenças de compra por volume. O padrão é 3. Se precisar de mais otimização, você pode aumentar o número de threads. No entanto, com um número maior de threads, como 6, uma importação de compra por volume resulta em uso de CPU alto. |
Como verificar deadlocks em um banco de dados SQL e excluir dados históricos
Quando você vir deadlocks, execute a consulta a seguir para ver os deadlocks. Depois, um administrador de banco de dados ou a equipe do Microsoft SQL pode confirmar as informações.
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-->
Limpar o banco de dados
Importante:
Faça backup do banco de dados antes de fazer alterações nas tabelas.
-
Execute a consulta a seguir para verificar os dados 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--> -
Exclua os dados das três tabelas anteriores.
Nota:
Você talvez não possa ver dados históricos em uma tabela. Em caso afirmativo, ignore a execução da consulta truncada dessa tabela específica.
truncate TABLE dbo.EWDEPLOY_HISTO; truncate TABLE dbo.EWSESS; truncate TABLE dbo.EWAUDIT; <!--NeedCopy--> -
Desbloquear as consultas SELECT que foram bloqueadas devido a deadlocks. Essa etapa cuida de mais deadlocks.
ALTER DATABASE <database_name> SET READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE <!--NeedCopy--> -
Por padrão, a limpeza do banco de dados é de sete dias para reter os dados de retenção de sessão e os dados de retenção de auditoria, o que é alto para muitos usuários. Altere o valor de limpeza para 1 ou 2 dias. Nas propriedades do servidor, faça a seguinte alteração:
zdm.dbcleanup.sessionRetentionTimeInDays = 1 day zdm.dbcleanup.deployHistRetentionTimeInDays = 1 day zdm.dbcleanup.auditRetentionTimeInDays=1 day <!--NeedCopy-->
Limpar órfãos na tabela KEYSTORE
Se os nós XenMobile tiverem desempenho ruim, verifique se a tabela KEYSTORE é muito grande. O XenMobile Server armazena certificados de registro nas tabelas ENROLLMENT_CERTIFICATE e KEYSTORE. Quando você exclui ou registra novamente os dispositivos, os certificados na tabela ENROLLMENT_CERTIFICATE são excluídos. As entradas na tabela KEYSTORE permanecem, o que pode causar problemas de desempenho. Execute o procedimento a seguir para limpar os órfãos da tabela KEYSTORE.
Importante:
Faça backup do banco de dados antes de fazer alterações nas tabelas.
-
Execute a consulta a seguir para verificar os dados históricos.
select COUNT(*) from KEYSTORE <!--NeedCopy--> -
Verifique se há órfãos na tabela KEYSTORE com a seguinte 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--> -
Limpe os órfãos usando a seguinte 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--> -
Adicione um índice à tabela KEYSTORE para melhorar a eficiência da pesquisa.
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-->
Neste artigo
- hibernate.c3p0.idle_test_period
- hibernate.c3p0.max_size
- hibernate.c3p0.min_size
- hibernate.c3p0.timeout
- Intervalo de pulsação de serviços push
- Tamanho do pool de conexões APNS de iOS MDM
- auth.ldap.connect.timeout
- auth.ldap.read.timeout
- Outras otimizações de servidores
- Como verificar deadlocks em um banco de dados SQL e excluir dados históricos