Prácticas recomendadas para el ajuste del rendimiento

En este documento, se proporciona orientación para mejorar Cloud Storage FUSE con funciones y parámetros de configuración clave de Cloud Storage FUSE para lograr la máxima capacidad de procesamiento y un rendimiento óptimo, en especial para las cargas de trabajo de inteligencia artificial y aprendizaje automático (IA/AA), como el entrenamiento, la entrega y la creación de puntos de control.

Consideraciones

Antes de aplicar los parámetros de configuración que recomendamos en esta página, ten en cuenta lo siguiente:

  • Puedes aplicar las configuraciones recomendadas en esta página con los siguientes métodos:

  • Asegúrate de ejecutar la versión más reciente de Cloud Storage FUSE. Las configuraciones recomendadas solo se deben aplicar a la versión 3.0 o posterior de Cloud Storage FUSE y al controlador CSI de Cloud Storage FUSE para Google Kubernetes Engine que se ejecuta en clústeres de GKE con la versión 1.32.2-gke.1297001 o posterior.

  • Las configuraciones recomendadas almacenan en caché los metadatos de Cloud Storage durante la duración del trabajo y no se verifican después del montaje inicial del sistema de archivos. Por lo tanto, para obtener un rendimiento óptimo, recomendamos que el sistema de archivos sea de solo lectura o que la semántica del sistema de archivos sea de aplicaciones de escritura en un archivo nuevo, lo que significa que las aplicaciones siempre escriben en archivos nuevos. Las siguientes cargas de trabajo de IA/AA son de escritura en un archivo nuevo:

    • Creación de puntos de control

    • Capacitación

    • Entrega

    • Almacenamiento en caché de jax.jit()

  • Los parámetros de configuración recomendados en esta página se validaron para las GPU de Cloud y los tipos de máquinas grandes de Cloud TPU a gran escala, en los que hay una gran cantidad de memoria y una interfaz de red de gran ancho de banda. Los tipos de máquinas de Cloud TPU y Cloud GPU pueden diferir en términos de la cantidad de recursos disponibles, como CPU, memoria y almacenamiento local, dentro de la configuración de su nodo host. Esto puede afectar directamente el rendimiento de las configuraciones, como las siguientes:

Compatibilidad con Rapid Bucket

A partir de la versión 3.7.1, Cloud Storage FUSE admite Rapid Bucket con una ruta de lectura optimizada.

La ruta de lectura optimizada mejora de forma significativa el rendimiento, ya que usa el algoritmo de lectura anticipada del kernel de Linux de forma predeterminada. Para usar esta ruta de lectura optimizada, se requieren cambios específicos en la configuración a nivel de la máquina para los parámetros read_ahead_kb, max_background y congestion_threshold. En los entornos de Google Kubernetes Engine (GKE) que usan el controlador de CSI de Cloud Storage FUSE, estas opciones de configuración se administran por completo y se aplican de forma automática. En el caso de las VMs de Compute Engine y otros entornos que no son de GKE, Cloud Storage FUSE requiere permisos de sudo para aplicar estos cambios automáticamente, o bien debes configurar estos parámetros manualmente.

Cuando uses la ruta de lectura optimizada para Rapid Bucket, ten en cuenta los siguientes comportamientos y limitaciones:

  • Compatibilidad con el lector almacenado en búfer y la caché de archivos: Dado que la ruta de lectura optimizada se basa en el algoritmo de lectura anticipada del kernel, no es compatible con el lector almacenado en búfer ni la caché de archivos de Cloud Storage FUSE. De forma predeterminada, estas funciones están inactivas (no-op) para Rapid Bucket. Si tu carga de trabajo requiere la caché de archivos o el lector con búfer, debes inhabilitar de forma explícita el lector del kernel configurando enable-kernel-reader: false durante la activación. Esto hará que Cloud Storage FUSE use la ruta de lectura estándar, que es compatible con el almacenamiento en caché de archivos y las lecturas almacenadas en búfer.
  • Requisitos de activación: La nueva ruta de lectura solo se admite para activaciones estáticas. No se admite cuando se usa la activación dinámica.

Usa buckets con el espacio de nombres jerárquico habilitado

Usa siempre buckets con el espacio de nombres jerárquico habilitado. El espacio de nombres jerárquico organiza tus datos en una estructura de sistema de archivos jerárquica, lo que hace que las operaciones dentro del bucket sean más eficientes, lo que genera tiempos de respuesta más rápidos y menos llamadas generales a la lista para cada operación.

Estos son algunos de los beneficios del espacio de nombres jerárquico:

  • Los buckets con espacio de nombres jerárquico proporcionan hasta ocho veces más consultas por segundo (QPS) iniciales en comparación con los buckets planos. El espacio de nombres jerárquico admite 40,000 solicitudes de lectura de objetos iniciales por segundo y 8,000 solicitudes de escritura de objetos iniciales, lo que es significativamente más alto que los buckets planos típicos de Cloud Storage FUSE, que ofrecen solo 5,000 solicitudes de lectura de objetos por segundo inicialmente y 1,000 solicitudes de escritura de objetos iniciales.

  • El espacio de nombres jerárquico proporciona cambios de nombre de directorio atómicos, que son necesarios para crear puntos de control con Cloud Storage FUSE y garantizar la atomicidad. Usar buckets con el espacio de nombres jerárquico habilitado es especialmente beneficioso cuando se crean puntos de control a gran escala, ya que los frameworks de AA usan cambios de nombre de directorio para finalizar los puntos de control, lo que es un comando rápido y atómico, y solo se admite en buckets con el espacio de nombres jerárquico habilitado. Si decides no usar un bucket con el espacio de nombres jerárquico habilitado, consulta Aumenta el límite de cambio de nombre para los buckets que no son de HNS.

