Qual é o espaço de pilha máximo Java para SuSE Linux

Question

Esta questão está relacionada com a Java se recusa a iniciar - não poderia Resrve suficiente espaço para o objeto Heap e deve ser fácil o suficiente para descobrir. Contudo; minhas pesquisas não produziram nada de útil.

Essencialmente temos 2 32 bit do OS (RedHat e SuSE) em máquinas diferentes com o mesmo hardware. Ambos usam o mesmo JVM ambos executar a mesma linha de comando. RedHat obras perfeitamente bem, mas SuSE relata Não há memória suficiente.

Nós só precisamos saber se isso é uma limitação da versão do SuSE estamos usando ou se é outra coisa.

'cat / proc / version' nos dá:

Linux version 2.6.5-7.244-bigsmp (geeko@buildhost) (gcc version 3.3.3 (SuSE Linux)) #1 SMP Mon Dec 12 18:32:25 UTC 2005

'uname -a' nos dá o seguinte em ambos os tipos de máquinas:

UTC 2005 i686 i686 i386 GNU/Linux

Answer 1

O limite de memória JVM está relacionada a maior livre contígua bloquear disponível, não é a quantidade de memória livre. O limite varia de cerca de 1,4 GB para um pouco mais de 2,0 GB, e depende de onde seus puts sistema operacional várias coisas na memória. Eu não sei os detalhes de onde Redhat ou Suse material de carga na memória, mas pode ser que suse está mapeando alguns biblioteca para um endereço no meio da RAM, onde Redhat pode mapeá-lo no final (especulação).

E lembre-se que seu uso de memória real em java é mais de o que você especificar para Xmx. As outras configurações de memória também afetam o tamanho da sua pilha (como permgen). Por isso, também pode ser que o espaço perm em Suse tem um padrão larget que em Redhat.

Além disso, dependendo do perfil de alocação de memória do seu aplicativo, você pode sair com um tamanho da pilha menor e diferentes opções de lixo coleta. Existem alguns detalhes aqui ( http://java.sun.com/performance/ referência / documentos técnicos / tuning.html ) e outros locais. Por exemplo, se você alocar um monte de blocos pequenos, temporários, você vai querer diferentes configurações de GC do que se você tem um monte de bit, objetos de vida longa.

Em relação à questão ligada, por que não usar Redhat? Isso pode ser uma solução simplista, mas eu garanto que vai resolver o seu problema mais rapidamente do que se aprofundar profundamente no mundo arcano de ajuste java e gerenciamento de memória SO: P

Answer 2

Em primeiro lugar, você é louco para ser executando um sistema operacional de 32 bits quando você tem essa pressão espaço de endereço muito. Migrar para a JVM de 64 bits no Linux de 64 bits. Quanto tempo você já desperdiçado tentando diagnosticar este problema que você deve ter suspeitado desde o início, iria embora com o maior espaço de endereço de um sistema de 64 bits?

Em segundo lugar, é sabido que, de todo o Linux fornecedores Red Hat tem a maioria dos engenheiros do kernel na equipe e faz alguns ajustes graves para os kernels em seus produtos RHEL. Estes incluem muitas vezes patches para grandes cargas de trabalho como a sua (bem, é um grande carga de trabalho para um sistema de 32 bits, não é nada especial em 64-bit). Portanto, há alguma chance a razão última análise, é que RHEL tem outros clientes fazendo a mesma coisa louca como você e você está beneficiando de trabalho que fizeram para apoiar os clientes.

Finalmente, porém, desde que eu suspeito que você vai insistir em tentando encontrar uma maneira de fazer isso em 32 bits SuSE eu gostaria de salientar que o Linux oferece uma variedade de espaço de endereço trade-offs em 32-bit x86, e é possível (mas não certo) que seus sistemas SuSE só tem um trade-off diferente selecionado. Se você pode abrir a configuração dos núcleos rodando (muitas vezes em / boot / config ....), então você pode comparar as configurações como highmem.

A opção convencional até alguns anos atrás era 2: 2 divisão, que é userspace é limitado a 2GiB de espaço de endereço, uma solução fácil para o programa e tem eficiência decente, mas neste cenário, obviamente, você não pode ter o seu pedido pilha, uma vez que não deixaria espaço para o texto do programa, pilha etc. Mais recentemente, a tendência tem sido para 3: 1 (similar ao interruptor Windows / 3GB) que amplia espaço de endereço do espaço do usuário com o custo de enfiar o próprio kernel do sistema operacional em menos espaço que potencialmente provoca seus próprios problemas. Este trabalho poderia, mas seria muito apertado para que eu também não ficaria surpreso se ele não funciona para os seus empregos. Finalmente mais recente Linux kernels também oferecem uma opção onde você começa 4GiB userspace de 32 bits, o que pode ser suficiente para fazer os seus trabalhos de executar de forma confiável, a um custo significativo desempenho desde então, obviamente, do espaço do usuário e do kernel endereços não podem co-existir.

Para tentar isso você precisa de um novo kernel. Você pode ser capaz de instalar apenas fornecido pelo SuSE (ver se eles oferecem outros para escolher opção, por exemplo, um "PAE") ou você pode ter de compilar seu próprio, caso em que ele provavelmente invalida seu contrato de suporte.

Mas, realmente, você deve apenas ir com a opção 1, mude para uma JVM de 64 bits e colocar os pés para cima.