sistema Linux de 64 bits ou 32 bits?

Question

Eu tenho um servidor com 4 GB de RAM. Nele, tenho instalação de 32bit do Slackware Linux 12.1. Claro, não está usando todos os 4GB de RAM. Eu logo gostaria de aumentar a memória RAM para 8GB, e estou procurando uma maneira para o sistema usá-lo. O sistema é usado como um servidor de banco de dados e está sob alta carga durante o dia.

AFAICT, eu tenho duas opções: ficar com 32 bits e reconstruir o kernel e perder algum desempenho. Ou vá com 64 bits e reinstale tudo. Olhando para versões de 64 bits do Slackware, eu poderia rodar -current ou Slamd64.

Agora, para as perguntas:

1. Devo ficar com 32 bits ou ir com 64 bits?

2. Se eu for 64bit, devo usar o -current ou o Slamd64?

P.S. Espero receber respostas de alguém que esteja realmente usando qualquer uma dessas configurações em produção, não apenas copiar / colar algo que eu possa encontrar por meio do Google.

    

Answer 1

A maioria das CPUs modernas de 32 bits suportam PAE, o que permite que elas abordem mais de 4 GB de memória física, embora um único processo possa ver apenas 4 GB por vez. O kernel levará um pouco desse espaço de endereço. Esta postagem do Stackoverflow discute como o PAE funciona.

Muitos sistemas operacionais (incluindo Linux e MS Windows) oferecem uma API que permite manipular a MMU e as sobreposições de páginas dentro e fora do espaço de endereço virtual de um processo. Este recurso permite que você use memória extra para buffers de disco. No entanto, até onde sei, a única plataforma DBMS com suporte direto para isso é o MS SQL Server.

Memória adicional melhorará o desempenho de leitura do seu banco de dados (o que provavelmente melhorará sua taxa de transferência geral), mas o desempenho de gravação será limitado pela E / S. Se você tiver uma taxa de acertos baixa do cache do banco de dados (digamos, menos de 95%), a memória adicional provavelmente melhorará sua taxa de transferência geral. Caso contrário, você pode precisar examinar seu subsistema de disco (veja 1 abaixo).

Supondo que você precise ou possa se beneficiar de mais memória, a melhor abordagem é migrar para uma plataforma de 64 bits. Um servidor Xeon ou Opteron moderno permitirá que você instale até 32-144 GB, dependendo do modelo. Esta é provavelmente a sua melhor opção.

1. As SANs são boas para aplicativos transacionais. Para um aplicativo de alto volume, você deve ter um cache de gravação nos logs do banco de dados, mas talvez consiga fugir com o cache de write-back nos volumes de dados. Isso proporcionará um bom desempenho do leitor de logs, já que as gravações de dados aleatórias podem ser absorvidas pelo cache de bateria suportado pelo controlador e o controlador pode otimizar as gravações de disco para melhorar o rendimento.
   
   No entanto, esse arranjo tem modos de falha que podem deixar os volumes de dados inconsistentes (corrompidos). O uso de write-through nos volumes de log atenua isso (pois os logs não são vulneráveis a esses modos de falha). Praticamente isso limita você a um modelo de recuperação de restauração / roll-forward, de modo que funcionará somente se você puder tolerar uma (digamos) janela de recuperação de 4 horas.

Answer 2

Por memória de processo em sistemas de 32 bits é de 4 GB (que é dividido em 3 GB para o processo e 1 GB para o kernel, por padrão). Se você quiser que seu banco de dados possa acessar mais memória / por processo / você tem pouca escolha a não ser instalar um sistema operacional de 64 bits. Se o limite de 3 GB por processo não estiver incomodando, você também deve ficar com a configuração atual. Existem outras opções para a divisão 3GiB / 1GiB, mas elas não irão ajudá-lo em sua situação específica.

Outros limites de uso de memória por processo existem na forma do que é chamado de 'ZONE NORMAL', que nunca excede um pouco abaixo de 1GiB (896MiB para ser exato). Ao usar memória acima de 1GiB (ZONE HIGHMEM), o kernel precisa mapear essa memória para ZONE NORMAL, criando ainda mais possíveis afunilamentos. ZONE HIGHMEM não existe em um sistema de 64 bits, no qual tudo é ZONE NORMAL. Isso pode ser um bom motivo para usar o 64-bit também.

