☰

Fsync lento con SSD local de Google Cloud (Postgresql)

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

Obtengo transacciones por segundo inesperadamente bajas en la opción "SSD local" de GCE (en comparación con el disco persistente SSD) usando pruebas simples de "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)

Los puntos de referencia "fio" muestran las IOPS anunciadas y el rendimiento de SSD local. Sin embargo, ejecutar "pg_test_fsync" en un montaje SSD local me lleva a creer que la latencia de fsync es la culpable. Los números de SSD locales se obtienen después de aplicar el script IRQ de Googleaquí:

# 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
  • Probado con imágenes de Ubuntu 14.04 y Debian 7
  • Tipo de instancia: n1-highmem-4
  • Las opciones de montaje son idénticas para ambos tipos de volumen.

No he visto nada sobre las limitaciones de fsync y el SSD local, pero no estoy seguro de dónde más verificar o probar.

Respuesta1

Comparando unsolteroSSD/HDD local/etc. a un controlador RAID tipo SAN, es como comparar un VW Beetle con un automóvil Audi RS10 Le-mans, sí, ambos salieron de la misma fábrica y ambos usan motores de cuatro tiempos/SSD/HDD, pero sus ajustes, etc. son muy, muy diferentes.

Puedo darle varios ejemplos de experiencias adquiridas, pero las respuestas simples están relacionadas con las enormes cantidades de caché RAM respaldada por batería que tiene el almacenamiento basado en SAN en comparación con el SSD/HDD que no está en el local. Incluso los SSD no pueden competir con la RAM DDR3 respaldada por batería cuando se trata de confirmar que los datos se han "confirmado" en el disco. Además, el disco local único puede (realmente) solo manejar una única operación a la vez escribiendo un bloque en el "disco", en comparación con los sistemas SAN respaldados por batería que pueden manejar múltiples solicitudes simultáneamente "escribiendo en el disco" (ya que confirmó los datos). a la RAM DDR3 respaldada por batería)

Por último, la pregunta podría sercualSe están utilizando discos SSD locales, ya que he visto enormes diferencias en el rendimiento de escritura entre diferentestamañosde la misma familia de SSD (cuanto más grandes, más rápidos) sin mencionar las distintas velocidades de los distintos discos SSD que existen.

Sí, los SSD son más rápidos que los HDD, pero aún no tan rápidos como la RAM DDR3 respaldada por batería;)

Respuesta2

Google reconoce que los vaciados de caché de escritura son bastante lentos en SSD local y proporciona pasos para deshabilitar el almacenamiento en caché de escritura en el montaje del sistema de archivos para evitar ese retraso [si es adecuado para su caso de uso]. Los documentos sonaquí.

información relacionada