Optimiza el rendimiento de discos persistentes

Optimiza discos persistentes

Los discos persistentes te proporcionan el rendimiento descrito en la tabla de tipos de disco si la VM genera un uso suficiente para alcanzar los límites de rendimiento. Una vez que dimensiones los volúmenes de discos persistentes para satisfacer tus necesidades de rendimiento, puede que tu app y tu sistema operativo necesiten algunos ajustes.

En las siguientes secciones, se describen algunos elementos clave que se pueden ajustar para obtener un mejor rendimiento y se explica cómo aplicar algunos de ellos a tipos específicos de cargas de trabajo.

Limita las cargas pesadas de E/S a un intervalo de 50 TB

Las cargas pesadas de E/S alcanzan el máximo rendimiento cuando se limitan a un intervalo de 50 TB. Los intervalos en discos persistentes distintos que agregan hasta 50 TB o menos pueden considerarse como un solo intervalo de 50 TB para fines de rendimiento. Un intervalo hace referencia a un rango contiguo de direcciones de bloque lógicas en un solo disco.

Inhabilita la inicialización diferida y habilita los comandos DISCARD

Los discos persistentes admiten los comandos DISCARD o TRIM, que permiten que los sistemas operativos informen a los discos cuando los bloques ya no están en uso. La compatibilidad con DISCARD permite que el sistema operativo marque los bloques de disco cuando ya no sean necesarios, sin incurrir en el costo de poner los bloques a cero.

En la mayoría de los sistemas operativos Linux, puedes habilitar DISCARD cuando activas un disco persistente en tu instancia. Las instancias de Windows Server 2012 R2 habilitan DISCARD de forma predeterminada cuando activas un disco persistente. Windows Server 2008 R2 no es compatible con DISCARD.

Habilitar DISCARD puede aumentar el rendimiento general del entorno de ejecución y, también, puede acelerar el rendimiento del disco cuando se activa por primera vez. Formatear el volumen completo del disco puede llevar mucho tiempo, por lo que el “formateo diferido” es una práctica común. La desventaja del formateo diferido es que el costo se suele pagar la primera vez que se activa el volumen. Si inhabilitas la inicialización diferida y habilitas los comandos DISCARD, puedes obtener una activación y un formateo rápidos.

  • Para inhabilitar la inicialización diferida y habilitar DISCARD durante el formateo, pasa los siguientes parámetros a mkfs.ext4:

    -E lazy_itable_init=0,lazy_journal_init=0,discard
    

    El parámetro lazy_journal_init=0 no funciona en instancias con imágenes de CentOS 6 o RHEL 6. Para esas instancias, formatea los discos persistentes sin ese parámetro.

    -E lazy_itable_init=0,discard
    
  • Para habilitar los comandos DISCARD durante la activación, pasa la marca siguiente al comando de activación:

    -o discard
    

Los discos persistentes funcionan bien con la opción discard habilitada. Sin embargo, puedes ejecutar fstrim de manera periódica junto con la opción discard o sin ella. Si no usas la opción discard, ejecuta fstrim antes de crear una instantánea de tu disco. Reducir el sistema de archivos te permite crear imágenes de instantáneas más pequeñas, lo que disminuye el costo de almacenamiento de instantáneas.

Profundidad de la cola de E/S

Muchas apps tienen opciones de configuración que afectan la profundidad de la cola de E/S. Las profundidades de la cola mayores aumentan las IOPS, pero también pueden aumentar la latencia. Las profundidades de cola menores disminuyen la latencia por E/S, pero también pueden producir IOPS máximas más bajas.

Caché de lectura anticipada

Para mejorar el rendimiento de E/S, los sistemas operativos emplean técnicas como la lectura anticipada, que consiste en leer en la memoria más archivos de los solicitados en el supuesto de que las lecturas posteriores necesitarán esos datos. Una lectura anticipada mayor aumenta la capacidad de procesamiento a expensas de la memoria y las IOPS. Una lectura anticipada menor aumenta las IOPS a expensas de la capacidad de procesamiento.

En los sistemas Linux, puedes obtener y establecer el valor de lectura anticipada con el comando blockdev:

$ sudo blockdev --getra /dev/[DEVICE_ID]
$ sudo blockdev --setra [VALUE] /dev/[DEVICE_ID]

El valor de lectura anticipada es <desired_readahead_bytes> o 512 bytes.

Por ejemplo, para una lectura anticipada de 8 MB, 8 MB es 8,388,608 bytes (8 * 1,024 * 1,024).

8388608 bytes / 512 bytes = 16384

Debes establecer blockdev como 16384:

$ sudo blockdev --setra 16384 /dev/[DEVICE_ID]

CPU libres