Para obtener información sobre cómo crear un bucket con el espacio de nombres jerárquico habilitado, consulta Crea buckets con el espacio de nombres jerárquico habilitado. Para obtener información sobre cómo activar un bucket con espacio de nombres jerárquico habilitado, consulta Cómo activar buckets con espacio de nombres jerárquico. Los espacios de nombres jerárquicos son compatibles con las versiones de Google Kubernetes Engine 1.31.1-gke.2008000 o posteriores.

Realiza una activación específica del directorio

Si deseas acceder a un directorio específico dentro de un bucket, puedes activar solo el directorio específico con la opción de activación only-dir en lugar de activar todo el bucket. Realizar una activación específica del directorio acelera las llamadas de lista y reduce la cantidad total de llamadas de lista y estadísticas, ya que limita la cantidad de directorios que se deben recorrer cuando se resuelve un nombre de archivo, porque las llamadas de LookUpInode y las solicitudes de acceso al bucket o al directorio generan automáticamente llamadas de lista y estadísticas para cada archivo o directorio de la ruta de acceso.

Para activar un directorio específico, usa uno de los siguientes métodos:

Google Kubernetes Engine

Para los volúmenes persistentes, usa la siguiente configuración de activación con el controlador de CSI de Cloud Storage FUSE para Google Kubernetes Engine:

mountOptions:
    - only-dir:DIRECTORY_NAME

Para los volúmenes efímeros, agrega la configuración de activación al volumeAttributes.mountOptions, con marcas separadas por comas:

mountOptions: "OTHER_OPTIONS,only-dir:DIRECTORY_NAME"

Reemplaza DIRECTORY_NAME por el nombre del directorio que deseas activar.

Compute Engine

Ejecuta el comando gcsfuse --only-dir para activar un directorio específico en una máquina virtual de Compute Engine:

gcsfuse --only-dir DIRECTORY_NAME BUCKET_NAME MOUNT_POINT

Reemplaza lo siguiente:

  • BUCKET_NAME es el nombre del bucket en el que deseas activar el directorio.

  • DIRECTORY_NAME es el nombre del directorio que deseas activar.

  • MOUNT_POINT es el directorio local donde se activará tu bucket. Por ejemplo, /path/to/mount/point

Para obtener más información sobre cómo activar un directorio, consulta Activa un directorio dentro de un bucket.

Aumenta los valores de la caché de metadatos

Para mejorar el rendimiento de las lecturas repetidas, puedes configurar Cloud Storage FUSE para que almacene en caché una gran cantidad de metadatos y omita el vencimiento de los metadatos, lo que evita las solicitudes repetidas de metadatos a Cloud Storage y mejora significativamente el rendimiento.

Aumentar los valores de la caché de metadatos es beneficioso para las cargas de trabajo con lecturas repetidas, ya que evita las llamadas repetitivas a Cloud Storage, y para los volúmenes de solo lectura, en los que se puede establecer un TTL infinito.

Ten en cuenta lo siguiente antes de aumentar los valores de la caché de metadatos:

  • Solo se debe establecer un tiempo de actividad (TTL) infinito para los volúmenes que son de solo lectura o de solo escritura en nuevos.

  • La caché de metadatos solo debe habilitarse para aumentar de forma significativa su tamaño en los nodos con configuraciones de memoria grandes, ya que almacena en caché todos los metadatos del punto de activación especificado en cada nodo y elimina la necesidad de acceso adicional a Cloud Storage.

  • Las configuraciones de esta sección almacenan en caché todos los metadatos a los que se accede con un TTL infinito, lo que puede afectar las garantías de coherencia cuando cualquier otro cliente realiza cambios en el mismo bucket de Cloud Storage, por ejemplo, cuando se sobrescribe o borra un archivo.

  • Para verificar que el consumo de memoria no se vea afectado, valida que la cantidad de memoria que consume la caché de metadatos sea aceptable para ti, ya que puede aumentar a gigabytes y depende de la cantidad de archivos en los buckets activados y de la cantidad de puntos de activación que se usan. Por ejemplo, los metadatos de cada archivo ocupan aproximadamente 1.5 KiB de memoria y, en términos relativos, los metadatos de un millón de archivos ocupan aproximadamente 1.5 GiB de memoria. Para obtener más información, consulta Descripción general del almacenamiento en caché.

Sigue las instrucciones que se indican a continuación para configurar Cloud Storage FUSE de modo que almacene en caché una gran cantidad de metadatos y omita su vencimiento:

Opciones de gcsfuse

