Introdução a vários proprietários Java

Conheça um novo recurso para sistemas em nuvem no IBM SDK Java Technology Edition, Versão 7 Liberação 1

A JVM de vários proprietários recentemente se tornou disponível como parte do IBM SDK Java™ Technology Edition, Versão 7 Liberação 1 como uma visualização de tecnologia. Executando diversos aplicativos dentro de uma única JVM de vários proprietários, um sistema em nuvem pode acelerar os horários de início de aplicativos e reduzir suas áreas de cobertura da memória. Este artigo apresenta a tecnologia por trás da JVM em nuvem de vários proprietários e discute os principais custos e benefícios.

A visualização técnica não está mais disponível. Para outras opções sobre implementação com diversos locatários, leia sobre contêineres IBM que suportam implementação MT.

Graeme Johnson, J9 Virtual Machine Development Manager, IBM  

Photo of Graeme JohnsonGraeme Johnson é um gerente de desenvolvimento e líder técnico na equipe J9 Virtual Machine da IBM. Ele tem desenvolvido máquinas virtuais e depuradores desde que entrou na IBM (anteriormente Object Technology International) em 1994 e ele trabalhou nos tempos de execução do VisualAge for Java e IBM/OTI Smalltalk. Recentemente, Graeme está focado no projeto do Apache Harmony e no suporte ao tempo de execução Java/PHP para o Projeto Zero da IBM. Graeme é um orador regular em conferências sobre vários tópicos que incluem: Apache Harmony em JavaOne 2006, desenvolvimento C de multiplataforma em EclipseCon 2007 e um exame do tempo de execução PHP em International PHP 2006.



Michael Dawson, Software Developer, IBM  

Photo of Michael DawsonMichael Dawson tem trabalhado com a equipe J9 JVM nos últimos nove anos, implementando componentes da JVM de núcleo. Ele tem contribuído com entregas para o IBM SDK for Java ao longo dos anos, incluindo WebSphere Real Time mais as liberações Java 6 e Java 7 entre plataformas. Nos últimos anos, ele contribuiu com os esforços de nuvem e virtualização da IBM para tecnologia Java. No passado, ele exerceu funções de liderança em equipes que desenvolviam aplicativos de e-commerce e os entregava como serviços, incluindo serviços de comunicação EDI, processamento de cartão de crédito, leilões online e fatura eletrônica.



25/Set/2015

Provedores em nuvem devem ponderar o custo da infraestrutura requerida para executar sistemas e entregar serviços com relação aos benefícios que os fornecedores derivam. Estas considerações sobre custo-benefício estão levando fornecedores a considerar várias arquiteturas. Suas opções abrangem um espectro de arquiteturas sem compartilhamento até compartilhada por vários proprietários . Sem compartilhamento, o fornecedor oferece hardware, software e aplicativos que são totalmente dedicados a clientes individuais. Em multitenancy compartilhado, vários aplicativos de clientes são suportados usando um único aplicativo, e todo hardware e software subjacente é compartilhado.

A principal troca conforme você se move ao longo deste espectro arquitetural é isolamento versus densidade. Densidade é o número de sistemas e serviços que podem ser entregues para um conjunto específico de hardware e software. Quanto mais recursos são compartilhados, maior a densidade. Maior densidade reduz os custos do fornecedor. Ao mesmo tempo, compartilhamento aumentado reduz o nível de isolamento entre proprietários — os sistemas e serviços individuais que estão sendo entregues. Isolamento é o grau no qual um proprietário pode afetar a atividade e os dados de outros proprietários.

Para proprietários baseados em Java, posições ao longo do espectro arquitetural incluem compartilhamento ou não compartilhamento da JVM. Em qualquer arquitetura na qual o aplicativo de nível superior é compartilhado, a JVM deve ser compartilhada. O compartilhamento da JVM economiza memória e tempo do processador. Mas, com a tecnologia de JVM tradicional, o compartilhamento da JVM normalmente remove qualquer isolamento restante da camada de infraestrutura, requerendo que o próprio aplicativo de nível superior forneça esse isolamento. Este artigo apresenta o recurso de vários proprietários que está disponível para uso de avaliação na liberação da 7 R1 da IBM como uma visualização de tecnologia (consulte Recursos). Este recurso possibilita que implementações obtenham as vantagens do compartilhamento da JVM enquanto mantém melhor isolamento que pode ser atingido quando uma JVM tradicional é compartilhada.

