Solaris 10 ZFS ARC maximizado e sobrecarregado de CPU

Question

Estamos executando o ZFS há alguns anos no Solaris 10 no servidor Oracle M5000 Enterprise com 32 núcleos de CPU e 256 GB de memória. Estamos executando um banco de dados / aplicativo neste servidor que parece ser pesado.

Tivemos problemas de E / S durante o UFS e isso foi resolvido ao alternar para o ZFS. Temos uma unidade de armazenamento NetApp que apresenta os discos através do fibre channel e, em seguida, formata usando o ZFS no nível do sistema operacional em um único LUN. No início, tivemos problemas com a memória do aplicativo e tivemos que limitar o tamanho do ARC para 128 GB de memória.

Agora, o problema que começamos a ver é que o ARC está sendo maximizado. Durante esse tempo, as CPUs ficam sobrecarregadas com 0% de tempo ocioso às vezes. Os processos de aplicação são paralisados e processos automatizados começam a ser executados entre si.

Venho pesquisando o assunto há algum tempo e consultei várias fontes que parecem acreditar que apenas precisamos de uma máquina maior ou que o fornecedor otimize seu código. Estamos olhando para a compra de um M10-4 e estamos trabalhando com o fornecedor do aplicativo, mas estou me perguntando se pode haver algo mais acontecendo.

Qualquer ajuda será apreciada e deixe-me saber se mais informações são necessárias.

Abaixo está a saída de arc_summary.pl

System Memory:
     Physical RAM:  257614 MB
     Free Memory :  79033 MB
     LotsFree:      4022 MB

ZFS Tunables (/etc/system):
     set zfs:zfs_arc_max = 137438953472

ARC Size:
     Current Size:             131043 MB (arcsize)
     Target Size (Adaptive):   131072 MB (c)
     Min Size (Hard Limit):    64 MB (zfs_arc_min)
     Max Size (Hard Limit):    131072 MB (zfs_arc_max)

ARC Size Breakdown:
     Most Recently Used Cache Size:           6%    8190 MB (p)
     Most Frequently Used Cache Size:        93%    122881 MB (c-p)

ARC Efficency:
     Cache Access Total:             217693264863
     Cache Hit Ratio:      99%       217640359356           [Defined State for buffer]
     Cache Miss Ratio:      0%       52905507       [Undefined State for Buffer]
     REAL Hit Ratio:       67%       146336547931           [MRU/MFU Hits Only]

     Data Demand   Efficiency:    99%
     Data Prefetch Efficiency:    96%

    CACHE HITS BY CACHE LIST:
      Anon:                       32%        71281340234                    [ New Customer, First Cache Hit ]
      Most Recently Used:          0%        172508676 (mru)        [ Return Customer ]
      Most Frequently Used:       67%        146164039255 (mfu)             [ Frequent Customer ]
      Most Recently Used Ghost:    0%        3430197 (mru_ghost)    [ Return Customer Evicted, Now Back ]
      Most Frequently Used Ghost:  0%        19040994 (mfu_ghost)   [ Frequent Customer Evicted, Now Back ]
    CACHE HITS BY DATA TYPE:
      Demand Data:                62%        136382108166
      Prefetch Data:               0%        1145425065
      Demand Metadata:             4%        9980846285
      Prefetch Metadata:          32%        70131979840
    CACHE MISSES BY DATA TYPE:
      Demand Data:                19%        10410690
      Prefetch Data:              72%        38324623
      Demand Metadata:             1%        874219
      Prefetch Metadata:           6%        3295975

Abaixo está a saída do vmstat:

# vmstat 5
kthr      memory            page            disk          faults      cpu
r b w   swap  free  re  mf pi po fr de sr m1 m1 m1 m1   in   sy   cs us sy id
0 0 0 40892888 93939912 256 1411 165 26 26 0 0 8 1 2 0 5651 274471 42913 2 5 93
0 0 0 22113320 81957648 118 1324 3 0 0 0 0 0  0  0  0 5631 313043 58903 2 35 63
0 0 0 22145624 81977312 353 459 0 746 746 0 0 145 0 0 0 5177 379709 58255 2 33 65
0 0 0 22150976 81982088 120 1329 0 0 0 0 0 1  0  0  0 5200 314711 59490 2 33 65
0 0 0 22147600 81981680 504 1834 0 8 5 0 0 5  0  0  0 5197 334201 58339 2 32 66
0 0 0 22146160 81982544 715 610 0 5 3 0 0  2  0  0  0 6296 364301 58900 2 35 63
0 0 0 22116584 81960496 678 1928 0 3 3 0 0 1  0  0  0 5178 351160 58947 2 34 64
1 0 0 22107080 81949528 95 1095 0 0 0 0 0  0  0  0  0 4531 309206 58450 2 35 63

Abaixo está a saída do zpool iostat:

# zpool iostat ntapdatatel 5
            capacity     operations    bandwidth
pool         alloc   free   read  write   read  write
-----------  -----  -----  -----  -----  -----  -----
ntapdatatel  1.07T   437G     10     13  1.07M  1.01M
ntapdatatel  1.07T   437G      0      0  51.2K  4.00K
ntapdatatel  1.07T   437G      0      0      0      0
ntapdatatel  1.07T   437G      0     95      0  6.47M
ntapdatatel  1.07T   437G      0      0      0      0
ntapdatatel  1.07T   437G      0      0      0      0
ntapdatatel  1.07T   437G      0      0      0      0
ntapdatatel  1.07T   437G      0      0      0      0
ntapdatatel  1.07T   437G      0      0  25.6K      0
ntapdatatel  1.07T   437G      0     87      0  5.16M

e as propriedades do sistema de arquivos:

NAME         PROPERTY              VALUE                  SOURCE
ntapdatatel  type                  filesystem             -
ntapdatatel  creation              Sun Oct 28 17:09 2012  -
ntapdatatel  used                  1.07T                  -
ntapdatatel  available             413G                   -
ntapdatatel  referenced            432G                   -
ntapdatatel  compressratio         1.00x                  -
ntapdatatel  mounted               yes                    -
ntapdatatel  quota                 none                   default
ntapdatatel  reservation           none                   default
ntapdatatel  recordsize            128K                   default
ntapdatatel  mountpoint            /ntapdatatel           local
ntapdatatel  sharenfs              off                    default
ntapdatatel  checksum              on                     default
ntapdatatel  compression           off                    default
ntapdatatel  atime                 on                     default
ntapdatatel  devices               on                     default
ntapdatatel  exec                  on                     default
ntapdatatel  setuid                on                     default
ntapdatatel  readonly              off                    default
ntapdatatel  zoned                 off                    default
ntapdatatel  snapdir               hidden                 default
ntapdatatel  aclmode               discard                default
ntapdatatel  aclinherit            restricted             default
ntapdatatel  canmount              on                     default
ntapdatatel  shareiscsi            off                    default
ntapdatatel  xattr                 on                     default
ntapdatatel  copies                1                      default
ntapdatatel  version               5                      -
ntapdatatel  utf8only              off                    -
ntapdatatel  normalization         none                   -
ntapdatatel  casesensitivity       sensitive              -
ntapdatatel  vscan                 off                    default
ntapdatatel  nbmand                off                    default
ntapdatatel  sharesmb              off                    default
ntapdatatel  refquota              none                   default
ntapdatatel  refreservation        none                   default
ntapdatatel  primarycache          all                    default
ntapdatatel  secondarycache        all                    default
ntapdatatel  usedbysnapshots       0                      -
ntapdatatel  usedbydataset         432G                   -
ntapdatatel  usedbychildren        666G                   -
ntapdatatel  usedbyrefreservation  0                      -
ntapdatatel  logbias               latency                default
ntapdatatel  sync                  standard               default
ntapdatatel  rekeydate             -                      default
ntapdatatel  rstchown              on                     default

    

Answer 1

Pode não ser zfs - você tem muita memória livre, então considere esta possibilidade -

echo 'pg_contig_disable/D' | mdb -k

Se a saída for:

echo pg_contig_disable/D | mdb -k
pg_contig_disable:
pg_contig_disable:              0

Você pode estar passando por um tipo de problema NUMA. O Solaris 10 tenta facilitar o acesso mais rápido à memória, configurando blocos de memória para eficiência do cache. Isso, quando você tem muita memória e oracle, resulta em uma situação estranha - exatamente como você descreve. Após um mês ou mais de tempo de atividade, não há muito uso do usuário da CPU, muito tempo de CPU do sistema e o sistema fica paralisado. A longo prazo, defina o parâmetro do kernel pg_contig_disable como 1.

A correção de curto prazo é reinicializar. Se a reinicialização ajuda você precisa definir o kernel parm. Este é um problema conhecido do Solaris 10 em sistemas com muita memória livre.

    

Answer 2

Obrigado a jim mcnamara por me apontar na direção certa. Eu não estava vendo sintomas consistentes com o problema pg_contig_disable, mas isso me levou a um problema com zfetch.

Encontrei o mesmo problema que estávamos tendo no seguinte site: link

Isso levou a um artigo de ajuste no site da Oracle descrevendo por que a pré-busca do ZFS era um problema para nós: link

Estávamos vendo dmu_zfetch_find no topo da lista de mutex usando lockstat durante uma carga pesada. Desde então, tenho desativado a pré-busca em nossa implementação do ZFS. Estarei reiniciando esta noite para garantir que tudo seja limpo e começarmos de novo.

Espero que este seja o ingresso. Podemos fazer alguns testes com o pg_contig_disable mais tarde, se ainda estivermos tendo problemas, caso isso aconteça.