O mau desempenho do MongoDB e do ZFS: disco sempre ocupado com leituras ao fazer somente gravações

Question

Tenho grandes problemas de desempenho usando o MongoDB (acredito que seja o mmapped DB) com o ZFSonlinux.

Nosso Mongodb é quase só escreve. Em réplicas sem ZFS, o disco está completamente ocupado por picos de aproximadamente 5 segundos, quando o aplicativo grava no banco de dados a cada 30 segundos e não há atividade de disco no meio, então considero isso como o comportamento de linha de base a comparar. Em réplicas com o ZFS, o disco está completamente ocupado todo o tempo, com as réplicas se esforçando para manter-se atualizado com o primário do MongoDB. Tenho a compactação lz4 ativada em todas as réplicas e a economia de espaço é ótima, portanto, deve haver muito menos dados para acessar o disco

Então, nesses servidores ZFS, eu primeiro tive o registro padrão = 128k. Em seguida, limpei os dados e configurei o tamanho do registro = 8k antes de ressincronizar os dados do Mongo. Então eu limpei novamente e tentei recordsize = 1k. Eu também tentei recordsize = 8k sem checksums

No entanto, não resolveu nada, disco sempre foi mantido 100% ocupado. Apenas uma vez em um servidor com recordsize = 8k, o disco estava muito menos ocupado do que qualquer réplica não ZFS, mas depois de tentar configurações diferentes e tentar novamente com recordsize = 8k, disco foi 100%, não consegui ver o bom comportamento anterior, e não poderia ver em qualquer outra réplica.

Além disso, deve haver quase apenas gravações, mas veja que em todas as réplicas sob diferentes configurações, o disco está completamente ocupado com 75% de leituras e apenas 25% escreve

(Nota, eu acredito MongoDB é mmapado DB. Disseram-me para experimentar MongoDB no modo AIO, mas eu não encontrei como configurá-lo, e com outro servidor executando o MySQL InnoDB percebi que o ZFSonLinux não suportava AIO de qualquer maneira.)

Meus servidores são o kernel 2.6.32-431.5.1.el6.x86_64 do CentOS 6.5. spl-0.6.2-1.el6.x86_64 zfs-0.6.2-1.el6.x86_64

#PROD 13:44:55 root@rum-mongo-backup-1:~: zfs list
NAME                     USED  AVAIL  REFER  MOUNTPOINT
zfs                      216G  1.56T    32K  /zfs
zfs/mongo_data-rum_a    49.5G  1.56T  49.5G  /zfs/mongo_data-rum_a
zfs/mongo_data-rum_old   166G  1.56T   166G  /zfs/mongo_data-rum_old

#PROD 13:45:20 root@rum-mongo-backup-1:~: zfs list -t snapshot
no datasets available

#PROD 13:45:29 root@rum-mongo-backup-1:~: zfs list -o atime,devices,compression,copies,dedup,mountpoint,recordsize,casesensitivity,xattr,checksum
ATIME  DEVICES  COMPRESS  COPIES          DEDUP  MOUNTPOINT               RECSIZE         CASE  XATTR   CHECKSUM
  off       on       lz4       1            off  /zfs                        128K    sensitive     sa        off
  off       on       lz4       1            off  /zfs/mongo_data-rum_a         8K    sensitive     sa        off
  off       on       lz4       1            off  /zfs/mongo_data-rum_old       8K    sensitive     sa        off

O que poderia estar acontecendo lá? O que devo procurar para descobrir o que o ZFS está fazendo ou qual configuração está mal definida?

EDIT1:
hardware: são servidores alugados, 8 vcores no Xeon 1230 ou 1240, 16 ou 32 GB de RAM, com zfs_arc_max=2147483648 , usando o hardware HP RAID1. Portanto, o zpool do ZFS está em / dev / sda2 e não sabe que existe um RAID1 subjacente. Mesmo sendo uma configuração abaixo do ideal para o ZFS, eu ainda não entendo porque o disco está sufocando nas leituras enquanto o DB só grava.
Eu entendo as muitas razões, que não precisamos expor aqui novamente, que isso é bad and bad, ... para o ZFS, e em breve teremos um servidor JBOD / NORAID que eu posso fazer os mesmos testes com a implementação RAID1 do próprio ZFS na partição sda2, com as partições /, / boot e swap fazendo o software RAID1 com mdadm.

    

Answer 1

Isso pode soar um pouco louco , mas eu dou suporte a outro aplicativo que se beneficia dos atributos de gerenciamento de volume do ZFS, mas não funciona bem no sistema de arquivos nativo do ZFS.