gcsfuse --metadata-cache-ttl-secs=-1 \
      --stat-cache-max-size-mb=-1 \
      BUCKET_NAME MOUNT_POINT

Reemplaza lo siguiente:

  • BUCKET_NAME es el nombre de tu depósito.

  • MOUNT_POINT es el directorio local donde se activará el bucket. Por ejemplo, /path/to/mount/point

Archivo de configuración

metadata-cache:
stat-cache-max-size-mb: -1
ttl-secs: -1

Google Kubernetes Engine

  mountOptions:
      - metadata-cache:ttl-secs:-1
      - metadata-cache:stat-cache-max-size-mb:-1

Compute Engine

gcsfuse --metadata-cache-ttl-secs=-1 \
      --stat-cache-max-size-mb=-1 \
      BUCKET_NAME MOUNT_POINT

Reemplaza lo siguiente:

  • BUCKET_NAME es el nombre de tu depósito.

  • MOUNT_POINT es el directorio local donde se activará el bucket. Por ejemplo, /path/to/mount/point

Cómo completar previamente la caché de metadatos

Antes de ejecutar una carga de trabajo, te recomendamos que prepropagues la caché de metadatos, lo que mejora significativamente el rendimiento y reduce de forma sustancial la cantidad de llamadas de metadatos a Cloud Storage, en especial, si se usa el campo implicit-dirs o la opción --implicit-dirs. El controlador de CSI de Cloud Storage FUSE para GKE proporciona una API que controla la propagación previa de la caché de metadatos. Consulta Usa la carga previa de metadatos para propagar previamente la caché de metadatos.

Para prepropagar la caché de metadatos, usa uno de los siguientes métodos:

Google Kubernetes Engine

Establece la marca del atributo de volumen del CSI gcsfuseMetadataPrefetchOnMount en true:

En las versiones 1.32.1-gke.1357001 y posteriores de Google Kubernetes Engine, puedes habilitar la recuperación previa de metadatos para un volumen determinado con la opción de configuración gcsfuseMetadataPrefetchOnMount en el campo volumeAttributes de tu definición de PersistentVolume. El método initContainer no es necesario cuando usas la opción de configuración gcsfuseMetadataPrefetchOnMount.

  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: training-bucket-pv
  spec:
    ...
    csi:
      volumeHandle: BUCKET_NAME
      volumeAttributes:
        ...
        gcsfuseMetadataPrefetchOnMount: "true"

Reemplaza lo siguiente:

  • BUCKET_NAME es el nombre de tu depósito.

Los recursos del contenedor de inicialización pueden variar según el contenido del bucket y el diseño jerárquico, por lo que se recomienda establecer recursos de sidecar de recuperación previa de metadatos personalizados para obtener límites más altos.

Linux

Ejecuta de forma manual el comando ls -R en el punto de activación de Cloud Storage FUSE para enumerar de forma recurrente todos los archivos y propagar previamente la caché de metadatos:

ls -R MOUNT_POINT > /dev/null

Reemplaza lo siguiente:

MOUNT_POINT: Es la ruta de acceso al punto de activación de Cloud Storage FUSE.

Compute Engine

Ejecuta de forma manual el comando ls -R en el punto de activación de Cloud Storage FUSE para enumerar de forma recurrente todos los archivos y propagar previamente la caché de metadatos:

ls -R MOUNT_POINT > /dev/null

Reemplaza lo siguiente:

MOUNT_POINT: Es la ruta de acceso al punto de activación de Cloud Storage FUSE.

Habilita el almacenamiento en caché de archivos y las descargas paralelas

El almacenamiento en caché de archivos te permite almacenar datos de archivos a los que se accede con frecuencia de forma local en tu máquina, lo que acelera las lecturas repetidas y reduce los costos de Cloud Storage. Cuando habilitas el almacenamiento en caché de archivos, las descargas paralelas también se habilitan automáticamente. Las descargas paralelas utilizan varios trabajadores para descargar un archivo en paralelo con el directorio de caché de archivos como un búfer de carga previa, lo que genera un tiempo de carga del modelo nueve veces más rápido.

Para obtener información sobre cómo habilitar y configurar el almacenamiento en caché de archivos y las descargas paralelas, consulta Habilita y configura el comportamiento del almacenamiento en caché de archivos. Para usar una configuración de ejemplo, consulta Configuración de ejemplo para habilitar el almacenamiento en caché de archivos y las descargas paralelas.

Consideraciones sobre las GPU de Cloud y las Cloud TPU para usar el almacenamiento en caché de archivos y las descargas paralelas

La caché de archivos se puede alojar en SSD locales, RAM, Persistent Disk o Google Cloud Hyperdisk con las siguientes instrucciones. En todos los casos, los datos o el archivo grande individual deben ajustarse a la capacidad disponible del directorio de caché de archivos, que se controla con el campo max-size-mb o la opción --file-cache-max-size-mb.

Consideraciones sobre las GPUs de Cloud