Benefícios e custos da JVM com vários proprietários

O principal benefício de usar a JVM com vários proprietários é que as implementações evitam o consumo de memória que geralmente está associado ao uso de várias JVMs padrão. Estes custos adicionais têm várias causas:

  • O heap Java consome centenas de megabytes de memória. Os objetos de heap não podem ser compartilhados entre JVMs, mesmo quando os objetos são idênticos. Além disso, JVMs tendem a usar todo o heap que está alocado nelas, mesmo se precisarem da quantia de pico somente por um curto período.
  • O compilador Just-in-time (JIT) consome dezenas de megabytes de memória, porque o código gerado é privado e consome memória. O código gerado também utiliza ciclos do processador significativos para produzir, o que rouba o tempo dos aplicativos.
  • Artefatos internos para classes (muitos dos quais, tais como Sequência e Hashtable, existem para todos os aplicativos) consomem memória. Uma instância de cada um destes artefatos existe para cada JVM.
  • Cada JVM possui um encadeamento auxiliar de coletor de lixo por núcleo por padrão e também possui diversos encadeamentos de compilação. A atividade de compilação ou coleta de lixo pode ocorrer simultaneamente em uma ou mais das JVMs, o que pode ser abaixo do ideal à medida que as JVMs competirem pelo tempo do processador limitado.

Além de reduzir custos de memória e processamento, a JVM com vários proprietários também fornece melhor isolamento do que a execução de diversos aplicativos em uma única JVM tradicional.

Um outro benefício é que, após o primeiro proprietário da JVM compartilhada iniciar, aplicativos subsequentes requerem menos tempo para iniciar porque a JVM já está em execução. Tempos de início reduzidos são particularmente úteis para aplicativos de curta execução que geralmente são usados para script.

O principal custo do uso da JVM com vários proprietários é que proprietários são menos isolados do que vários aplicativos que são executados em JVMs separadas. Por exemplo, um travamento nativo na JVM com vários proprietários afeta todos os proprietários.

Além disso, uma taxa de desempenho pequena resulta do trabalho que a JVM deve fazer para implementar as extensões de vários proprietários. No entanto, o impacto desta ocorrência de desempenho diminui conforme o número de proprietários aumenta — porque você evita o custo do processador e da memória de executar várias JVMs no mesmo sistema.


Usando a JVM com vários proprietários

Para optar por compartilhar um tempo de execução com outros proprietários, o usuário do aplicativo inclui um único argumento, -Xmt, na linha de comando quando você ativa o aplicativo. Por exemplo:

java -Xmt -jar one.jar

O resultado é que o aplicativo se comporta (sujeito às limitações que descreveremos posteriormente neste artigo) como se ele estivesse em execução em uma JVM dedicada. Mas, na realidade, ele é executado lado a lado com outros aplicativos. As extensões na JVM com vários proprietários tornam a ativação desta maneira possível e fornecem isolamento entre os proprietários que estão compartilhando a JVM.

Quando um proprietário é ativado, o ativador da JVM localiza o daemon da JVM compartilhada existente (javad) ou o inicia, se necessário, conforme a Figura 1 ilustra:

Figura 1. Ativador da JVM localiza (e, se necessário, inicia) o daemon da JVM compartilhada automaticamente
Screen capture and diagram represents the JVM launcher locating and starting the shared JVM daemon (javad)

Quando um segundo proprietário é iniciado, esse proprietário localiza o daemon da JVM compartilhada existente e executa dentro dessa JVM, conforme a Figura 2 ilustra:

Figura 2. Ativador da JVM localiza e se conecta ao daemon da JVM existente
Screen capture and diagram represents the JVM launcher locating and connecting to the existing JVM daemon (javad)

O resultado é que uma cópia do código de autoinicialização que é comum a ambos os proprietários está ativa no processo javad . Esta organização permite que os proprietários compartilhem mais estruturas de tempo de execução.

É fácil executar aplicativos existentes usando a JVM com vários proprietários, porque somente mudanças limitadas na linha de comando são requeridas.


Atingindo o isolamento

