Início / user-1257773

siemon's questions

Martin Hope
siemon
Asked: 2025-04-17 23:22:39 +0800 CST
  • 6

Ambiente:

  • SO: Oracle Linux 9.5 (systemd 252)
  • Sistema de arquivos: XFS
  • Armazenamento: IBM SAN LUNs via multipathd (configuração ALUA)
  • Dispositivos:/dev/mapper/mpath[a-d]1
  • Opções de montagem:rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota,_netdev
  • O sistema não está sob pressão de memória, o uso da CPU é nulo (pré-implantação não produtiva)

Problema: Operações simples de arquivo como cp, rsync e até mesmo dd direto (com iflag=direct oflag=direct) de/para sistemas de arquivos XFS são extremamente lentas (até 2 MB/s), mesmo ao copiar arquivos pequenos (por exemplo, 50 MB). No entanto, ao testar com fio, obtive excelente taxa de transferência — até 3 GB/s de leitura e 1,8 GB/s de gravação, tanto no sistema de arquivos montado quanto diretamente no dispositivo (por exemplo, /dev/mapper/mpathc1).

Even cat file > /dev/nullmostra 3,2 MB/s enquanto fio com o mesmo arquivo mostra 2-3 GB/s.

O que eu tentei:

  • Cache desabilitado usando iflag=direct/oflag=direct
  • Alterou entre opções de montagem sincronizadas e assíncronas (sem impacto)
  • Contabilidade de E/S e cgroups testados (funcionando bem)
  • Prioridades ALUA e multicaminho verificadas (devidamente balanceadas, sem erros de caminho)
  • Usado nice, ionice, systemd-run --scope com IOWeight, CPUWeight
  • Analisado com strace, que mostra o loop de cópia normal (chamadas de sistema de leitura/gravação)
  • Defina zero para /proc/sys/vm/dirty_ratioedirty_background_ratio
  • multipath.confConfiguração adequada garantida (round-robin, no_path_retry, etc.)

Comportamento notável:

  • Todos os comandos de leitura/gravação no dispositivo (por exemplo, dd, cat, cp, rsync) se comportam de forma anormalmente lenta.
  • fio funciona perfeitamente — tanto em testes baseados em arquivos quanto em testes baseados em dispositivos brutos.
  • O problema não parece estar relacionado à SAN ou limitado à largura de banda.
  • Estatísticas de E/S (iostat, vmstat, iotop) mostram atividade mínima durante essas operações lentas.
  • Sem corrupção no sistema de arquivos — a montagem XFS está limpa, sem logs ou erros de dmesg. Sistema novo.

Pergunta: O que poderia explicar a enorme discrepância de desempenho entre fio e operações básicas de arquivo, como cp ou rsync?

[root@oracle01 ~]# fio --name=read_test --filename=/u01/oradata/edm/testfile --rw=read --bs=64k --size=50M --iodepth=32 --numjobs=4 --time_based --runtime=10s --ioengine=libaio --group_reporting
{...}
Jobs: 4 (f=4): [R(4)][100.0%][r=42.3MiB/s][r=676 IOPS][eta 00m:00s]

[root@oracle01 ~]# fio --name=read_test --filename=/u01/oradata/edm/testfile --rw=read --bs=64k --size=50M --iodepth=32 --numjobs=4 --time_based --runtime=10s --ioengine=libaio --group_reporting --direct=1
{...}
Jobs: 4 (f=4): [R(4)][100.0%][r=3523MiB/s][r=56.4k IOPS][eta 00m:00s]

[root@oracle01 ~]# rsync -ah --progress OracleLinux-R9-U5-x86_64-dvd.iso  /u01/oradata/edm/tesst
sending incremental file list
OracleLinux-R9-U5-x86_64-dvd.iso
          7.18M   0%    1.56MB/s    2:11:12  ^C
xfs