Las SSD locales son ideales para los datos de entrenamiento y las descargas de puntos de control. Los tipos de máquinas de GPU de Cloud incluyen capacidad de SSD que se puede usar, como los tipos de máquinas A4 que incluyen 12 TiB de SSD.

  • Un disco RAM proporciona el mejor rendimiento para cargar pesos de modelos debido a su tamaño pequeño en comparación con la cantidad de RAM sin usar en el sistema.

  • Tanto Persistent Disk como Google Cloud Hyperdisk se pueden usar como caché.

Consideraciones sobre Cloud TPU

Cloud TPU no admite SSD locales. Si usas el almacenamiento en caché de archivos en Cloud TPU sin modificaciones, la ubicación predeterminada que se usa es el volumen de arranque, lo que no se recomienda y genera un rendimiento deficiente.

En lugar del volumen de arranque, te recomendamos usar un disco RAM, que se prefiere por su rendimiento y sin costo incremental. Sin embargo, un disco RAM suele tener un tamaño limitado y es más útil para entregar pesos de modelos o descargas de puntos de control, según el tamaño del punto de control y la RAM disponible. Además, recomendamos usar Persistent Disk y Google Cloud Hyperdisk para el almacenamiento en caché.

Ejemplo de configuración para habilitar el almacenamiento en caché de archivos y las descargas paralelas

De forma predeterminada, la caché de archivos usa una SSD local si el modo ephemeral-storage-local-ssd está habilitado para el nodo de Google Kubernetes Engine. Si no hay una SSD local disponible, por ejemplo, en las máquinas de Cloud TPU, la caché de archivos usa el disco de arranque del nodo de Google Kubernetes Engine, lo que no se recomienda. En este caso, puedes usar un disco RAM como directorio de caché, pero ten en cuenta la cantidad de RAM disponible para el almacenamiento en caché de archivos en comparación con la que necesita el pod.

Opciones de gcsfuse

gcsfuse --file-cache-max-size-mb=-1 \
      --file-cache-cache-file-for-range-read=true \
      --file-cache-enable-parallel-downloads=true \
      BUCKET_NAME

Reemplaza lo siguiente:

  • BUCKET_NAME es el nombre de tu depósito.

Archivo de configuración

file-cache:
  max-size-mb: -1
  cache-file-for-range-read: true
  enable-parallel-downloads: true

GPU de Cloud 

mountOptions:
    - file-cache:max-size-mb:-1
    - file-cache:cache-file-for-range-read:true
    - file-cache:enable-parallel-downloads:true

# RAM disk file cache if LSSD not available. Uncomment to use
# volumes:
#   - name: gke-gcsfuse-cache
#     emptyDir:
#       medium: Memory

Cloud TPU 

mountOptions:
    - file-cache:max-size-mb:-1
    - file-cache:cache-file-for-range-read:true
    - file-cache:enable-parallel-downloads:true

volumes:
    - name: gke-gcsfuse-cache
      emptyDir:
        medium: Memory

Compute Engine

gcsfuse --file-cache-max-size-mb=-1 \
      --file-cache-cache-file-for-range-read=true \
      --file-cache-enable-parallel-downloads=true \
      BUCKET_NAME MOUNT_POINT

Reemplaza lo siguiente:

  • BUCKET_NAME es el nombre de tu depósito.

  • MOUNT_POINT es el directorio local donde se activará tu bucket. Por ejemplo, /path/to/mount/point

Inhabilitar las entradas de caché de estadísticas negativas

De forma predeterminada, Cloud Storage FUSE almacena en caché las entradas de estadísticas negativas, es decir, las entradas de archivos que no existen, con un TTL de cinco segundos. En las cargas de trabajo en las que los archivos se crean o borran con frecuencia, como los puntos de control distribuidos, estas entradas almacenadas en caché pueden quedar obsoletas con rapidez, lo que genera problemas de rendimiento. Para evitar esto, te recomendamos que inhabilites la caché de estadísticas negativas para las cargas de trabajo de entrenamiento, entrega y puntos de control con el campo negative-ttl-secs o la opción --metadata-cache-negative-ttl-secs.

Sigue estas instrucciones para inhabilitar la caché de estadísticas negativas:

Opción gcsfuse

gcsfuse --metadata-cache-negative-ttl-secs=0 \
  BUCKET_NAME

Reemplaza lo siguiente:

  • BUCKET_NAME es el nombre de tu depósito.

Archivo de configuración

metadata-cache:
 negative-ttl-secs: 0

Google Kubernetes Engine

mountOptions:
    - metadata-cache:negative-ttl-secs:0

Compute Engine

gcsfuse --metadata-cache-negative-ttl-secs=0 \
  BUCKET_NAME MOUNT_POINT

Reemplaza lo siguiente:

  • BUCKET_NAME es el nombre de tu depósito.

  • MOUNT_POINT es el directorio local donde se activará tu bucket. Por ejemplo, /path/to/mount/point

Habilita las escrituras de transmisión

Las escrituras de transmisión suben datos directamente a Cloud Storage a medida que se escriben, lo que reduce la latencia y el uso del espacio en el disco. Esto es especialmente beneficioso para las escrituras secuenciales grandes, como los puntos de control. Las escrituras de transmisión están habilitadas de forma predeterminada en Cloud Storage FUSE versión 3.0 y posteriores.

