☰

Fsync lento com SSD local do Google Cloud (Postgresql)

tag-icon • tag-icon postgresql google-compute-engine
Fsync lento com SSD local do Google Cloud (Postgresql)

Estou recebendo transações inesperadamente baixas por segundo na opção "SSD local" do GCE (em comparação com o disco permanente SSD) usando testes simples "pgbench":

# With Local SSD
# /dev/mapper/vg0-data on /data type xfs (rw,noexec,noatime,attr2,inode64,noquota)
pg-dev-002:~$ pgbench -c 8 -j 2 -T 60 -U postgres
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 8
number of threads: 2
duration: 60 s
number of transactions actually processed: 10765
tps = 179.287875 (including connections establishing)
tps = 179.322407 (excluding connections establishing)

# With SSD Persistent Disk
# /dev/mapper/vg1-data on /data1 type xfs (rw,noexec,noatime,attr2,inode64,noquota)
pg-dev-002:/data$ pgbench -c 8 -j 2 -T 60 -U postgres
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 8
number of threads: 2
duration: 60 s
number of transactions actually processed: 62457
tps = 1040.806664 (including connections establishing)
tps = 1041.012782 (excluding connections establishing)

Os benchmarks "fio" mostram o IOPS anunciado e a taxa de transferência para SSD local. No entanto, a execução de "pg_test_fsync" em uma montagem SSD local me leva a acreditar que a latência do fsync é a culpada. Os números do SSD local são obtidos após a aplicação do script IRQ do Googleaqui:

# Local SSD
open_datasync                     319.738 ops/sec    3128 usecs/op
fdatasync                         321.963 ops/sec    3106 usecs/op

# Persistent SSD
open_datasync                    1570.305 ops/sec     637 usecs/op
fdatasync                        1561.469 ops/sec     640 usecs/op
  • Testado com imagens Ubuntu 14.04 e Debian 7
  • Tipo de instância: n1-highmem-4
  • As opções de montagem são idênticas para ambos os tipos de volume

Não vi nada sobre as limitações do fsync e do SSD local, mas não tenho certeza de onde verificar ou testar.

Responder1

Comparando umsolteiroSSD/HDD local/etc. para um controlador RAID tipo SAN, é como comparar um VW Beetle a um carro Audi RS10 Le-mans, sim, ambos saíram da mesma fábrica e ambos usam motores / SSDs / HDDs de quatro tempos, mas suas afinações etc. são muito, muito diferentes.

Posso dar vários exemplos de experiências adquiridas, mas as respostas simples estão relacionadas às enormes quantidades de cache RAM com backup de bateria que o armazenamento baseado em SAN tem em comparação com o que não está no SSD/HDD local. Mesmo os SSDs não conseguem competir com a RAM DDR3 suportada por bateria quando se trata de confirmar que os dados foram “comprometidos” no disco. Além disso, o disco local único pode (realisticamente) lidar apenas com uma única operação por vez, gravando um bloco no "disco", em comparação com os sistemas SAN alimentados por bateria que podem lidar com várias solicitações simultaneamente "gravando no disco" (conforme compromete os dados para a RAM DDR3 com backup de bateria)

Por último, a questão pode serqualdisco SSD local estão sendo usados, pois tenho visto enormes diferenças no desempenho de gravação entre diferentestamanhosda mesma família de SSDs (quanto maior, mais rápido) sem falar nas diversas velocidades dos diversos discos SSD que existem por aí.

SIM, os SSDs são mais rápidos que os HDDs, mas ainda não tão rápidos quanto a RAM DDR3 com bateria;)

Responder2

O Google reconhece que as liberações de cache de gravação são bastante lentas no SSD local e fornece etapas para desativar o cache de gravação na montagem do sistema de arquivos para evitar esse atraso [se adequado ao seu caso de uso]. Os documentos sãoaqui.

informação relacionada