Uso de O_DIRECT no Linux

Question

Se esta questão for muito orientada para programadores, me avise. Gostaria de saber se há pessoas familiarizadas com o sinalizador O_DIRECT para a chamada do sistema open () no Linux 2.6? Linus deprecia seu uso, no entanto, a escrita de arquivos de alto desempenho parece indicar seu uso. Eu gostaria de saber de qualquer experiência e recomendações do mundo real.

Mais informações: O aplicativo que estou usando faz manter seu próprio cache e, ao fazê-lo, atinge uma média de 5x ou mais de velocidade. Ao gravar no arquivo, o conteúdo do cache deve ser gravado no cache do sistema de arquivos, o que parece redundante e um problema de desempenho.

    

Answer 1

Ok, você pede experiências, isso torna a questão um pouco subjetiva e argumentativa, mas passável.

Linus disse que, referindo-se aos usos que as pessoas geralmente atribuem ao O_DIRECT, e para esses usos, o IMO Linus está mais correto. Mesmo se você direcionar E / S, não poderá transferir dados de / para dispositivos diretamente para suas instruções de programa, precisará de um buffer preenchido (pelo programa ou dispositivo) e transferido por meio de uma chamada de sistema para a outra extremidade. Além disso, para torná-lo eficiente, você não vai querer reler algo que acabou de ler, caso precise dele novamente. Então você precisa de algum tipo de cache ... e é exatamente isso que o kernel fornece sem O_DIRECT, um cache de páginas! Por que não usar isso? Ele também vem com benefícios se mais processos quiserem acessar o mesmo arquivo ao mesmo tempo, seria um desastre com O_DIRECT.

Dito isto, O_DIRECT tem seus usos: Se por algum motivo você precisar obter dados diretamente do dispositivo de bloco. Não tem nada a ver com desempenho.

As pessoas que usam O_DIRECT para desempenho geralmente vêm de sistemas com algoritmos de cache de página inválidos, ou sem mecanismos de conselhos POSIX, ou até mesmo pessoas repetindo sem pensar o que outras pessoas disseram. Para evitar esses problemas, O_DIRECT foi uma solução. O Linux, OTOH, tem a filosofia de que você deve corrigir o verdadeiro problema subjacente, e o problema subjacente eram os sistemas operacionais que faziam um trabalho ruim com o cache de páginas.

Eu usei O_DIRECT para uma implementação simples de cat para encontrar uma memória erro na minha máquina. Este é um uso válido para O_DIRECT. Isso não tem nada a ver com desempenho.

    

Answer 2

Na verdade, O_DIRECT é necessário para evitar

• poluição do cache - às vezes você sabe que não faz sentido sobrecarregar o cache, por exemplo. g. ao lidar com arquivos realmente grandes, digamos 64 GiB quando há apenas 2 GiB de RAM. O arquivo torrent de 32 GiB que um usuário decidiu verificar não parece ser um bom candidato para o armazenamento em cache. É apenas uma atividade extra com sua própria sobrecarga. E isso pode fazer com que alguns dados realmente úteis sejam removidos do cache.
• cache duplo - para e. g. alguns RDBMSes (MySQL para mencionar) permitem definir seu próprio cache. Bancos de dados supostamente sabem melhor como fazer o cache e o que, do que a memória virtual do kernel, que não sabe nada sobre planejamento de SQL e assim por diante.

- o que não é bom, como parece. E O_DIRECT não significa ser mais rápido, muitas vezes não é .

    

Answer 3

Observe que o uso de O_DIRECT está sujeito a falhas em novos kernels com sistemas de arquivos mais novos. Veja este relatório de bug por exemplo. Portanto, não apenas o uso é duvidoso, como provavelmente não funcionará na próxima geração de distribuições Linux. Então, eu não apostaria o desempenho do meu código nele, mesmo que você possa provar que ele pode ter um benefício.

    

Answer 4

Em relação ao que @Juliano já disse.

Verificação posix_fadvise se o problema real for mau comportamento do algoritmo de cache do sistema de arquivos subjacente, você pode tentar dar conselhos, como você vai usar o sistema de arquivos. Para fs bem implementados, deve aumentar o desempenho. (Aqui há um link para outro tópico que aborda considerações semelhantes link )

    

Answer 5

Tem muito a ver com desempenho.

Um exemplo interessante está no mongodb usando o mecanismo mmap. O_DIRECT é melhor usado, como outros afirmaram, onde é improvável que os dados sejam lidos por algum tempo. No mongodb, o diário de banco de dados é escrito usando O_DIRECT enquanto os dados e índices gravados são manipulados pelo mecanismo de cache de página (pdflush) porque, embora O_DIRECT ofereça menos largura de banda, também significa menos latência e, portanto, reduz a perda de dados no caso de um interrupção inesperada (pane do kernel, disco ou falha de energia). Observe que ainda há buffer antes que uma gravação O_DIRECT seja confirmada para armazenamento não-volátil, isso apenas reduz a perda de dados.

Outra característica importante do O_DIRECT é que ele fornece mais controle sobre a seqüência das gravações. Novamente, isso não garante a ordem das gravações (a menos que você tenha um controlador de disco de cache não volátil e esteja usando o programador fifo, mas elas têm suas próprias complicações). Portanto, embora o mysql use O_DIRECT para seus dados / índices, assim como o journalling, ele pode esperar que o último seja comprometido primeiro.

Mas é importante lembrar que O_DIRECT quebra a equidade na alocação de recursos. Uma das razões pela qual seu aplicativo é acelerado é que ele está reduzindo a velocidade de outras coisas.