Realizar operaciones de lectura y escritura en un disco persistente requiere ciclos de CPU de tu VM. Si quieres alcanzar niveles de IOPS muy altos y coherentes, debes tener CPU libres para procesar E/S.

Cargas de trabajo orientadas a IOPS

Las bases de datos, ya sean SQL o NoSQL, tienen patrones de uso de acceso aleatorio a los datos. Google recomienda los siguientes valores para las cargas de trabajo orientadas a IOPS:

  • Valores de profundidad de la cola de E/S de 1 por cada 400–800 IOPS, hasta un límite de 64 para volúmenes grandes

  • Una CPU libre por cada 2,000 IOPS de lectura aleatoria y 1 CPU libre por cada 2,500 IOPS de escritura aleatoria

Por lo general, en los documentos de recomendaciones, se sugieren valores de lectura anticipada menores para MongoDB, Apache Cassandra y otras aplicaciones de bases de datos.

Cargas de trabajo orientadas a la capacidad de procesamiento

Las operaciones de transmisión, como un trabajo de Hadoop, se benefician de las operaciones de lectura secuenciales rápidas; los tamaños más grandes de E/S pueden aumentar el rendimiento de la transmisión. Para cargas de trabajo orientadas a la capacidad de procesamiento, recomendamos E/S con un tamaño de 256 KB o más.

Optimiza el rendimiento de discos persistentes estándar

Si quieres lograr niveles de capacidad de procesamiento máximos para los discos persistentes estándar de manera coherente, usa las siguientes recomendaciones:

  • Usa transmisiones de E/S secuenciales paralelas cuando sea posible

    Usa E/S secuencial en discos persistentes estándar porque el sistema está diseñado para optimizar el rendimiento de E/S con el acceso secuencial al disco similar a un disco duro HDD real.

    La distribución de E/S en múltiples transmisiones secuenciales mejorará el rendimiento de manera significativa. Para lograr el mejor nivel de coherencia, usa 8 o más transmisiones secuenciales.

  • Usa un tamaño de E/S grande

    Los discos persistentes estándar proporcionan una capacidad de procesamiento muy alta en el límite. Para garantizar que los límites y la latencia de IOPS no generen un cuello de botella en el rendimiento de tu aplicación, usa un tamaño mínimo de E/S de 256 KB o más.

    Usa tamaños de franjas grandes para las aplicaciones del sistema de archivos distribuido. Una carga de trabajo de E/S aleatoria que usa franjas de tamaño grande (p. ej., 4 MB) obtendrá un gran rendimiento en los discos persistentes estándar debido a la exactitud con que imita el acceso al disco con múltiples transmisiones secuenciales.

  • Asegúrate de proporcionar E/S con suficiente paralelismo

    Usa la mayor profundidad de cola posible de modo que puedas aprovechar el paralelismo del SO. Usar una profundidad de cola lo bastante alta es muy importante para que los discos persistentes estándar permitan alcanzar una capacidad de procesamiento al límite sin generar un cuello de botella a tu aplicación por latencia de E/S.

Optimiza el rendimiento del disco persistente SSD

En la tabla de rendimiento por tipo de disco, se describe el rendimiento máximo alcanzable esperado para los discos persistentes de estado sólido. Para optimizar tus apps y tus instancias de VM a fin de alcanzar estas velocidades, usa las siguientes recomendaciones:

  • Asegúrate de que tu app genere suficiente E/S

    Si tu app genera menos IOPS que el límite descrito en la tabla anterior, no alcanzarás ese nivel de IOPS. Por ejemplo, en un disco de 500 GB, el límite de IOPS esperado es de 15,000 IOPS. Sin embargo, si generas menos IOPS o si las operaciones de E/S superan los 8 KB, no obtendrás 15,000 IOPS.

  • Asegúrate de proporcionar E/S con suficiente paralelismo

    Usa una profundidad de cola lo bastante alta de modo que puedas aprovechar el paralelismo del SO. Si proporcionas 1,000 IOPS, pero lo haces de forma sincróna con una profundidad de la cola de 1, obtendrás muchas menos IOPS que el límite descrito en la tabla. Como mínimo, tu app debe tener una profundidad de cola de 1 por cada 400–800 IOPS.

  • Asegúrate de que haya suficiente CPU disponible en la instancia que genera la E/S

    Si tu instancia de VM consume mucha CPU, tu app no podrá administrar las IOPS descritas con anterioridad. Te recomendamos tener una CPU disponible por cada 2,000–2,500 IOPS de tráfico esperado.

  • Asegúrate de que tu app esté optimizada para una localidad de datos temporales razonable en discos grandes

    Si tu app accede a datos que se distribuyen en diferentes partes de un disco durante un período corto (cientos de GB por CPU virtual), no obtendrás IOPS óptimas. Si quieres obtener un mejor rendimiento, optimiza para una localidad de datos temporales y en cuenta factores como la fragmentación del disco y la aleatoriedad de las partes accedidas del disco.

  • Asegúrate de que el programador de E/S en el SO esté configurado para satisfacer tus necesidades específicas

    En los sistemas basados en Linux, puedes configurar el programador de E/S como noop para alcanzar la mayor cantidad de IOPS en dispositivos respaldados por SSD.