Dois ou mais aplicativos que são executados na mesma JVM (convencional) normalmente não seriam isolados um do outro. A atividade de cada aplicativo afetaria o que o outro poderia fazer. Além disso, dados que podem ser compartilhados por meio de campos estáticos estariam acessíveis a todos os aplicativos. A JVM com vários proprietários aborda estes problemas de duas maneiras: isolamento de campo estático e restrições de recurso.

Isolamento de campo estático

Na JVM com vários proprietários, as partes invariáveis de classes são compartilhadas entre proprietários. Estas partes incluem o código compilado para métodos, estruturas de dados que a JVM usa e outros artefatos semelhantes. Este compartilhamento resulta em uma economia de memória porque cópias separadas que existiriam se várias JVMs fossem usadas são desnecessárias. No entanto, a JVM com vários proprietários fornece a cada proprietário sua própria cópia de campos estáticos. Devido ao isolamento de campo estático, — juntamente com o fato de que cada proprietário geralmente pode obter acesso somente às instâncias de objetos que ele criou, — cada proprietário pode acessar somente dados que estão associados a ele próprio. O resultado é o isolamento de dados entre proprietários.

Restrições de recurso: Lidando com comportamento inválido

Em um mundo perfeito, proprietários cooperariam e usariam recursos compartilhados de uma maneira apropriada. No entanto, erros e comportamentos malintencionados podem ocorrer neste mundo imperfeito. A JVM com vários proprietários fornece controles que podem ser configurados para limitar a capacidade de um proprietário portar-se mal e usar recursos de uma maneira que afete outros proprietários. Os valores que podem ser controlados incluem:

  • Tempo do processador
  • Tamanho de heap
  • Contagem de encadeamentos
  • E/S do arquivo: largura da banda de leitura, largura da banda de gravação
  • E/S do soquete: largura da banda de leitura, largura da banda de gravação

Estes controles podem ser especificados na linha de comandos -Xmt . Por exemplo:

  • -Xlimit:cpu=10-30 (10 por cento de CPU mínimo, 30 por cento máximo)
  • -Xlimit:cpu=30 (30 por cento de CPU máximo)
  • -Xlimit:netIO=20M (largura da banda máxima de 20 Mbps)
  • -Xms8m-Xmx64m (heap de 8 MB inicial, 64 MB máximo)

A documentação de Java 7 R1 inclui informações em todas as opções disponíveis (consulte Recursos).


Desempenho e área de cobertura

Como um teste para comparar o desempenho do aplicativo e a área de cobertura da memória em JVMs não compartilhadas e com vários proprietários, incluímos aplicativos em cada configuração de JVM até as trocas do sistema. (Quando ele troca consideramos que o sistema está "cheio"). No caso não compartilhado executamos o aplicativo em uma JVM separada e iniciamos uma nova JVM para cada aplicativo adicional. No caso de vários proprietários, executamos o aplicativo como um outro proprietário na única JVM com vários proprietários.

Tabela 1 e Tabela 2 mostram os resultados que obtivemos usando uma máquina com 1 GB de memória e uma JVM de 64 bits (a JVM de referências compactadas com a política de coleta de lixo balanceada em todos os casos). A coluna "Ajustado Manualmente" em ambas as tabelas mostra os resultados da JVM regular após ajustarmos manualmente as opções da linha de comando para tentar atingir a melhor densidade (Tabela 1) ou tempos de inicialização possíveis (Tabela 2). A coluna Padrão mostra os resultados para a JVM regular com as opções padrão.

A JVM com vários proprietários atingiu 1,2x a 4,9x vezes a densidade da JVM não compartilhada — dependendo do aplicativo, — conforme mostrado na Tabela 1:

Tabela 1. Número máximo de aplicativos simultâneos
AplicativoDescriçãoVários ProprietáriosAjustado ManualmentePadrãoMelhoria com a JVM de vários proprietários
Hello World Imprimir "HelloWorld" e, em seguida, suspender30973634,2X a 4,9X
JettyIniciar Jetty e aguardar solicitações34-181,9X
TomcatIniciar Tomcat e aguardar solicitações28-132,1X
JRubyIniciar JRuby e aguardar solicitações3226151,2X a 2,1X

