En esta página, se proporciona orientación para mejorar Cloud Storage FUSE con funciones y configuraciones clave de Cloud Storage FUSE para lograr el máximo rendimiento 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 tres métodos:
Solo para Google Kubernetes Engine: archivos YAML de muestra de Google Kubernetes Engine
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 de 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 nuevo destino:
Controles
Capacitación
Entrega
Almacenamiento en caché de
jax.jit()
Las configuraciones recomendadas 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 alto ancho de banda. Los tipos de máquinas de Cloud TPU y GPU de Cloud 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 configuraciones como las siguientes:
A3 Mega: 1.8 TiB de memoria, con 6 TiB de LSSD
Cloud TPU v5e: 188 GiB de memoria, sin LSSD
Cloud TPU v5p: 448 GiB de memoria, sin LSSD
Cloud TPU v6 (Trillium): 1.5 TiB de memoria, sin LSSD
Usa buckets con el espacio de nombres jerárquico habilitado
Siempre usa 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.
Los beneficios del espacio de nombres jerárquico incluyen lo siguiente:
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 iniciales de lectura de objetos por segundo y 8,000 solicitudes iniciales de escritura de objetos, lo que es significativamente mayor que los buckets planos típicos de Cloud Storage FUSE, que ofrecen solo 5,000 solicitudes iniciales de lectura de objetos por segundo y 1,000 solicitudes iniciales de escritura de objetos.
El espacio de nombres jerárquico proporciona cambios de nombre de directorios 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 directorios 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 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 1.31.1-gke.2008000 o posteriores de Google Kubernetes Engine.
Cómo realizar 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 un montaje específico del directorio acelera las llamadas de lista y reduce la cantidad total de llamadas de lista y de 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 a bucket o directorios generan automáticamente llamadas de lista y de estadísticas para cada archivo o directorio de la ruta.
Para activar un directorio específico, usa uno de los siguientes métodos:
Google Kubernetes Engine
Usa la siguiente configuración de activación con el controlador CSI de Cloud Storage FUSE para Google Kubernetes Engine:
volumeHandle: BUCKET_NAME
- only-dir:DIRECTORY_NAME
Aquí:
BUCKET_NAME
es el nombre del bucket en el que deseas activar el directorio.DIRECTORY_NAME
es 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
Aquí:
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.
Antes de aumentar los valores de la caché de metadatos, ten en cuenta lo siguiente:
Solo se debe establecer un tiempo de actividad (TTL) infinito para los volúmenes que son de solo lectura o de escritura solo para nuevos.
La caché de metadatos solo debe habilitarse para que aumente significativamente de 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 crecer hasta alcanzar 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 estas instrucciones para configurar Cloud Storage FUSE de modo que almacene en caché una gran cantidad de metadatos y omita el vencimiento de los metadatos:
Opciones de CLI
gcsfuse --metadata-cache-ttl-secs=-1 \ --stat-cache-max-size-mb=-1 \ --type-cache-max-size-mb=-1 \ BUCKET_NAME MOUNT_POINT
Aquí:
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
Archivo de configuración
metadata-cache: stat-cache-max-size-mb: -1 ttl-secs: -1 type-cache-max-size-mb: -1
Google Kubernetes Engine
mountOptions: - metadata-cache:ttl-secs:-1 - metadata-cache:stat-cache-max-size-mb:-1 - metadata-cache:type-cache-max-size-mb:-1
Compute Engine
gcsfuse --metadata-cache-ttl-secs=-1 \ --stat-cache-max-size-mb=-1 \ --type-cache-max-size-mb=-1 \ BUCKET_NAME MOUNT_POINT
Aquí:
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
Cómo propagar previamente la caché de metadatos
Antes de ejecutar una carga de trabajo, te recomendamos que propagues previamente la caché de metadatos, lo que mejora significativamente el rendimiento y reduce sustancialmente la cantidad de llamadas de metadatos a Cloud Storage, en especial si se usa la opción de configuración implicit-dirs
. El controlador de CSI de Cloud Storage FUSE para GKE proporciona una API que controla la precarga de la caché de metadatos. Consulta Usa la recuperación previa de metadatos para precargar la caché de metadatos.
Para completar previamente 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
.
No se necesita el método initContainer
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"
Aquí:
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 personalizados de sidecar de recuperación previa de metadatos para 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 recursiva todos los archivos y propagar previamente la caché de metadatos:
ls -R MOUNT_POINT > /dev/null
Aquí:
MOUNT_POINT
: Es la ruta de acceso al punto de montaje 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 recursiva todos los archivos y propagar previamente la caché de metadatos:
ls -R MOUNT_POINT > /dev/null
Aquí:
MOUNT_POINT
: Es la ruta de acceso al punto de montaje 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 muestra, consulta Configuración de muestra para habilitar el almacenamiento en caché de archivos y las descargas paralelas.
Consideraciones sobre las GPUs y 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 la configuración de max-size-mb
.
Consideraciones sobre las GPUs de Cloud
Los SSD locales son ideales para los datos de entrenamiento y las descargas de puntos de control. Los tipos de máquinas con 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 del modelo 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
Las Cloud TPU no admiten 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 que uses un disco RAM, que es preferible por su rendimiento y porque no tiene costos incrementales. Sin embargo, un disco RAM suele tener un tamaño limitado y es más útil para entregar pesos del modelo o descargas de puntos de control, según el tamaño del punto de control y la RAM disponible. Además, te recomendamos que uses Persistent Disk y Google Cloud Hyperdisk para fines de 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 CLI
gcsfuse --file-cache-max-size-mb: -1 \ --file-cache-cache-file-for-range-read: true \ --file-cache-enable-parallel-downloads: true \ BUCKET_NAME
Aquí:
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
Aquí:
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
Inhabilita 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 la creación de puntos de control distribuidos, estas entradas almacenadas en caché pueden volverse obsoletas rápidamente, 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 creación de puntos de control con la opción de configuración negative-ttl-secs
.
Sigue estas instrucciones para inhabilitar la caché de estadísticas negativas:
Opciones de CLI
gcsfuse --metadata-cache-negative-ttl-secs: 0 \ BUCKET_NAME
Aquí:
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
Aquí:
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 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 3.0 y versiones posteriores.
Si las escrituras de transmisión no están habilitadas de forma predeterminada, sigue estas 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.
Opciones de CLI
gcsfuse --enable-streaming-writes: true \ BUCKET_NAME
Aquí:
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
Aquí:
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
Aumenta el tamaño de la lectura anticipada del kernel
Para las cargas de trabajo que implican principalmente lecturas secuenciales de archivos grandes, como la entrega y las restauraciones de puntos de control, aumentar el tamaño de la 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 del 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 de sudo
o root
para aumentar correctamente el parámetro del kernel.
Para aumentar el parámetro del kernel read_ahead_kb
a 1 MB para un directorio específico de Cloud Storage FUSE que se haya activado, sigue las instrucciones que se indican a continuación. Tu bucket debe estar activado en Cloud Storage FUSE antes de ejecutar el comando. De lo contrario, el parámetro del kernel no aumentará.
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
Aquí:
MOUNT_POINT
: Es la ruta de acceso al punto de montaje de Cloud Storage FUSE.
Inhabilita 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 recuperación de Pods debido a la configuración incorrecta por parte del usuario de las vinculaciones de identidades para cargas de trabajo entre el bucket y la cuenta de servicio de GKE, lo que puede afectar 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 adecuado al bucket de Cloud Storage de destino para evitar errores de montaje del pod.
Además, la cuota del servicio de token 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 de 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 debe aumentarse a 10000
.
Para establecer el atributo de volumen skipCSIBucketAccessCheck
, consulta la siguiente configuración de ejemplo:
volumeAttributes: - skipCSIBucketAccessCheck: "true"
Otras consideraciones sobre el rendimiento
Además de las optimizaciones principales que se analizaron, varios otros factores pueden afectar de manera significativa el rendimiento general de Cloud Storage FUSE. En las siguientes secciones, se describen consideraciones adicionales sobre el rendimiento que recomendamos tener en cuenta cuando usas 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 un mayor QPS 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 la opción de configuración rename-dir-limit
si realizas puntos de control con buckets sin espacio de nombres jerárquico para especificar un límite en la cantidad de archivos u operaciones involucrados en una operación de cambio de nombre de directorio en cualquier momento.
Recomendamos establecer la opción de configuración rename-dir-limit
en un valor alto para evitar errores de creación de puntos de control. Dado 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 configurando la opción de configuración rename-dir-limit
.
Sigue estas instrucciones para establecer la opción de configuración rename-dir-limit
:
Opciones de CLI
gcsfuse --rename-dir-limit: 200000 \ BUCKET_NAME
Aquí:
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
Aquí:
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
Almacenamiento en caché de la lista de kernels
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 las cachés de estadísticas y tipos, que administra Cloud Storage FUSE, la caché de la lista se mantiene en la caché de la página del kernel y el kernel la controla 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 ejecuciones de entrenamiento de IA/AA. Esto puede beneficiar tanto las cargas de trabajo de entrenamiento como las de entrega.
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 realmente de solo lectura, sin cambios esperados 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, Cliente 1 incluye directoryA
, lo que hace que directoryA
sea residente en la caché de la lista del kernel. Cliente 2 crea fileB
en directoryA
en el bucket de Cloud Storage. Cliente 1 verifica continuamente la presencia de fileB
en directoryA
, lo que equivale a verificar la entrada de la caché de la lista del kernel y nunca se conecta a la red. 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 se interrumpe.
Usa la siguiente instrucción para habilitar el almacenamiento en caché de listas:
Opciones de CLI
gcsfuse --kernel-list-cache-ttl-secs: -1 \ BUCKET_NAME
Aquí:
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
Aquí:
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
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é Just-In-Time (JIT), una caché de compilación persistente opcional que almacena artefactos de funciones compiladas. Cuando usas esta caché, puedes acelerar significativamente las ejecuciones de secuencias de comandos posteriores, ya que evitas 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 aprovechar las optimizaciones y las funciones de caché más recientes.
Maximiza la capacidad de la caché: Para evitar la degradación del rendimiento debido al desalojo de la caché, considera establecer un tamaño de caché ilimitado, en especial si deseas anular la configuración predeterminada. Para lograrlo, configura la variable de entorno de la siguiente manera:
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.
¿Qué sigue?
Usa un archivo YAML de ejemplo de Google Kubernetes Engine para configurar las prácticas recomendadas de ajuste.
Obtén más información sobre las opciones del archivo de configuración de Cloud Storage FUSE.
Obtén más información sobre las opciones de la CLI de Cloud Storage FUSE.