Temos um servidor com 64 GB de RAM total, os aplicativos normalmente usam no máximo 30 GB dessa RAM disponível. Um desses aplicativos lida com muitos arquivos simples e estamos tendo problemas de rendimento, ou seja, aguardando E/S de disco. Ao explorar possíveis soluções surgiu a ideia de um disco RAM. O problema que tenho com um disco RAM é a volatilidade inerente.
Encontrei documentação separada sobre discos RAM, configuração RAID 1 e volumes espelhados lógicos para agruparfísicodiscos, mas não consigo encontrar nenhuma documentação que sugira se alguma dessas soluções de replicação de disco pode ser usada com um disco RAM. Mais importante ainda, uma vez que a ideia é ter o disco RAM disponível para leitura/gravação e fazer com que o disco físico "sombreie" o disco RAM, acompanhando as gravações, gostaríamos que o disco RAM fosse o disco "primário" para todos lê/escreve.
Para observar, gostaríamoscomopara evitar apenas o cache de RAM dos arquivos com o sistema operacional, mas se conseguirmos o mesmo desempenho de um disco RAM independente, isso pode funcionar. Inicialmente evitamos isso porque muitas vezes certos arquivos não serão acessados por longos períodos de tempo, mas ainda precisam da velocidade de leitura/gravação sob demanda.
Responder1
Para observar, gostaríamos de evitar apenas o armazenamento em cache da RAM com o sistema operacional, mas se conseguirmos obter o mesmo desempenho de um disco RAM independente, isso poderá funcionar. Inicialmente evitamos isso porque muitas vezes certos arquivos não serão acessados por longos períodos de tempo, mas ainda precisam da velocidade de leitura/gravação sob demanda.
Você poderia usarvmtouchpara resolver seu problema.Este é um utilitário que permite fixar certos arquivos ou até mesmo diretórios inteiros e tudo abaixo deles no cache da página para que não sejam despejados, mesmo que não sejam acessados por longos períodos de tempo (que foi o seu motivo inicial para não simplesmente dependendo do cache da página). Isso requer no máximo a mesma quantidade de memória que o seu disco RAM, ou menos na prática. Você ainda usará o cache de páginas, mas isso resultará em desempenho semelhante ao uso de um disco RAM para tudo (na verdade, desempenho superior, pois o driver MD não estará envolvido).
Responder2
Isso poderia ser hackeado em conjunto, mas é uma má ideia e provavelmente tem vários problemas de confiabilidade e facilidade de manutenção.
Acho que um RAID1 de disco RAM e disco físico seria limitado ao desempenho do disco físico, pois parte da funcionalidade do RAID1 é garantir que ambas as cópias estejam sincronizadas.
Para leituras, pode haver algum benefício, porque o driver MD pode distribuir leituras entre diferentes dispositivos.
Possíveis etapas para criar isso:
- Crie um arquivo vazio, que tenha o tamanho do array que você deseja suportar
- Use
losetuppara criar um dispositivo de bloco a partir do arquivo. - Use
mdadmpara criar a matriz com o dispositivo de bloco recém-criado e a partição do disco rígido correspondente. - Crie um sistema de arquivos no novo array MD.
Eu não tentei isso sozinho, então é apenas um exemplo teórico de como isso poderia ser feito.
Responder3
Primeiro, um disco RAM é quasenuncaa resposta correta no Linux. Por ser um dispositivo de bloco, você acaba com qualquer leitura tendo que passar pela camada de bloco, pelo sistema de arquivos e pela camada VFS regular,eos dados acabarão armazenados em cache na RAM, além de serem armazenados no disco RAM. Essa duplicação de dados, bem como o número de camadas adicionais envolvidas, são a razão pela qual o tmpfs existe no Linux. Em vez de envolver a camada de bloco, um sistema de arquivos tmpfs apenas armazena dados diretamente no cache da página, evitando toda a complexidade extra. Também acontece o dimensionamento automático com base na quantidade de dados armazenados nele (em vez de ter que ter o tamanho definido antecipadamente) e pode até aproveitar o espaço de troca. Se você acha que precisa de um ramdisk, então 99% das vezes você deveria usar o tmpfs.
Agora, no que diz respeito às soluções reais...
Se todos os seus dados realmente cabem na RAM, é muito melhor fixar tudo na RAM, usando uma ferramenta comovmtouchou fazendo com que o aplicativo mapeie todos os arquivos e depois chame mlock em todas as regiões mapeadas.
Se nem todos os seus dados cabem na RAM, você tem duas opções realistas:
- Armazene os dados compactados em disco, de preferência usando um sistema de arquivos que forneça compactação transparente, como BTRFS, F2FS ou ZFS. Desde que você tenha uma CPU razoavelmente rápida, isso normalmentereduziro tempo necessário para ler um arquivo grande, ao custo de exigir um pouco mais de tempo de CPU. A melhoria geralmente é proporcional à qualidade da compactação dos dados, mas em muitos casos pode facilmente se traduzir em uma melhoria de 30% ou mais.
- Considere investir em armazenamento mais rápido. O suficiente para apenas substituir o armazenamento existente ou uma quantidade menor que você pode usar combcachepara acelerar funcionalmente seu armazenamento existente.
Responder4
Se precisar de persistência, um RAMDISK não é a solução correta.
Eu sugiro fortemente investir em um par de discos NVMe rápidos (leia-se: nível empresarial, com proteção contra perda de energia) para colocar em um array RAID1 clássico (espelhado).