Servidor para replicação do servidor e CPU e 32k \ doc corrompido

Question

Resumo: se o banco de dados contiver um documento com problema 32K ou corrompido, na replicação do servidor para o servidor, haverá um aumento acentuado na CPU na tarefa nserver.exe, o que faz com que o (s) servidor (es) diminua a velocidade.

Temos um cluster de 5 servidores (1 "hub" e 4 servidores HTTP acessados via proxy reverso e SSO para balanceamento de carga e redundância). Todos estão fisicamente localizados um ao lado do outro na rede, eles não têm rede dedicada \ ports para cluster ou replicação. Eu percebo que a recomendação da IBM é uma porta dedicada para o cluster. As filas de cluster estão na tolerância e sob carga pesada do usuário do aplicativo, ou seja, o número máximo de documentos está sendo criado, editado, excluído, os tempos de replicação entre os servidores são insignificantes. Normalmente, tudo está bem.

Dos servidores no cluster, 1 é considerado o "hub" e imita uma replicação PUSH-PULL com seus correspondentes de cluster a cada 60mins, para que a carga de replicação seja tomada pelo hub e não pelos agrupamentos de cluster.

O problema que temos: de vez em quando, obtemos um tempo de replicação lento do hub para um cluster, às vezes até 30min. Isso maximiza a tarefa nserver.exe no "cluster mate", o que faz com que ele responda às solicitações http muito lentamente.

No passado, descobrimos que, se um documento corrompido está no banco de dados, ele pode ter esse efeito, mas nessas ocasiões, o log do servidor mostrará o documento corrompido noteId, nós executamos a correção, tudo bem. Mas agora não estamos vendo nenhum registro de documentos corruptos. O que notamos é que, se um documento com o problema 32K estiver presente, a mesma coisa pode acontecer. Nossa única solução nesse caso é executar um: fixup mydb.nsf -V, que mostra que ele está limpando um documento de 32K. Felizmente, executamos um proxy reverso, para que possamos desligar os servidores HTTP sem que os usuários percebam, mas os usuários notam quando um servidor tem o problema!

Alguém viu isso ocorrer?

Eu configurei os manipuladores de eventos do DDM para muitos dos eventos de replicação. Eu defini o limite de tempo de replicação para 5 minutos (o máximo que normalmente vemos sob carga total do usuário é de 0,1 min), para evitar que ele seja repassado por 30 minutos como antes. Isso é um trabalho temporário.

Alguém sabe de um evento do DDM para interceptar o problema 32K? nós poderíamos, pelo menos, enviar um alerta.

Em relação ao problema 32K: este prob precisa de outro thread, mas estamos achando isso relativamente difícil encontrar a origem do problema, já que o evento 32K é bastante raro. Nosso aplicativo é bastante complexo, interagindo com vários outros serviços da Web externos, com transferência de dados de 2 vias. Mas se encontrarmos um documento de 32K, não poderemos ver as propriedades do campo, portanto não podemos descobrir qual campo tem problema que nos daria uma pista sobre qual processo é o culpado. Como acima, nós executamos um ajuste -V.

Qualquer ajuda \ comentários sobre isso seria recebida com gratidão.

    

Answer 1

Se você ainda estiver interessado em receber alertas para problemas de 32K, pode dar uma olhada na ferramenta de monitoramento "GSX Monitor".

Página inicial do Monitor GSX

Usamos o GSX Monitor para esse propósito (embora não apenas para este :-))

    

Answer 2

Talvez você possa usar o probe Replication

Eu tive alguns problemas de replicação no passado e recebi uma sugestão da IBM para usar isso.

    

Answer 3

Você não mencionou a versão do Domino, mas dependendo das configurações que você escreveu, você passou a ter mais conhecimento do que os administradores básicos do Domino. Portanto, para solucionar problemas, você pode tentar desativar / ativar o recurso de replicação do Domino Streaming:

link

Talvez isso resolva o problema.