Quanto à parte 'tendo em produção': eu nem sei qual banco de dados você está usando. As minhas configurações do Oracle quase sempre executam 64 bits pela razão exata que afirmei acima. Eu não executo o Slackware na produção e não conheço ninguém que o faça.

Meus € 0,02: vá para 64 bits. A reinstalação é trivial comparada a possíveis benefícios.

    

Answer 3

Estou quase no mesmo cenário que você ( Existe alguma razão para usar o MySQL (e OS) de 64 bits em bancos de dados pequenos? ), e pelo que pude descobrir: o MySQL em 32bits não pode usar mais de 2GB de RAM por instância não importa o que você faz com o seu kernel.

Se você não estiver executando o MySQL, a situação pode ser diferente.

    

Answer 4

Acho que seria melhor fazer a pergunta: "Por que eu ficaria com um kernel de 32 bits?"

Eu passei todos os 64 bits em todos os hardwares que o suportam o mais rápido possível e não me arrependo. No trabalho, estamos rodando servidores PostgreSQL em 64-bit CentOS 5 com 32 GB de RAM e é muito bom (exceto por certas limitações com o próprio PostgreSQL, mas nada a ver com 32 ou 64 bits).

    

Answer 5

O principal perigo de rodar em um sistema de 32 bits com muita memória (mais de 8GB) é que o kernel pode acabar precisando alocar mais dados do que o que se encaixa no ZONE_NORMAL. Isso significa que a máquina pode efetivamente ficar sem memória, mesmo se ainda houver muita memória livre.

Outra questão é que o sistema recuperará de forma mais agressiva as estruturas de dados do kernel, como inodes em cache, cabeçalhos de buffer e outros caches que podem ajudar o desempenho do sistema.

A terceira questão é que, em um sistema de 32 bits, nenhum processo poderá usar efetivamente mais de 3 GB de memória. Isso significa que comprar mais de 4 GB de memória só é útil se nenhum dos processos em seu sistema precisar de toda a memória.

Por essas razões, é recomendável que, se você comprar um sistema com mais de 4 GB de memória, considere adquirir uma CPU de 64 bits e instalar um sistema operacional de 64 bits. A diferença de preço entre os sistemas de 32 e 64 bits é praticamente inexistente, então não há necessidade real de experimentar as dores de highmem mais ...

Mais informações ...

    

Answer 6

64 bits é o único caminho. No 32-bit, é um hack inventivo para chegar a 1GB, e um hack ainda maior para > 4GB. ^[1] Você diz que é um sistema muito carregado, então por que gastar ciclos em um bodge para chegar à memória quando ele pode ser mapeado diretamente?

A única razão pela qual você deve usar 32 bits é para suporte de fornecedores. Como você está no Slackware, duvido que isso seja uma razão.

_{^[1] Veja, por exemplo, " Limite de alocação de memória do Linux na plataforma de 32 bits ", do Guia de instalação e operações do UGS NX Nastran 5.0 , que menciona brevemente o 1GB barreira.}

    

Answer 7

64 bits + mais ram, se você estiver usando o innodb, defina o seu inndb_buffer_pool_size para cerca de 70-75% do total da memória RAM do sistema. Ajustar os tamanhos do cache. Se você estiver usando versões recentes do MySQL, configure seu diretório / tmp para usar tmpfs (memória), o que permitirá ao MySQL criar tabelas temporárias na memória, em vez de no disco físico. Certifique-se de que o MySQL esteja configurado para usar / tmp para tabelas temporárias.

    

Answer 8

Se você quiser aumentar sua memória, você não tem escolha, mas para executar um kernel de 64 bits. Você pode manter um userland de 32 bits, se quiser, mas cada processo será limitado a um máximo de 2 GB (talvez 3 GB). Você não precisa reinstalar tudo, apenas um novo kernel.

    

Answer 9

A maioria das pessoas responde à pergunta 1, mas deixe-me entrar na questão # 2.

Se você escolher rodar o Slackware de 64 bits, você só tem uma escolha: o Slackware64. O Slamd64 era uma porta não oficial do Slackware que deixou de ser necessária agora que o Slackware tem uma porta oficial de 64 bits. Em termos de versões, você tem a escolha das versões 13.0, 13.1, 13.37 e -current do Slackware64. Observe também que o 14.0 provavelmente será lançado em breve, então você também pode esperar por isso.