Si las escrituras de transmisión no están habilitadas de forma predeterminada, usa las siguientes instrucciones para habilitarlas. Para habilitar las escrituras de transmisión, se requiere la versión 3.0 de Cloud Storage FUSE, que está disponible en las versiones 1.32.1-gke.1729000 o posteriores de Google Kubernetes Engine.

Opción gcsfuse

gcsfuse --enable-streaming-writes=true \
  BUCKET_NAME

Reemplaza lo siguiente:

  • BUCKET_NAME es el nombre de tu depósito.

Archivo de configuración

write:
 enable-streaming-writes: true

Google Kubernetes Engine

mountOptions:
    - write:enable-streaming-writes:true

Compute Engine

gcsfuse --enable-streaming-writes=true \
  BUCKET_NAME MOUNT_POINT

Reemplaza lo siguiente:

  • BUCKET_NAME es el nombre de tu depósito.

  • MOUNT_POINT es el directorio local donde se activará el bucket. Por ejemplo, /path/to/mount/point

Habilita las lecturas almacenadas en búfer

Las lecturas almacenadas en búfer pueden mejorar el rendimiento de lectura secuencial de archivos grandes de dos a cinco veces, ya que recuperan de forma asíncrona partes de un objeto de Cloud Storage en un búfer en memoria. Esto permite que las lecturas posteriores se realicen desde el búfer en lugar de requerir llamadas de red.

Ten en cuenta lo siguiente antes de habilitar las lecturas almacenadas en búfer:

  • Las lecturas almacenadas en búfer no son compatibles con el almacenamiento en caché de archivos. Si se habilitan las lecturas almacenadas en búfer y el almacenamiento en caché de archivos, el almacenamiento en caché de archivos tendrá prioridad y se ignorarán las lecturas almacenadas en búfer.

  • Las lecturas almacenadas en búfer pueden consumir una cantidad significativa de memoria y recursos de procesamiento.

Para habilitar las lecturas almacenadas en búfer, sigue estas instrucciones:

Opciones de CLI

gcsfuse --enable-buffered-read=true \
  BUCKET_NAME

Reemplaza lo siguiente:

  • BUCKET_NAME es el nombre de tu depósito.

Archivo de configuración

read:
 enable-buffered-read: true

Aumenta el tamaño de lectura anticipada del kernel

Para las cargas de trabajo que involucran principalmente lecturas secuenciales de archivos grandes, como la entrega y las restauraciones de puntos de control, aumentar el tamaño de lectura anticipada puede mejorar significativamente el rendimiento. Esto se puede hacer con el parámetro del kernel de Linux read_ahead_kb en tu máquina local. Te recomendamos que aumentes el parámetro de kernel read_ahead_kb a 1 MB en lugar de usar la cantidad predeterminada de 128 KB que se establece en la mayoría de las distribuciones de Linux. En el caso de las instancias de Compute Engine, se requieren permisos sudo o root para aumentar correctamente el parámetro del kernel.

Para aumentar el parámetro de kernel read_ahead_kb a 1 MB para un directorio específico activado de Cloud Storage FUSE, sigue estas instrucciones. Tu bucket debe estar activado en Cloud Storage FUSE antes de ejecutar el comando; de lo contrario, el parámetro del kernel no aumenta.

Para los buckets zonales, Cloud Storage FUSE administra automáticamente el parámetro del kernel read_ahead_kb en la versión 1.35.0-gke.3047001 o posterior de Google Kubernetes Engine, y en los entornos de Compute Engine que usan la versión 3.7.0 o posterior de Cloud Storage FUSE. Debido a que esto se controla de forma automática, la opción de activación read_ahead_kb ya no se aplica; se ignorará cualquier valor que proporciones. Ten en cuenta que, en los entornos de Compute Engine, Cloud Storage FUSE requiere permisos de sudo sin contraseña o de administrador para administrar automáticamente este parámetro.

Google Kubernetes Engine

mountOptions:
    - read_ahead_kb=1024

Compute Engine

export MOUNT_POINT=/path/to/mount/point
echo 1024 | sudo tee /sys/class/bdi/0:$(stat -c "%d" $MOUNT_POINT)/read_ahead_kb

Reemplaza lo siguiente:

  • /path/to/mount/point: Es la ruta de acceso en tu sistema de archivos local en el que se activa el bucket de Cloud Storage.

Inhabilitar el servicio de tokens de seguridad para evitar verificaciones redundantes

El controlador de CSI de Cloud Storage FUSE para Google Kubernetes Engine tiene verificaciones de acceso para garantizar la recuperabilidad de los Pods debido a una configuración incorrecta de las vinculaciones de Workload Identity entre el bucket y la cuenta de servicio de GKE, lo que puede alcanzar las cuotas predeterminadas de la API de Security Token Service a gran escala. Esto se puede inhabilitar configurando el atributo de volumen skipCSIBucketAccessCheck del controlador de CSI de volumen persistente. Te recomendamos que te asegures de que la cuenta de servicio de GKE tenga el acceso correcto al bucket de Cloud Storage de destino para evitar fallas de activación en el Pod.

