Temos um aplicativo CF8 que é executado por 20 a 25 minutos antes de travar sob carga pesada ~ 1200 usuários. Essa carga é gerada por nossa ferramenta de teste de carga: 1200 usuários aumentaram em 5 minutos (aproximadamente o comportamento de nossos usuários), funcionando por uma hora.
Temos este aplicativo no Solaris 10, Apache 2, JRun 4 e Oracle 10g. A versão do Java é 1.6.
Durante os testes de carga iniciais, os dumps de thread apontavam para monitorar deadlocks que apontavam para sessões.
"jrpp-173":
waiting to lock monitor 0x019fdc60 (object 0x6b893530, a java.util.Hashtable),
which is held by "scheduler-1"
"scheduler-1":
waiting to lock monitor 0x026c3ce0 (object 0x6abe2f20, a coldfusion.monitor.memory.SessionMemoryMonitor$TopMemoryUsedSessions),
which is held by "jrpp-167"
"jrpp-167":
waiting to lock monitor 0x019fdc60 (object 0x6b893530, a java.util.Hashtable),
which is held by "scheduler-1"
Aumentamos o número de sessões em relação ao número de CPUs (48 encadeamentos simultâneos contra 32 CPUs), e o impasse foi embora. Embora a variação dos encadeamentos simultâneos ajudasse um pouco em termos de tempo de resposta, o servidor CF ainda ficava cheio em 20 a 25 minutos durante todos desses testes.
Fizemos mais despejos de thread e vimos um thread bloqueando um monitor, por exemplo:
"jrpp-475" prio=3 tid=0x02230800 nid=0x2c5 runnable [0x4397d000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.getEntry(HashMap.java:347)
at java.util.HashMap.containsKey(HashMap.java:335)
at java.util.HashSet.contains(HashSet.java:184)
at coldfusion.monitor.memory.MemoryTracker.onAddObject(MemoryTracker.java:124)
at coldfusion.monitor.memory.MemoryTrackerProxy.onReplaceValue(MemoryTrackerProxy.java:598)
at coldfusion.monitor.memory.MemoryTrackerProxy.onPut(MemoryTrackerProxy.java:510)
at coldfusion.util.CaseInsensitiveMap.put(CaseInsensitiveMap.java:250)
at coldfusion.util.FastHashtable.put(FastHashtable.java:43)
- locked <0x6f7e1a78> (a coldfusion.runtime.Struct)
at coldfusion.runtime.CfJspPage._arrayset(CfJspPage.java:1027)
at coldfusion.runtime.CfJspPage._arraySetAt(CfJspPage.java:2117)
at cfvalidation2ecfc1052964961$funcSETUSERAUDITDATA.runFunction(/app/docs/apply/cfcs/validation.cfc:377)
Como você pode ver na última linha acima, havia várias referências de CFMs e CFCs, e as linhas tinham tags "cflock", que tinham como escopo o "aplicativo". Nós (a equipe de desenvolvedores) os alteramos para o escopo de um "nome".
Depois de mais testes de carga, não há bloqueio acontecendo e não há deadlocks, mas agora os tanques de aplicação em 7-10 minutos.
Recebemos relatórios de sistema, rede e banco de dados dos respectivos administradores e eles não estão sendo tributados; Até mesmo assisti as estatísticas do servidor com o monitor do servidor, top, prstat, correu relatórios sar, etc Então, nós acreditamos que é um problema com o servidor CF ou talvez a JVM.
Estou ficando sem ideias quanto ao que mais podemos tentar. Disclaimer: Eu não sou um desenvolvedor CF ou Admin. Estou apenas executando o teste de carga, analisando os relatórios, os encadeamentos, etc, e compartilhando os resultados com as equipes de desenvolvimento e administração, e tentando a próxima alteração, e assim por diante. Até agora não há dados.
Alguém se deparou com algo semelhante? Como você fez o diagnóstico e a solução de problemas? Todos os pensamentos e ponteiros são bem vindos.
Obrigado pelo seu tempo!
KM
Obrigado Mark e Adam por reservar um tempo para examinar minha pergunta e suas sugestões. Este problema específico foi resolvido. Evidentemente, nosso novo servidor foi construído a partir de um servidor antigo com "CF corrompido" - o que quer que isso signifique. Desde então, ela foi reconstruída e o desempenho não é mais um problema.
KM
Quando você bloqueia o escopo do aplicativo (nome ou um bloqueio de "escopo"), você essencialmente "serializa" as variáveis do aplicativo. Então, isso em si é um problema .... app vars deve ser bloqueado e escrito uma vez e, em seguida, ler à vontade (de preferência e com segurança sem bloqueios, pois eles não estão mudando). Pode ser um arenque vermelho de qualquer maneira. quando você bloqueia o escopo do aplicativo e acessa seus bloqueios o tempo todo, você naturalmente acaba com coisas relacionadas a ele no log (já que tanta coisa está acontecendo lá).
Eis as minhas melhores suposições
Verifique o "coldfusion monitor" e certifique-se de que (double, triple, quadrupal) o "perfil de memória" não está ativado. Na verdade, para seu teste de carga, certifique-se de que o acompanhamento e o monitoramento não estejam ativados - e eu até desligaria as métricas. Seu snippet acima me faz pensar que o rastreamento de memória está ativado e você está simplesmente ultrapassando o servidor. Isso acontece porque o heap tem que ser constantemente introspectivo para mudanças - extremamente caro. O acompanhamento de memória só deve ser ativado por um curto período quando você está baselining.
32 CPUs e 48 sim. pedidos .... isso é um monte de poder de CPU. Se você estiver usando o JRUN, certifique-se de que os threads do Jrun estejam definidos o suficiente ao norte do que o Jrun tem alguns threads de controle para trabalhar.
Verifique no diretório bin por erros de hot spot - erros iniciados por "hs_errpidXXX.log" (ou algo semelhante). Se você vê-los, a pilha pode lhe dar algumas dicas - mas normalmente é algo como erros de mem ou CFX de terceiros ou código java nativo que está lançando exceções não tratadas para o compilador de hotsports.
Por fim, verifique seu cliente vars. Às vezes você os está usando quando você não os "usa". Se você estiver, eles serão armazenados em um arquivo no servidor Solaris e isso definitivamente causará um problema durante o carregamento - especialmente quando o arquivo é anexado ou bloqueado durante uma limpeza. Confira este post para mais informações:
Isso é tudo o que vem à mente no momento ... se você quiser que eu olhe mais de perto na segunda-feira (em uma base formal), deixe-me saber e podemos conversar sobre isso.