memória virtual confirmada

Question

Depois que ocorre uma rejeição do servidor e após cerca de 40 a 45 dias, recebemos alertas contínuos de "Confirmação de memória virtual" que indicam o uso de espaço de troca na magnitude de > 4 GB Isso também faz com que o aplicativo tenha um desempenho muito lento e experimente várias transações interrompidas. Configuração do servidor:

4 Servidores Tomcat (versão 7.0.22) que são balanceados por carga (não agrupados) por 2 Servidores Apache. E os próprios servidores Apache fornecem conteúdo estático e roteamento para esses 4 servidores tomcat.

Java Runtime Version: java version "1.6.0_30" Java(TM) SE Runtime Environment (build 1.6.0_30-b12) Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode

Parâmetros de inicialização da memória:

MEMORY_OPTIONS="-Xms1024m -Xmx1024m -Xss192k -XX:MaxGCPauseMillis=500 -XX:+HeapDumpOnOutOfMemoryError -XX:MaxPermSize=256m -XX:+CMSClassUnloadingEnabled"

Monitoramento - o monitoramento do Wily está disponível em todos os servidores de produção que monitoram os principais parâmetros do servidor e envia e-mails de alerta configuráveis com base em configurações predefinidas.

Nota: Cada um dos servidores também tem dois outros domínios tomcat separados que executam aplicativos diferentes

Área investigada:

• Não há vazamento de memória Heap e o GC está funcionando sem problemas durante qualquer período de tempo
• A contagem de threads ocupada atual corresponde diretamente ao uso do aplicativo - fins de semana e noites têm menor não. de tópicos em comparação ao horário comercial
• O ThreadLocal usa um WeakReference internamente. Se o ThreadLocal não for strongmente referenciado, ele será coletado como lixo, mesmo que vários segmentos tenham valores armazenados por meio desse ThreadLocal.
• Além disso, os valores do ThreadLocal são realmente armazenados no Thread; se um encadeamento for interrompido, todos os valores associados a esse encadeamento por meio de um ThreadLocal serão coletados.
• Se você tiver um ThreadLocal como um membro da classe final, essa é uma referência strong e não poderá ser coletada até que a classe seja descarregada. Mas é assim que qualquer membro da classe trabalha, e não é considerado um vazamento de memória.
• O problema citado só entra em ação quando o valor armazenado em um ThreadLocal referencia strongmente aquele ThreadLocal - uma espécie de referência circular. Nesse caso, o valor (um SimpleDateFormat) não possui referência anterior ao ThreadLocal. Não há vazamento de memória neste código.

Alguém pode, por favor, me avisar o que poderia ser a causa disso e o que ser monitorado?