ColdFusion limitado a 1.8Gb de RAM

Poucos sabem, mas a arquitetura x86/32bits (Linux/Windows) oferece uma limitação importante para aplicações Java no tocante ao consumo de memória RAM. A arquitetura 32 bits pode endereçar nativamente no máximo 4GB de memória RAM (2^32 = 4.2 bilhões ~ 4Gb). Destes 4GB, metade (2GB) é reservada para o funcionamento do kernel e a outra metade (2GB) fica disponível para outros processos e aplicações. Não vou entrar no mérito da questão do porquê isso ocorre, até porque não me sinto seguro para comentar sobre algo que não pude estudar muito, porém adianto que existem algumas alternativas no Windows 2k/2k3/XP (/PAE) para endereçar um número maior de memória ao invés de 2GB, o mesmo é válido para os kernels mais novos do Linux (2.4 para cima), mas até agora não compreendi muito bem o que isso pode mudar em relação ao suporte à Java.

O fato é que a pilha (heap) do JVM utiliza a memória de forma contínua, alocando um bloco unitário, como um único processo, limitando o uso de RAM por uma instância JVM única à 1.8GB (os 200Mb restantes são usados pelo JVM para atender processos internos, como o garbage collection e afins). Estes são números aproximados, não há uma métrica precisa.

Em resumo: se você está pensando em comprar um servidor na arquitetura x86/32bits (Intel/AMD) e pretende instalar mais do que 4GB de memória RAM pense e estude esta questão, pois você poderá estar comprando memória extra (e cara) que não fará a menor diferença, pois não poderá ser usada pelo JVM.

Se a sua aplicação precisar de algo maior (o que está se tornando bastante comum hoje em dia), a solução é partir para a arquitetura 64bits (tanto em Windows quanto em Linux), arquitetura que graças à AMD está se tornando mais popular e viável ($) para os nossos bolsos. Em alguns casos você pode optar pelo modelo híbrido 32/64bits (Atlhon64) e ficar pronto para quando for a hora de migrar. Caso estas não sejam uma opção, você pode adotar um modelo de cluster, com quantas máquinas (inclusive um falso cluster, com várias instâncias dentro de um mesmo servidor) forem necessárias para suportar seu site/aplicação. Uma continha gostosa de se conhecer: na arquitetura 64bits teríamos: 2^64 = alguns terabits para muitos anos…).

O interessante é saber que a arquitetura 32bits Sparc (Risc?) da Sun não apresenta este problema com o JVM. Que diferença faz ser dona da tecnologia não? :o)

Alguns links para ajudar a compreender o problema:

– Maximum JVM heap size greater than 1.8GB will prevent ColdFusion MX from starting;
– The 4GB Windows Memory Limit: What does it really mean?;
– 1.8GB Heap Limit in ColdFusion MX;
– How to avoid 2GB memory limit of JVM in Linux (bastante informativo);
– http://forum.java.sun.com/thread.jsp?thread=525731&forum=37&message=2521405

E claro, o bom e velho Google.

The dark side of ColdFusion

Esta semana foi uma semana dura, cheia de decisões e de coisas para resolver, uma semana “dark” em resumo (mas com frutos futuros excelentes). Por isso estive literalmente em alpha, perdido e sem tempo de ler muita coisa, especialmente o que andou rolando no “jet-set” da blogsfera. Em tempo: um software muito legal – agora eu não posso mais dizer qual (antes podia) – também entrou em alpha esta semana… (segunda fase). De qualquer maneira não precisa de cochicho, a informação é pública, não estou quebrando nenhum NDA.

Rebobinando a fita encontrei este excelente artigo (via Forta Blog) escrito por um programador PHP de longa data (incluindo a alcunha preconceituosa em relação ao mundo “proprietário”) e que mudou de opinião ao usar o ColdFusion com um pouco mais de seriedade.

Pode ter sido uma imposição do empregador dele, mas que ele gostou da coisa, ah gostou.

Leitura recomenda: Making the Case for ColdFusion