Minha solução?!?

XFS no topo de ZFS zvols .

Por quê?!?

Como o XFS apresenta um bom desempenho e elimina os problemas específicos do aplicativo que eu estava enfrentando com o ZFS nativo. Os zvols do ZFS permitem que eu provisione volumes thin-thin, inclua compactação, habilite instantâneos e faça uso eficiente do pool de armazenamento. Mais importante para o meu aplicativo, o armazenamento em cache do ARC do zvol reduziu a carga de E / S nos discos.

Veja se você pode seguir esta saída:

# zpool status
  pool: vol0
 state: ONLINE
  scan: scrub repaired 0 in 0h3m with 0 errors on Sun Mar  2 12:09:15 2014
config:

        NAME                                            STATE     READ WRITE CKSUM
        vol0                                            ONLINE       0     0     0
          mirror-0                                      ONLINE       0     0     0
            scsi-SATA_OWC_Mercury_AccOW140128AS1243223  ONLINE       0     0     0
            scsi-SATA_OWC_Mercury_AccOW140128AS1243264  ONLINE       0     0     0
          mirror-1                                      ONLINE       0     0     0
            scsi-SATA_OWC_Mercury_AccOW140128AS1243226  ONLINE       0     0     0
            scsi-SATA_OWC_Mercury_AccOW140128AS1243185  ONLINE       0     0     0

ZFS zvol, criado com: zfs create -o volblocksize=128K -s -V 800G vol0/pprovol (observe que os instantâneos automáticos estão ativados)

# zfs get all vol0/pprovol
NAME          PROPERTY               VALUE                  SOURCE
vol0/pprovol  type                   volume                 -
vol0/pprovol  creation               Wed Feb 12 14:40 2014  -
vol0/pprovol  used                   273G                   -
vol0/pprovol  available              155G                   -
vol0/pprovol  referenced             146G                   -
vol0/pprovol  compressratio          3.68x                  -
vol0/pprovol  reservation            none                   default
vol0/pprovol  volsize                900G                   local
vol0/pprovol  volblocksize           128K                   -
vol0/pprovol  checksum               on                     default
vol0/pprovol  compression            lz4                    inherited from vol0
vol0/pprovol  readonly               off                    default
vol0/pprovol  copies                 1                      default
vol0/pprovol  refreservation         none                   default
vol0/pprovol  primarycache           all                    default
vol0/pprovol  secondarycache         all                    default
vol0/pprovol  usedbysnapshots        127G                   -
vol0/pprovol  usedbydataset          146G                   -
vol0/pprovol  usedbychildren         0                      -
vol0/pprovol  usedbyrefreservation   0                      -
vol0/pprovol  logbias                latency                default
vol0/pprovol  dedup                  off                    default
vol0/pprovol  mlslabel               none                   default
vol0/pprovol  sync                   standard               default
vol0/pprovol  refcompressratio       4.20x                  -
vol0/pprovol  written                219M                   -
vol0/pprovol  snapdev                hidden                 default
vol0/pprovol  com.sun:auto-snapshot  true                   local

Propriedades do dispositivo de bloqueio ZFS zvol. Volume de 900 GB (tamanho real de 143 GB no disco):

# fdisk -l /dev/zd0

Disk /dev/zd0: 966.4 GB, 966367641600 bytes
3 heads, 18 sectors/track, 34952533 cylinders
Units = cylinders of 54 * 512 = 27648 bytes
Sector size (logical/physical): 512 bytes / 131072 bytes
I/O size (minimum/optimal): 131072 bytes / 131072 bytes
Disk identifier: 0x48811e83

    Device Boot      Start         End      Blocks   Id  System
/dev/zd0p1              38    34952534   943717376   83  Linux

Informações XFS no dispositivo de bloqueio do ZFS:

# xfs_info /dev/zd0p1
meta-data=/dev/zd0p1             isize=256    agcount=32, agsize=7372768 blks
         =                       sectsz=4096  attr=2, projid32bit=0
data     =                       bsize=4096   blocks=235928576, imaxpct=25
         =                       sunit=32     swidth=32 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=65536, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Opções de montagem do XFS:

# mount
/dev/zd0p1 on /ppro type xfs (rw,noatime,logbufs=8,logbsize=256k,nobarrier)

Observação: também faço isso em cima do RAID de hardware do HP Smart Array em alguns casos.

A criação do pool se parece com:

zpool create -o ashift=12 -f vol1 wwn-0x600508b1001ce908732af63b45a75a6b

Com o resultado parecido com:

