Arquivo com backup, memória compartilhada bloqueada e interação com disco

Question

O Varnish, um acelerador de HTTP, usa um arquivo SHM com 80 MB de backup que é mlock () ed na memória. Os documentos em verniz recomendam armazenar o arquivo em tmpfs para evitar acesso desnecessário ao disco. No entanto, se o arquivo inteiro estiver bloqueado na memória, o kernel do Linux ainda gravará no arquivo de apoio?

Eu tentei monitorar isso usando inotify e fatrace, mas como essa interação acontece presumivelmente dentro do kernel, nenhuma atividade de arquivo era visível para essas ferramentas. Existe claramente algum tipo de atualização acontecendo tanto no arquivo quanto no sistema de arquivos, já que monitorar o arquivo de apoio com ls mostrou a mudança do horário do arquivo, e o sha1sum mostrou que o conteúdo estava mudando, mas isso realmente envolve acesso ao disco ou está acontecendo? memória?

Basicamente eu estou tentando evitar ter que fazer a solução tmpfs, como o uso de SHM para trás SHM parece ser uma solução feia para um problema que pode até não existir.

    

Answer 1

O Varnish parece usar um arquivo mapeado na memória para sua memória compartilhada (em vez de, por exemplo, POSIX shm_open ). De a fonte :

loghead = mmap(NULL, heritage.vsl_size,
    PROT_READ|PROT_WRITE,
    MAP_HASSEMAPHORE | MAP_NOSYNC | MAP_SHARED,
    heritage.vsl_fd, 0);

No BSD, MAP_NOSYNC solicita que o kernel não grave os dados compartilhados no disco, a menos que seja forçado (por exemplo, para liberar memória). Quando é mlocked também, isso quase nunca deveria acontecer. Infelizmente, o Linux não suporta MAP_NOSYNC .

Assim, o Linux acabará rotineiramente escrevendo páginas sujas (alteradas) do cache para o disco. Colocar o cache em um tmpfs evitará isso. Assim também o Varnish usaria memória compartilhada POSIX ou SysV (na verdade, a memória compartilhada POSIX é implementada no Linux com um tmpfs montado em /dev/shm , portanto, o uso do tmpfs deve ser bom).