Os resultados de densidade aumentada do compartilhamento dos artefatos chave, incluindo:

  • Classes e artefatos relacionados que são carregados pela autoinicialização e carregadores de classes de extensões, o objeto Classe de heap para cada uma das classes que os carregadores carregam e os objetos de heap que podem ser compartilhados com segurança entre proprietários (por exemplo, Sequências internas).
  • Código e metadados compilados com JIT para classes compiladas com JIT.
  • Heap: Um proprietário pode usar espaço que está disponível no heap quando ele não é requerido por outros proprietários.

A Tabela 2 mostra que atingimos 1,2x a 6x tempos de inicialização médios mais rápidos com a JVM com vários proprietários:

Tabela 2. Tempos de inicialização (primeiro/média)
AplicativoDescriçãoVários ProprietáriosAjustado ManualmentePadrãoMelhoria com a JVM de vários proprietários
Hello WorldImprimir "HelloWorld" e, em seguida, suspender5709/138ms514/400ms3361/460ms3.3X
JettyIniciar Jetty e aguardar solicitações7478/2116ms-6296/12624ms6X
TomcatIniciar Tomcat e aguardar solicitações9333/6005ms-7802/7432ms1,2X
JRubyIniciar JRuby e aguardar solicitações12391/3277ms14847/4101ms7849/6058ms1,25X a 1,8X

Na Tabela 2, é possível ver que o tempo de inicialização para a primeira instância do aplicativo é, em geral, mais lento na JVM com vários proprietários do que na JVM padrão. Este resultado é esperado porque a primeira instância incorre em algum atraso na inicialização adicional devido ao comprimento do caminho extra causado por extensões com vários proprietários. O tempo de inicialização de instâncias subsequentes é consistentemente melhor para a JVM com vários proprietários.

Estes resultados anteriores foram produzidos com JVMs de desenvolvimento, e mais melhorias são possíveis. Além disso, estes exemplos não levam em conta o compartilhamento que pode ocorrer quando aplicativos precisam de recursos em diferentes momentos. Em uma JVM típica, a área de cobertura da memória para cada JVM tende a crescer em direção ao máximo que ela requer durante seu tempo de vida. Na JVM padrão muita desta área de cobertura não é compartilhada. Com a JVM com vários proprietários, se os requisitos de recurso não se sobrepõem, a memória para heap e artefatos nativos podem ser compartilhados mais facilmente.


Limitações

Um objetivo da JVM com vários proprietários é poder executar todos os aplicativos Java sem modificação. Isto não é atualmente possível devido às limitações que as especificações de Java impõem e as limitações em nossa implementação atual. As principais limitações conhecidas incluem:

  • Nativos de Java Native Interface (JNI): A JVM de vários proprietários não fornece isolamento para nativos de JNI. Aplicativos com nativos de JNI fornecidos pelo usuário podem não ser seguros para execução com a JVM com vários proprietários. Tais aplicativos podem afetar a operação da JVM geral e dados de acesso de outros proprietários. Em casos que requerem "confiança" suficiente nos nativos (por exemplo, middleware bem conhecido), o risco pode ser aceitável. Além disso, o S.O. permite que o processo da JVM compartilhado carregue somente uma cópia de uma biblioteca compartilhada, que é onde nativos estão localizados. O resultado é que diversos proprietários não podem carregar os mesmos nativos se eles estão na mesma biblioteca compartilhada.
  • Java Virtual Machine Tool Interface (JVMTI): Como as atividades de depuração e criação de perfil afetam todos os proprietários que compartilham o servidor JVM, estes recursos atualmente não são suportados no JDK de vários proprietários. Esta é uma área na qual planejamos trabalhar mais.
  • Programas de GUI: Bibliotecas como SWT aparecem para manter o estado global na camada nativa e, portanto, não são suportadas no JDK de vários proprietários.

Conclusão

Este artigo apresentou a JVM com vários proprietários, como ela pode ser usada e os custos e benefícios de usá-la. Esperamos que tenhamos despertado seu interesse e que você experimente o beta e nos forneça um feedback. Acreditamos que a JVM com vários proprietários possa fornecer benefícios significativos para os ambientes corretos.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

  • Participe da comunidade do developerWorks. Conecte-se com outros usuários do developerWorks conforme você explora os blogs, fóruns, grupos e wikis orientados ao desenvolvedor.

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Tecnologia Java, Cloud computing
ArticleID=950990
ArticleTitle=Introdução a vários proprietários Java
publish-date=09252015