Además, la cuota del servicio de tokens de seguridad debe aumentarse más allá del valor predeterminado de 6000 si un clúster de Google Kubernetes Engine consta de más de 6,000 nodos, lo que puede generar errores 429 si no se aumenta en implementaciones a gran escala. La cuota del servicio de tokens de seguridad debe aumentarse a través de la página Cuotas y límites. Te recomendamos que mantengas la cuota igual a la cantidad de activaciones. Por ejemplo, si hay 10,000 activaciones en el clúster, la cuota debería aumentarse a 10000.

Para establecer el atributo de volumen skipCSIBucketAccessCheck, consulta el siguiente ejemplo de configuración:

  volumeAttributes:
      - skipCSIBucketAccessCheck: "true"

Optimiza el rendimiento de los puntos de control de Orbax de OCDBT

Para las cargas de trabajo que usan puntos de control de Orbax con formato OCDBT, puedes mejorar el rendimiento de la entrega y el restablecimiento de puntos de control con la siguiente guía:

  • Establece páginas enormes transparentes en always: Establecer páginas enormes transparentes en always mejora el rendimiento, ya que reduce la fragmentación de la memoria y las llamadas al sistema. Este parámetro de configuración es más eficaz cuando se asignan grandes fragmentos de memoria, lo que es común en estas cargas de trabajo. Este parámetro de configuración se establece de forma predeterminada en las máquinas de Cloud TPU y solo se debe establecer en otros tipos de máquinas. Para habilitar páginas grandes transparentes en tu máquina local, ejecuta el siguiente comando con permisos de root.

    echo always | tee /sys/kernel/mm/transparent_hugepage/enabled

    En un entorno de GKE, puedes crear un Pod con privilegios para hacer lo mismo.

  • Aumenta el tamaño de lectura anticipada del kernel: Aumentar el tamaño de lectura anticipada del kernel a 1,024 KB mejora el rendimiento de lectura secuencial. Para obtener más información, consulta Aumenta el tamaño de lectura anticipada del kernel.

  • Establece ocdbt_target_data_file_size en 200 MiB: Establece ocdbt_target_data_file_size en 200 MiB, que es óptimo para el rendimiento de lectura con Cloud Storage FUSE.

  • Usa el almacenamiento en caché de DNS: El almacenamiento en caché de DNS reduce la latencia, ya que almacena en caché las búsquedas de DNS de forma local. En GKE, puedes habilitar NodeLocal DNSCache para almacenar en caché las búsquedas de DNS. Como alternativa, usa la versión 3.5 o posterior de Cloud Storage FUSE en Compute Engine, o la versión 1.34.1-gke.3899000 o posterior de GKE en un entorno de GKE.

Otras consideraciones sobre el rendimiento

Más allá de las optimizaciones principales que se analizaron, hay varios factores que pueden afectar de forma significativa el rendimiento general de Cloud Storage FUSE. En las siguientes secciones, se describen consideraciones de rendimiento adicionales que te recomendamos tener en cuenta cuando uses Cloud Storage FUSE.

Aumenta el límite de cambio de nombre para los buckets que no son de HNS

Las cargas de trabajo de puntos de control siempre deben realizarse con un bucket que tenga habilitado el espacio de nombres jerárquico debido a los cambios de nombre atómicos y más rápidos, y a las QPS más altas para las lecturas y escrituras. Sin embargo, si aceptas el riesgo de que los cambios de nombre de los directorios no sean atómicos y tarden más, puedes usar el campo rename-dir-limit o la opción --rename-dir-limit si realizas un punto de control con buckets sin un espacio de nombres jerárquico para especificar un límite en la cantidad de archivos o de operaciones que participan en una operación de cambio de nombre de directorio en un momento determinado.

Te recomendamos establecer este parámetro de configuración en un valor alto para evitar fallas en los puntos de control. Debido a que Cloud Storage FUSE usa un espacio de nombres plano y los objetos son inmutables, una operación de cambio de nombre de directorio implica cambiar el nombre y borrar todos los archivos individuales dentro del directorio. Puedes controlar la cantidad de archivos afectados por una operación de cambio de nombre si configuras la opción gcsfuse de rename-dir-limit.

Usa las siguientes instrucciones para establecer la opción de configuración rename-dir-limit:

Opción gcsfuse

gcsfuse --rename-dir-limit=200000 \
  BUCKET_NAME

Reemplaza lo siguiente:

  • BUCKET_NAME es el nombre de tu depósito.

Archivo de configuración

file-system:
 rename-dir-limit: 200000

Google Kubernetes Engine

mountOptions:
    - rename-dir-limit=200000

Compute Engine

gcsfuse --rename-dir-limit=200000 \
  BUCKET_NAME MOUNT_POINT

Reemplaza lo siguiente:

  • BUCKET_NAME es el nombre de tu depósito.

  • MOUNT_POINT es el directorio local donde se activará el bucket. Por ejemplo, /path/to/mount/point

Almacenamiento en caché de listas del kernel

La caché de la lista es una caché para la lista de directorios y archivos, o ls, respuestas que mejora la velocidad de las operaciones de listas. A diferencia de la caché de estadísticas, que administra Cloud Storage FUSE, la caché de listas se mantiene en la caché de páginas del kernel y la controla el kernel según la disponibilidad de la memoria.