Haz una evaluación comparativa del rendimiento del disco persistente SSD

Los siguientes comandos se basan en un dispositivo PD-SSD de 2,500 GB. Si el tamaño de tu dispositivo es diferente, modifica el valor del argumento --filesize. Este tamaño de disco es necesario para alcanzar los límites de capacidad de procesamiento de VM de 32 CPU virtuales.

    # Install dependencies
    sudo apt-get update
    sudo apt-get install -y fio
  1. Llena el disco con datos distintos de cero. Las operaciones de lectura de disco persistente de bloques vacíos tienen un perfil de latencia diferente del de los bloques que contienen datos. Recomendamos llenar el disco antes de ejecutar una evaluación comparativa de latencia de operaciones de lectura.

    # Running this command causes data loss on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=fill_disk \
      --filename=/dev/sdb --filesize=2500G \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=128K --iodepth=64 --rw=randwrite
    
  2. Para probar el ancho de banda de operaciones de escritura, realiza operaciones de escritura secuenciales con múltiples transmisiones paralelas (más de 8) con un tamaño de E/S de 1 MB y una profundidad de E/S mayor o igual que 64.

    # Running this command causes data loss on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=write_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=1M --iodepth=64 --rw=write --numjobs=8 --offset_increment=100G
    
  3. Prueba las IOPS de escritura. Para alcanzar las IOPS de PD máximas, debes mantener una cola de E/S profunda. Por ejemplo, si la latencia de operación de escritura es de 1 milisegundo, la VM puede alcanzar, como máximo, 1,000 IOPS por cada E/S en tránsito. Para alcanzar 15,000 IOPS, la VM debe mantener al menos 15 E/S en tránsito. Si tu disco y tu VM pueden alcanzar 30,000 IOPS, el número de E/S en tránsito debe ser de al menos 30 E/S. Si el tamaño de E/S supera los 4 KB, puede que la VM alcance el límite de ancho de banda antes de alcanzar el límite de IOPS.

    # Running this command causes data loss on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=write_iops_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=64 --rw=randwrite
    
  4. Prueba la latencia de operaciones de escritura. Mientras pruebas la latencia de E/S, la VM no debe alcanzar las IOPS ni el ancho de banda máximos. De lo contrario, la latencia observada no reflejará la latencia de E/S real del disco persistente. Por ejemplo, si el límite de IOPS se alcanza a una profundidad de E/S de 30 y el comando fio duplica ese valor, el total de IOPS se mantendrá igual y la latencia de E/S informada se duplicará.

    # Running this command causes data loss on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=write_latency_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=4 --rw=randwrite
    
  5. Para probar el ancho de banda de operaciones de lectura, realiza operaciones de lectura secuenciales con múltiples transmisiones paralelas (más de 8) con un tamaño de E/S de 1 MB y una profundidad de E/S mayor o igual que 64.

    sudo fio --name=read_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=1M --iodepth=64 --rw=read --numjobs=8 --offset_increment=100G
    
  6. Prueba las IOPS de lectura. Para alcanzar las IOPS de PD máximas, debes mantener una cola de E/S profunda. Por ejemplo, si el tamaño de E/S supera los 4 KB, puede que la VM alcance el límite de ancho de banda antes de alcanzar el límite de IOPS.

    sudo fio --name=read_iops_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=64 --rw=randread
    
  7. Prueba la latencia de operaciones de lectura. Es importante llenar el disco con datos para obtener una medición de latencia realista. Es importante también que la VM no alcance los límites de IOPS o de capacidad de procesamiento durante esta prueba, ya que después de que el disco persistente alcanza su límite de saturación, rechaza la E/S entrante y esto se refleja en un aumento artificial en la latencia de E/S.

    sudo fio --name=read_latency_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=4 --rw=randread
    
  8. Prueba el ancho de banda de operaciones de lectura secuenciales.

    sudo fio --name=read_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --numjobs=4 --thread --offset_increment=500G \
      --bs=1M --iodepth=64 --rw=read
    
  9. Prueba el ancho de banda de operaciones de escritura secuenciales.

    sudo fio --name=write_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --numjobs=4 --thread --offset_increment=500G \
      --bs=1M --iodepth=64 --rw=write
    

Qué sigue

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Documentación de Compute Engine