# zpool status  -v
  pool: vol1
 state: ONLINE
  scan: scrub repaired 0 in 0h14m with 0 errors on Wed Feb 26 05:53:51 2014
config:

        NAME                                      STATE     READ WRITE CKSUM
        vol1                                      ONLINE       0     0     0
          wwn-0x600508b1001ce908732af63b45a75a6b  ONLINE       0     0     0

    

Answer 2

Primeiro, vale dizer que o ZFS não é um sistema de arquivos suportado para o MongoDB no Linux - os sistemas de arquivos recomendados são ext4 ou XFS. Como o ZFS nem é verificado no Linux (consulte SERVER-13223 , por exemplo), ele não usará arquivos esparsos, em vez disso, tentar pré-alocar (preencher com zeros), e isso significa desempenho horrendo em um sistema de arquivos COW . Até que isso seja corrigido, adicionar novos arquivos de dados será um grande impacto no desempenho do ZFS (que você tentará fazer com frequência com suas gravações). Enquanto você não está fazendo isso, o desempenho deve melhorar, mas se você estiver adicionando dados com rapidez suficiente, talvez nunca se recupere entre os hits de alocação.

Além disso, o ZFS não suporta Direct IO, por isso você estará copiando dados várias vezes na memória (mmap, ARC, etc.) - Eu suspeito que essa seja a fonte de suas leituras, mas eu teria que testar para ser certo. A última vez que vi algum teste com o MongoDB / ZFS no Linux, o desempenho foi ruim, mesmo com o ARC em um SSD - o ext4 e o XFS foram massivamente mais rápidos. O ZFS pode ser viável para o uso de produção do MongoDB no Linux no futuro, mas não está pronto no momento.

    

Answer 3

Estávamos investigando o Mongo no ZFS e percebemos que esse post levantou grandes preocupações sobre o desempenho disponível. Dois anos depois, queríamos ver como as novas versões do Mongo que usam o WiredTiger sobre o mmap, foram executadas no ZFS, agora oficialmente suportado, que vem com a versão mais recente do Ubuntu Xenial.

Em resumo, ficou claro que o ZFS não funciona tão bem quanto EXT4 ou XFS, entretanto, a lacuna de desempenho não é tão significativa, especialmente quando você considera os recursos extras que o ZFS oferece.

Fiz uma postagem no blog sobre nossas descobertas e metodologia. Espero que você ache útil!

    

Answer 4

Acredito que seu disco esteja ocupado fazendo leituras por causa do

zfs_arc_max=2147483648

configuração. Aqui você está explicitamente limitando o ARC para 2Gb, mesmo que você tenha 16-32Gb. O ZFS é extremamente faminto de memória e zeloso quando se trata do ARC. Se você tem réplicas não-ZFS idênticas às réplicas do ZFS (HW RAID1 abaixo), algumas matemáticas produzem

5s spike @ (200Mb/s writes (estimated 1 hdd throughput) * 2 (RAID1)) = 2Gb over 5sec

, o que significa que você provavelmente está invalidando todo o cache do ARC em 5 segundos. O ARC é (até certo ponto) "inteligente" e tentará manter os blocos mais recentemente escritos e os mais usados, portanto, o volume do ZFS pode estar tentando fornecer um cache de dados decente com o espaço limitado que ele possui. Tente aumentar o zfs_arc_max para metade da sua RAM (ou até mais) e usar o arc_shrink_shift para despejar os dados do cache do ARC de forma mais agressiva.

Aqui você pode encontrar uma leitura de blog em 17 partes para sintonizar e entender os sistemas de arquivos ZFS.

Aqui você pode encontrar a explicação do ajuste de mudança de contração do ARC (primeiro parágrafo), que permitirá que você recupere mais RAM do ARC após o despejo e mantenha-o sob controle.

Não tenho certeza da confiabilidade da solução XFS em zvol. Mesmo que o ZFS seja COW, o XFS não é. Suponha que o XFS esteja atualizando seus metadados e a máquina perca energia. O ZFS lerá a última cópia boa dos dados graças ao recurso COW, mas o XFS não saberá dessa alteração. Seu volume XFS pode permanecer "instantâneo" para a versão antes da falha de energia por metade, e para a versão após falha de energia para o outro (porque não é conhecido pelo ZFS que toda essa gravação de 8Mb deve ser atômica e contém apenas inodes) .

[EDIT] arc_shrink_shift e outros parâmetros estão disponíveis como parâmetros de módulo para o ZFSonlinux. Experimente

modinfo zfs

para obter todos os suportados para sua configuração.