Habilitar el almacenamiento en caché de la lista de kernels es más beneficioso para los siguientes casos de uso:

  • Cargas de trabajo con listas de directorios repetidas: Esta configuración es especialmente útil para las cargas de trabajo que realizan listas de directorios completas con frecuencia, como las rondas de entrenamiento de IA/AA. Esto puede beneficiar las cargas de trabajo de entrega y entrenamiento.

  • Activaciones de solo lectura: Se recomienda el almacenamiento en caché de listas con activaciones de solo lectura para evitar problemas de coherencia.

La habilitación del almacenamiento en caché de la lista del kernel debe realizarse con precaución y solo debe usarse si el sistema de archivos es de solo lectura y no se esperan cambios en el contenido del directorio durante la ejecución de un trabajo. Esto se debe a que, con esta marca, la aplicación local nunca ve actualizaciones, en especial si el TTL se establece en -1.

Por ejemplo, el Cliente 1 enumera directoryA, lo que hace que directoryA sea un residente en la caché de la lista del kernel. Cliente 2 crea fileB en directoryA en el bucket de Cloud Storage. El cliente 1 verifica de forma continua fileB en directoryA, lo que, en esencia, verifica la entrada de caché de la lista del kernel y nunca pasa por la red. El cliente 1 no ve que hay un archivo nuevo en el directorio porque la lista de archivos se entrega de forma continua desde la caché de la lista del kernel local. Luego, Cliente 1 agota el tiempo de espera y el programa deja de funcionar.

Usa la siguiente instrucción para habilitar el almacenamiento en caché de listas:

Opción gcsfuse

gcsfuse --kernel-list-cache-ttl-secs=-1 \
  BUCKET_NAME

Reemplaza lo siguiente:

  • BUCKET_NAME es el nombre de tu depósito.

Archivo de configuración

file-system:
 kernel-list-cache-ttl-secs: -1

Google Kubernetes Engine

mountOptions:
    - file-system:kernel-list-cache-ttl-secs:-1

Compute Engine

gcsfuse --kernel-list-cache-ttl-secs=-1 \
  BUCKET_NAME MOUNT_POINT

Reemplaza lo siguiente:

  • BUCKET_NAME es el nombre de tu depósito.

  • MOUNT_POINT es el directorio local donde se activará el bucket. Por ejemplo, /path/to/mount/point

Cuando usas la opción de activación file-system:kernel-list-cache-ttl-secs, los valores significan lo siguiente:

  • Un valor positivo representa el TTL en segundos para mantener la respuesta de la lista de directorios en la caché de la página del kernel.

  • Un valor de -1 omite el vencimiento de la entrada y muestra la respuesta de la lista desde la caché cuando está disponible.

Usa la caché de compilación persistente (JIT) de JAX con Cloud Storage FUSE

JAX admite la caché de compilación justo a tiempo (JIT), una caché de compilación persistente opcional que almacena artefactos de funciones compiladas. Cuando usas esta caché, puedes acelerar de forma significativa las ejecuciones de secuencias de comandos posteriores, ya que se evitan los pasos de compilación redundantes.

Para habilitar el almacenamiento en caché JIT, debes cumplir con los siguientes requisitos:

  • Usa la versión más reciente de JAX: usa las versiones 0.5.1 o posteriores de JAX para obtener las funciones y optimizaciones de caché más recientes.

  • Maximiza la capacidad de la caché: Para evitar la degradación del rendimiento debido a la expulsión de la caché, considera establecer un tamaño de caché ilimitado, en especial si deseas anular la configuración predeterminada. Para ello, configura la variable de entorno:

    export JAX_COMPILATION_CACHE_MAX_SIZE=-1

  • Ensure checkpoint pod YAML: Usa la configuración del punto de control para el punto de montaje de la caché de JIT de JAX.

Configura la dirección de flujo de recepción (RFS) para A4X

En las instancias de Compute Engine, la dirección de paquetes de recepción (RPS) y la dirección de flujo de recepción (RFS) funcionan juntas para mejorar el rendimiento de la red distribuyendo de forma inteligente el procesamiento de paquetes de red en varias CPUs. Recomendamos estos parámetros de configuración para el tráfico de red de alta velocidad en tipos de máquinas como A4X.

  • El RPS distribuye los paquetes de red entrantes entre diferentes CPUs para su procesamiento. Esto ayuda a balancear la carga y evitar que una sola CPU se convierta en un cuello de botella, lo que es especialmente útil para el tráfico de red de alta velocidad y puede contribuir a una latencia más baja.

  • RFS se basa en RPS para reducir aún más la latencia de la red, ya que mejora la eficiencia de la caché de la CPU. Dirige los paquetes al núcleo de CPU específico en el que se ejecuta la aplicación que consumirá los paquetes, lo que aumenta la tasa de acierto de caché de datos de la CPU y genera una menor latencia de red.

Beneficios de rendimiento

RFS mejora significativamente el rendimiento en varias cargas de trabajo, lo que aumenta la capacidad de procesamiento hasta un 40%.

Consideraciones

