Travamento

Estas “30 instâncias de Java” não são 30 JVMs instanciadas, mas é a forma como o Linux costuma mapear as threads da sua aplicação quando o mecanismo de threads usado pelo seu Linux é o LWP (e não pThreads). Obviamente estou considerando que sua aplicação Java não cria novos processos de JVM durante sua execução.

Agora, como resolver seu problema, ninguém aqui vai saber como lhe ajudar se você não explicar exatamente:

• o que sua aplicação faz
• como sua aplicação faz isso
• e por que você faz isso desta maneira

Para não ver todas essas instâncias, você deve usar um Linux com kernel 2.6 (provavelmente seu kernel é 2.4.)

(Mas vai “travar” do mesmo jeito. Talvez você precise arranjar mais memória - quanta memória você tem? Que distribuição você está usando?)

Antes de mais nada agradeço as respostas.

Vejam só o pepino que tenho nas mãos. O software deve rodar em estações ThinClient da TechnoWorld. O sistema operacional é o MetaSys, uma distribuição baseada em Fedora 4. O Kernel é o 2.6.17. Infelizmente, não posso mudar nada disso.

Trata-se de uma aplicação multimedia pensada para rodar standalone e na Web.

Funciona da seguinte maneira:

• Abre-se uma janela de Browser embutida, através do JDesktop. O browser é o Mozilla SeaMonkey.
• Esta janela abre páginas com conteúdos em Flash (.swf). Utilizo o Flash plugin para Mozilla.
• Inicia-se o serviço Tomcat embutido que recebe pedidos HTTP e processa páginas JSP.
• Inicia-se o servidor de banco de dados Derby, também embutido. As páginas JSP acessam este banco de dados.

É isso, será que conseguirei rodar este elefante em uma estação Thinclient?

Entrei no centro de informações de hardware e obtive as seguintes informações sobre a máquina:

Processador: CentaurHauls Via Samuel 2 (nunca vi isto antes)
Clock: 800MhZ
Cache: 64KB
Memória: 216 MB

Espero que o “thin client” rode apenas o servidor X (só a parte de visualização); o resto tem de rodar em um servidor normal. Mas o Firefox é bastante pesado para rodar no servidor - eu vi isso em um thin client Solaris. Espero que a parte do Flash não tenha animações com taxa de refresh muito rápida - elas “matam” a banda de rede do Thin Client.

É por isso que o processador é esse - se você abrir uma máquina dessas vai descobrir que o processador nem tem ventilador no cooler, ou seja, ela é bem lenta para processar, e só é adequada para efetuar a visualização dos dados (como se fosse o Remote Desktop do Windows).

Quanto ao kernel 2.6 ele deveria estar mostrando apenas uma instância do Java (ou um pouco mais, se você tiver o Derby rodando em uma JVM separada), a menos que você esteja com 20 instâncias do Tomcat, o que não deve estar ocorrendo porque para configurar o Tomcat com 20 instâncias você tem de ralar um pouco

No caso específico do Red Hat, mesmo com o kernel 2.4 aparece apenas 1 instância do Java por JVM, não 20 (uma para cada thread). Acho que isso só ocorre se você setar uma variável de environment que normalmente só é necessária se você vai rodar algo que não funciona direito com o kernel 2.6 (acho que o IBM DB2 é assim.)

Acho que você está confundindo o sistema operacional que roda no thin client (que na verdade não importa muito para você ) com o sistema operacional que roda no servidor. Pelo que você reportou, parece que o kernel é 2.4 nesse servidor, não 2.6. O que “uname -a” reporta no servidor?

Uma das coisas que aparece com “uname” é justamente a versão do kernel.

Agora entendi por que está pesado.

Você está usando uma instância de uma aplicação Swing (ou SWT) por cada cliente.
Isso já é naturalmente pesado; se puder usar uma versão da JRE (como 5.0 ou 6.0) que permita o compartilhamento de memória entre aplicativos (deve ser iniciado com -client, não como -server), já melhora um pouco o consumo de memória.
Outra coisa pesada é usar um browser por usuário - o Firefox, e acredito que o SeaMonkey também, é outro devorador de memória.
O problema é que não sei se o compartilhamento é possível se cada usuário estiver logado com um usuário diferente do Unix. Não tenho dados para lhe dizer.

Thingol e Daniel Quirino Oliveira obrigado pela ajuda.

Consegui detectar as threads que consumiam mais memória com o Netbeans Profiler.

Desta forma, foi possível distribuir melhor os processos entre o servidor e os clientes.

Cumprimentos,

Guilherme.