Por padrão, todas as gravações são assíncronas.
Você pode configurá-los para serem síncronos no nível de aplicativo O_DIRECT|O_SYNC open(2) flags ou no sistema de arquivos um ( -o sync opção do comando mount).
O CentOS está usando gravação síncrona ou assíncrona? Existe alguma maneira de verificar ou mudar isso?
Por padrão, todas as gravações são assíncronas.
Você pode configurá-los para serem síncronos no nível de aplicativo O_DIRECT|O_SYNC open(2) flags ou no sistema de arquivos um ( -o sync opção do comando mount).
De acordo com a página da Red Hat (bastante antiga) 12.5. Verificando o uso de E / S assíncrona , a E / S assíncrona é suportada usando o libaio. Os aplicativos são ou não estão vinculados a essa biblioteca. Não há nada mencionado sobre ativação ou desativação: aplicativos simplesmente usam a biblioteca. A página diz que você pode verificar o uso inspecionando /proc/slabinfo .
Na minha máquina do CentOS 6, com 2466 arquivos em /usr/bin , apenas 3 estão vinculados à libaio:
Existem programas que usam esse recurso, mas não muitos. Algumas pessoas confundem isso com o cache de buffer.
Leitura adicional:
I/O operations in UNIX and Linux systems typically go through the file system cache. Although this doesn't represent a problem in itself, this extra processing does require resources. Bypassing the file system cache reduces CPU requirements, and frees up the file system cache for other non-database file operations. Operations against raw devices automatically bypass the file system cache.
Como / u / jiliagre mencionado , você cat força O_SYNC com o arquivo aberto ou em montagem -time via -o sync flag, por dispositivo (você pode remontar a maioria dos pontos de montagem abertos com mount -o remount,sync <mtpt> . Alternativamente, você pode dizer ao sistema para agendar imediatamente um flush toda vez que fizer uma gravação (que "suga uma página"). / p>
Quando o modo de sincronização não está ativado, os algoritmos complicados de write-back entram em ação. O algoritmo de write-back foi projetado para limitar operações IO. Ele pressupõe que o usuário prefira que o sistema execute liberações para o disco apenas ocasionalmente: após um prazo ou quando houver um limite de páginas "sujas" para liberar. Para fazer o flushing, simplesmente atribui algum trabalho e "acorda" o (s) thread (s) do kernel pdflush .
Existem algumas variáveis do sistema que você pode manipular via sysctl e /proc/ para controlar o comportamento do write-back. Você está interessado principalmente em:
vm.dirty_background_ratio = 0
que essencialmente força cada escrita suja a acordar e ser liberada; e / ou
vm.dirty_writeback_centisecs = 1
que garante que páginas sujas sejam liberadas a cada 1/100 de segundo. Você pode ficar tentado a definir o último como 0, mas isso realmente desativará o cronômetro. Você também pode ser tentado a definir vm.dirty_ratio para 0, mas pelo menos em 2.6.25, isso é menor que 5% e não o ajudará aqui.
Advertência # 1: O algoritmo de write-back emprega comportamento limitador de taxa. Eu não estou completamente certo do algoritmo, já que é complicado, mas se tantas páginas precisarem ser liberadas para o disco, o pdflush será chamado em um número definido, e então o pdflush será agendado no próximo segundo. Eu acho que se subseqüente ao primeiro pedaço enviado para ser pdflushed, outra página é suja, então outro pedaço será imediatamente agendado antes do temporizador de 1 segundo.
Advertência # 2: ainda não será completamente síncrona, porque o pdflush envia seus dados para o escalonador IO em nível de bloco, o que empurra a operação de gravação para uma "fila". Mas não tenho certeza se isso é diferente do que você obtém com o modo de sincronização.
PS: Não se esqueça de olhar e votar este belo responder .
Tags filesystems hard-disk