Si bien son eficaces bajo carga, es posible que estos parámetros de configuración no sean útiles en todas las situaciones:

  • Cargas de trabajo de un solo flujo o subproceso: Una carga de trabajo de un solo flujo se produce cuando todo el tráfico de red usa una sola conexión de red (por ejemplo, una sola transferencia de archivos masiva a través de una conexión TCP). Estas aplicaciones suelen obtener pocos beneficios y, incluso, pueden experimentar una pequeña disminución de la capacidad de procesamiento (p.ej., ~7.7% en pruebas específicas de nginx). Las aplicaciones de flujo único suelen ser poco comunes en contextos de alto rendimiento.

  • Migración frecuente de subprocesos: Si los subprocesos de la aplicación se mueven con frecuencia entre las CPUs, RFS actualiza constantemente las asignaciones de CPU(por ejemplo, las aplicaciones que usan grandes grupos de subprocesos de trabajo dinámicos en los que las solicitudes se transfieren con frecuencia entre diferentes núcleos), lo que puede generar un tráfico excesivo entre las CPUs y una reordenación de paquetes.

Secuencia de comandos de configuración

Ejecuta la siguiente secuencia de comandos en el sistema operativo invitado de tu instancia de Compute Engine. La secuencia de comandos requiere permisos sudo o root para modificar los parámetros del kernel.

La secuencia de comandos habilita los RPS, asigna las colas de red a las CPU disponibles de forma rotativa y establece el tamaño de la tabla de flujo por cola en 65536.

#!/bin/bash
set -e

# Note: This script uses 'apt' and is intended for Debian-based systems.
# If 'iproute2' is not found, you may need to run 'sudo apt update' first.
sudo apt install -y iproute2

# This script enables and configures RPS (Receive Packet Steering) and RFS
# (Receive Flow Steering) for the primary network interface.
# It creates a 1:1 mapping of CPUs to receive queues and sets a specific
# flow count for each queue.

# --- Configuration ---
# The desired number of flow entries per receive queue.
RPS_FLOW_CNT_PER_QUEUE=65536

# --- Script Body ---

# 1. Auto-detect the primary network interface.
INTERFACE=$(ip route | grep default | awk '{print $5}' | head -n 1)

if [ -z "$INTERFACE" ]; then
  echo "Error: Could not determine the primary network interface."
  exit 1
fi
echo "Primary network interface detected: $INTERFACE"

echo "Starting RPS/RFS configuration for interface: $INTERFACE"

# 2. Determine the number of receive queues for the interface.
NUM_QUEUES=$(ls -d /sys/class/net/$INTERFACE/queues/rx-* 2>/dev/null | wc -l)
if [ "$NUM_QUEUES" -eq 0 ]; then
  echo "Error: No receive queues found for interface $INTERFACE."
  echo "Please check if the network driver supports multi-queue."
  exit 1
fi
echo "Found $NUM_QUEUES receive queues for interface $INTERFACE."

# 3. Determine the number of CPUs.
NUM_CPUS=$(nproc)
if [ -z "$NUM_CPUS" ] || [ "$NUM_CPUS" -eq 0 ]; then
  echo "Error: Could not determine the number of CPUs."
  exit 1
fi
echo "Found $NUM_CPUS CPUs."

# 4. Calculate and set the total socket flow entries.
# This is the total number of entries in the global socket flow table.
RPS_SOCK_FLOW_ENTRIES=$((NUM_QUEUES * RPS_FLOW_CNT_PER_QUEUE))
echo "Setting the total RPS socket flow entries to $RPS_SOCK_FLOW_ENTRIES..."
if ! echo "$RPS_SOCK_FLOW_ENTRIES" | sudo tee /proc/sys/net/core/rps_sock_flow_entries > /dev/null; then
  echo "Error: Failed to set rps_sock_flow_entries. Please run with sufficient privileges."
  exit 1
fi

# 5. Configure each receive queue.
for i in $(seq 0 $((NUM_QUEUES - 1))); do
  RX_QUEUE="/sys/class/net/$INTERFACE/queues/rx-$i"

  # a) Assign a CPU to this queue (round-robin).
  CPU_INDEX=$((i % NUM_CPUS))
  CPU_BITMAP_HEX=$(printf '%x' $((1 << CPU_INDEX)))
  echo "Assigning CPU $CPU_INDEX (bitmap: $CPU_BITMAP_HEX) to queue rx-$i"
  if ! echo "$CPU_BITMAP_HEX" | sudo tee "$RX_QUEUE/rps_cpus" > /dev/null; then
    echo "Error writing bitmap to $RX_QUEUE/rps_cpus"
    exit 1
  fi

  # b) Set the flow count for this queue.
  echo "Setting flow count for $RX_QUEUE to $RPS_FLOW_CNT_PER_QUEUE"
  if ! echo "$RPS_FLOW_CNT_PER_QUEUE" | sudo tee "$RX_QUEUE/rps_flow_cnt" > /dev/null; then
    echo "Error writing to $RX_QUEUE/rps_flow_cnt"
    exit 1
  fi
done

echo "RPS and RFS configuration updated successfully for $INTERFACE."

¿Qué sigue?