Mc: Se eliminan las cargas desde el cliente MC

Verifique el código de salida. Al copiar muchos archivos, mc puede usar mucha memoria. Si este es el caso, entonces el asesino de memoria insuficiente de Linux puede estar causando esto.

[root@aws-cli-5c67c9bfb-vvt4d /]# mc mirror rook-ceph-rgw-my-store-a/orderbookevents-a rook-ceph-rgw-my-store-b/orderbookevents-b
...2020-01-08-00-20-00-000-execution.raw:  98.67 GiB / 98.67 GiB ┃▓▓▓▓▓▓▓┃ 297.81 MiB/s
Killed
[root@aws-cli-5c67c9bfb-vvt4d /]# echo $?
137

Estoy ejecutando el mío en kubernetes, así que necesitaba mirar los registros del nodo para obtener el error

Sep 21 16:54:07 lddata-live-kubeworker03 kernel: Out of memory: Kill process 25008 (mc) score 1151 or sacrifice child
Sep 21 16:54:07 lddata-live-kubeworker03 kernel: Killed process 25011 (mc), UID 0, total-vm:9874000kB, anon-rss:8634100kB, file-rss:0kB, shmem-rss:0kB
Sep 21 16:54:07 lddata-live-kubeworker03 kernel: rados_async invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=1000
Sep 21 16:54:07 lddata-live-kubeworker03 kernel: rados_async cpuset=docker-ec3ef33f5359ee048f1bf4ca32a94db4b8008a12ffcc1e99e42665021a31d50d.scope mems_allowed=0
Sep 21 16:54:07 lddata-live-kubeworker03 kernel: CPU: 5 PID: 29051 Comm: rados_async Kdump: loaded Tainted: G               ------------ T 3.10.0-1062.9.1.el7.x86_64 #1
Sep 21 16:54:07 lddata-live-kubeworker03 kernel: Hardware name: Red Hat KVM, BIOS 1.11.1-4.module_el8.2.0+320+13f867d7 04/01/2014
Sep 21 16:54:07 lddata-live-kubeworker03 kernel: Call Trace:
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaf37ac23>] dump_stack+0x19/0x1b
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaf375ce9>] dump_header+0x90/0x229
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaed06142>] ? ktime_get_ts64+0x52/0xf0
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaedc1714>] oom_kill_process+0x254/0x3e0
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaed32e71>] ? cpuset_mems_allowed_intersects+0x21/0x30
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaedc11bd>] ? oom_unkillable_task+0xcd/0x120
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaedc1266>] ? find_lock_task_mm+0x56/0xc0
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaedc1f66>] out_of_memory+0x4b6/0x4f0
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaedc8a6f>] __alloc_pages_nodemask+0xacf/0xbe0
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaee16b28>] alloc_pages_current+0x98/0x110
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaedbd617>] __page_cache_alloc+0x97/0xb0
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaedc01d8>] filemap_fault+0x298/0x490
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffc02f155e>] __xfs_filemap_fault+0x7e/0x1d0 [xfs]
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaecd4ffe>] ? finish_task_switch+0x4e/0x1c0
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffc02f175c>] xfs_filemap_fault+0x2c/0x30 [xfs]
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaedec15a>] __do_fault.isra.61+0x8a/0x100
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaedec70c>] do_read_fault.isra.63+0x4c/0x1b0
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaedf11ba>] handle_pte_fault+0x22a/0xe20
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaecc9e30>] ? hrtimer_get_res+0x50/0x50
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaedf3ecd>] handle_mm_fault+0x39d/0x9b0
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaf388653>] __do_page_fault+0x213/0x500
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaf388a26>] trace_do_page_fault+0x56/0x150
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaf387fa2>] do_async_page_fault+0x22/0xf0
Sep 21 16:54:07 lddata-live-kubeworker03 kernel:  [<ffffffffaf3847a8>] async_page_fault+0x28/0x30
Sep 21 16:54:07 lddata-live-kubeworker03 kernel: Mem-Info:
Sep 21 16:54:07 lddata-live-kubeworker03 kernel: active_anon:13829373 inactive_anon:12475 isolated_anon:0
                                                           active_file:17 inactive_file:533 isolated_file:12
                                                           unevictable:0 dirty:0 writeback:0 unstable:0
                                                           slab_reclaimable:23949 slab_unreclaimable:38242
                                                           mapped:9831 shmem:14077 pagetables:36281 bounce:0
                                                           free:75345 free_pcp:34 free_cma:0

Recibo esto cuando copio lotes (> muchos miles) de archivos y supongo que mc está creando una lista en la memoria de todos los archivos que ve, incluidos algunos metadatos. Esto hace que eventualmente use toda la memoria en mi instancia de nodo y luego aparece el siempre útil asesino de oom y mata el proceso.

• https://tldp.org/LDP/abs/html/exitcodes.html
• https://support.circleci.com/hc/en-us/articles/115014359648-Salir-code-137-Out-of-memory

La duplicación de 153 archivos locales (6.5GB) en S3 usa más de 2GB de RAM, lo que lo elimina OOM en una VM de 2GB. No estoy familiarizado con los componentes internos de mc pero parece demasiado alto.

Editar: este comportamiento no se muestra durante la copia de local a local (sin uso de S3). Ocurre tanto en AWS S3 como en los controles remotos de Scaleway Object Storage. En una máquina con menos memoria limitada, la misma carga útil alcanza el uso de memoria de 6GB en 60-63 subprocesos.

Aquí hay una parte superior de perfil de mem:

% go tool pprof -lines ./mc/mc mem.pprof
(pprof) top
Showing nodes accounting for 7GB, 99.66% of 7.02GB total
Dropped 298 nodes (cum <= 0.04GB)
      flat  flat%   sum%        cum   cum%
       7GB 99.66% 99.66%        7GB 99.66%  github.com/minio/minio-go/v7.Client.putObjectMultipartStreamFromReadAt /home/twix/.go/pkg/mod/github.com/minio/minio-go/[email protected]/api-put-object-streaming.go:152
         0     0% 99.66%     7.02GB 99.94%  github.com/minio/mc/cmd.(*ParallelManager).addWorker.func1 /home/twix/tmp/mc_memory/mc/cmd/parallel-manager.go:83
         0     0% 99.66%     7.02GB 99.94%  github.com/minio/mc/cmd.(*S3Client).Put /home/twix/tmp/mc_memory/mc/cmd/client-s3.go:1008
         0     0% 99.66%     7.02GB 99.94%  github.com/minio/mc/cmd.(*mirrorJob).doMirror /home/twix/tmp/mc_memory/mc/cmd/mirror-main.go:363
         0     0% 99.66%     7.02GB 99.94%  github.com/minio/mc/cmd.(*mirrorJob).startMirror.func1 /home/twix/tmp/mc_memory/mc/cmd/mirror-main.go:584
         0     0% 99.66%     7.02GB 99.94%  github.com/minio/mc/cmd.putTargetStream /home/twix/tmp/mc_memory/mc/cmd/common-methods.go:322
         0     0% 99.66%     7.02GB 99.94%  github.com/minio/mc/cmd.uploadSourceToTargetURL /home/twix/tmp/mc_memory/mc/cmd/common-methods.go:551
         0     0% 99.66%     7.02GB 99.94%  github.com/minio/minio-go/v7.Client.PutObject /home/twix/.go/pkg/mod/github.com/minio/minio-go/[email protected]/api-put-object.go:212
         0     0% 99.66%     7.02GB 99.94%  github.com/minio/minio-go/v7.Client.putObjectCommon /home/twix/.go/pkg/mod/github.com/minio/minio-go/[email protected]/api-put-object.go:246
         0     0% 99.66%     7.02GB 99.94%  github.com/minio/minio-go/v7.Client.putObjectMultipartStream /home/twix/.go/pkg/mod/github.com/minio/minio-go/[email protected]/api-put-object-streaming.go:49

https://github.com/minio/minio-go/blob/master/api-put-object-streaming.go#L152 parece incriminado.
Este código fue introducido por https://github.com/minio/minio-go/pull/1357 , que "evita la carrera de datos copiando el búfer".

Sufro de un problema similar. En Kubernetes, si elimino los límites de recursos, mc consumirá cada fragmento de memoria que pueda tener en sus manos, y kswapd detiene la máquina, sin embargo, si limito la memoria a un concierto o dos, no parece haber ningún progreso, aunque no parece ser asesinado inmediatamente por k8s, sin embargo, parece morir después de un par de horas sin progreso.

Investigaremos que este es un cambio que era necesario para el cálculo de content-md5 en minio-go. Veré si hay una forma más limpia de solucionar este problema.

https://github.com/minio/minio-go/blob/master/api-put-object-streaming.go#L152 parece incriminado.
Este código fue introducido por minio / minio-go # 1357 , que "evita la carrera de datos copiando el búfer".

Este código es necesario porque no hay forma de buscar y leer desde múltiples compensaciones en paralelo en POSIX - * os. El archivo no está bloqueado. La introducción de un mutex simplemente serializaría todo.

El uso de memoria independiente es la única forma de cargar contenido en paralelo

Este problema se ha marcado automáticamente como obsoleto porque no ha tenido actividad reciente. Se cerrará después de 21 días si no se produce más actividad. Gracias por sus aportaciones.

Me encontré con el mismo problema, intenté reflejar archivos de video grandes usando mc mirror . de repente me quedé sin memoria y, afortunadamente, el kernel mató a mc .

No estoy seguro de cómo debería reflejar (¿rsync?) Mis archivos en minio.

Pensando en hacer un bucle de archivos en mi propio script de shell y luego usar la carga en streaming canalizando el archivo a mc .

mc mirror --disable-multipart

esta solución resolvió el problema de la memoria por ahora.

mc mirror --disable-multipart

esta solución resolvió el problema de la memoria por ahora.

También acelera mi mc mirror . Estoy intentando cargar millones de archivos pequeños.

Gracias @furkanmustafa , ¡funcionó a las

@harshavardhana, ¿le importa si podemos cambiar el nombre del título de este número "Mayor utilización de la memoria para la carga de varias partes" 🤗 o hay un tema mejor para discutir esto?

Este código es necesario porque no hay forma de buscar y leer desde múltiples compensaciones en paralelo en POSIX - * os. El archivo no está bloqueado. La introducción de un mutex simplemente serializaría todo.
El uso de memoria independiente es la única forma de cargar contenido en paralelo

¡Gracias por la explicación! Tengo un par de ideas. Pero antes de intentar comprender el problema https://github.com/minio/minio-go/issues/1355 , ¿de qué se trataba la raza? Porque si se trata de la contabilidad de compensación, podemos abrir el archivo varias veces o calcular las compensaciones manualmente, ¿WDYT? 🤗

¡Gracias por la explicación! Tengo un par de ideas. Pero antes de intentar entender el problema minio / minio-go # 1355 , ¿de qué se trataba la raza? Porque si se trata de la contabilidad de compensación, podemos abrir el archivo varias veces o calcular las compensaciones manualmente, ¿WDYT?

La carrera es de búsqueda simultánea en * sistema operativo. El archivo no es posible y no es seguro para subprocesos, lo que genera contenido potencialmente incorrecto en el destino

Entiendo que tienes esencialmente un puntero "compensado". Pero no necesitamos usar Seek, simplemente podríamos implementar nuestra propia verificación de compensación o simplemente ... abrir el mismo archivo 4 veces. Creo que es mejor que asignar 0,5 GB para una carga única 🤗

Entiendo que tienes esencialmente un puntero "compensado". Pero no necesitamos usar Seek, simplemente podríamos implementar nuestra propia verificación de compensación o simplemente ... abrir el mismo archivo 4 veces. Creo que es mejor que asignar 0,5 GB para una carga única

Correcto, pero la API no está diseñada para tomar 4 * os diferentes. Archivo @bwplotka, esto solo es posible si se proporciona el nombre completo de la ruta al cliente minio-go para que pueda abrir tantos fd's como sea necesario internamente.

Por ahora, establezca un PartSize () adecuado para garantizar que para los casos de uso más comunes no tenga que usar búferes 128MiB * 4 localmente @bwplotka

Ah sí, solo tenemos un lector.

Por ahora, establezca un PartSize () adecuado para garantizar que para los casos de uso más comunes no tenga que usar búferes 128MiB * 4 localmente @bwplotka

Me encantaría evitar esto, no creo que tenga sentido. PartSize debería controlar cómo interactúo con el protocolo HTTP y el objetivo minio. No debería controlar repentinamente cuánto se asigna. De la misma manera, cuando subo 6GB de archivo sin varias partes, no quiero que se asignen 6GB de mem, ¿verdad? Creo que esta es una falta de eficiencia importante que debemos eliminar. Ya puede ver cuántos problemas y proyectos se vieron afectados. Veamos cómo podemos mejorar esto.

Creo que podemos confiar en la lógica ReadAt , ¿no? ReadAt está usando pread que es seguro para subprocesos:

Las llamadas al sistema pread () y pwrite () son especialmente útiles en
aplicaciones multiproceso. Permiten que varios subprocesos
realizar E / S en el mismo descriptor de archivo sin verse afectado por
cambios en el archivo compensado por otros hilos.

Si no me equivoco, deberíamos poder evitar usar Seek sin problemas, ¿no? Podemos simplemente leer En el desplazamiento que queremos en un búfer de tamaño fijo más pequeño.

Alternativamente, comprobaría cómo lo está haciendo AWS SDK. ¿Quizás algo en lo que podamos inspirarnos?

Si no me equivoco, deberíamos poder evitar usar Seek sin problemas, ¿no? Podemos simplemente leer En el desplazamiento que queremos en un búfer de tamaño fijo más pequeño.

ReadAt también tuvimos otros problemas en el pasado @bwplotka , es por eso que lo volvimos a implementar para ser una implementación mucho más simple (predecible) aunque usamos más memoria al mismo tiempo.

Alternativamente, comprobaría cómo lo está haciendo AWS SDK. ¿Quizás algo en lo que podamos inspirarnos?

AWS SDK también está almacenando en búfer, ya que todos deben hacerlo debido a los requisitos de la API de S3.

Me encantaría evitar esto, no creo que tenga sentido. PartSize debería controlar cómo interactúo con el protocolo HTTP y el objetivo minio. No debería controlar repentinamente cuánto se asigna. De la misma manera, cuando subo 6GB de archivo sin varias partes, no quiero que se asignen 6GB de mem, ¿verdad? Creo que esta es una falta de eficiencia importante que debemos eliminar. Ya puede ver cuántos problemas y proyectos se vieron afectados. Veamos cómo podemos mejorar esto.

La asignación es necesaria sin importar qué @bwplotka porque el cálculo de content-md5 o sha256 debe calcularse antes de la carga. Si vuelve a buscar su fd si usa * os.File y es muy complicado administrar estas compensaciones de forma limpia y segura. El uso de ReadAt () hace que sea complicado porque luego necesita reflexionar sobre un io.Seeker () para buscar de todos modos y eso no es seguro.

También necesitamos manejar reintentos transparentes, por eso todo esto se vuelve aún más complicado. Un reintento transparente requiere volver a buscar al comienzo del desplazamiento requerido.

Puede volver a buscar virtualmente aunque dentro de un búfer.

Sí, parece que tenemos muchas cosas en su lugar aquí (((: escaló rápidamente a una implementación bastante compleja, potencialmente por una buena razón. Gracias por señalar.

Esto nos lleva a la pregunta: ¿Cuál es el impacto negativo de reducir el tamaño de varias partes, por ejemplo, a 16 MB? 🤗

Esto nos lleva a la pregunta: ¿Cuál es el impacto negativo de reducir el tamaño de varias partes, por ejemplo, a 16 MB?

Realmente no hay impacto, de hecho, tengo un PR para cambiar eso como el valor predeterminado para mc - en los puntos de referencia, veo que 32MiB es el mejor valor posible - pero 16MiB es quizás lo mejor de ambos mundos para el punto de vista de la memoria.

Los usuarios que tienen más margen de maniobra pueden utilizar un búfer más alto si es necesario. Sospecho que la mayoría de sus archivos son menores que este valor en términos del tamaño completo del objeto, ¿o lo está cargando con -1 como longitud del contenido? @bwplotka

Realmente no hay ningún impacto, de hecho, tengo un PR para cambiar eso como el valor predeterminado para mc; en los puntos de referencia, veo que 32MiB es el mejor valor posible, pero 16MiB es quizás lo mejor de ambos mundos para el punto de memoria de vista.

¡Gracias! ¡Actualicemos por defecto entonces si podemos! 🤗

Los usuarios que tienen más margen de maniobra pueden utilizar un búfer más alto si es necesario. Sospecho que la mayoría de sus archivos son menores que este valor en términos del tamaño completo del objeto, ¿o lo está cargando con -1 como longitud del contenido? @bwplotka

Sí, depende de si podemos o no adivinar el tamaño. A veces no podemos, así que usamos -1. La API de GCS es sorprendente porque deduce varias partes o no directamente del lector, sin necesidad de pasar a tamaño completo. No tengo idea de cómo lo hacen 🙃 Magia. Probablemente buscando previamente para comprobarlo.

Pero nuestros archivos pueden tener muchos, a veces alrededor de 50 GB. Entonces la pregunta es, ¿a qué tamaño deberíamos empezar a hacer multiparte ... siempre? 32 MB si tenemos 16 MB de tamaño de pieza? 🤗 Definitivamente podemos experimentar y comparar, eso sería lo mejor

Pero nuestros archivos pueden tener muchos, a veces alrededor de 50 GB. Entonces la pregunta es, ¿a qué tamaño deberíamos empezar a hacer multiparte ... siempre? 32 MB si tenemos 16 MB de tamaño de pieza? Definitivamente podemos experimentar y comparar, eso sería lo mejor

NOTA: debe recordar que, como máximo, puede cargar hasta 10,000 partes en la API de varias partes de S3, por lo que debe establecer el valor de manera que se adapte al tamaño máximo del objeto. Internamente, en minio-go , el valor predeterminado es 128MiB, pero la idea es que debe calcular el tamaño de parte óptimo en función de la longitud del contenido disponible.

Entonces, esencialmente tu mejor parte El tamaño es siempre

partSize := objectSize / 10000

Entonces, cualquiera que cargue un objeto que sea como 128GiB tiene que gastar 128MiB de memoria por carga de varias partes, ya que no hay forma de evitarlo. Este tipo de API de cacofonía es la razón por la que a veces nos encanta la API de GCS, donde se necesita una carga indefinida para cargarla sin muchos requisitos de memoria en el lado del cliente.

Luego, hay otras formas, como puedes escribir tu propio cargador usando https://github.com/minio/minio-go/blob/master/core.go donde tienes control total sobre todos los detalles subyacentes, pero eso pone algo de carga. en su extremo donde puede optimizar completamente el requisito de memoria.

Hice algunos puntos de referencia y, de hecho, puede ser significativo para nuestro caso de uso: https://github.com/thanos-io/thanos/issues/3917#issuecomment -805983470

¿Hay alguna forma de que la lógica de carga acepte algún tipo de lector que bloquee las cosas? ¿O la capacidad de decirle a minio que no usamos varios Uploads a la vez? (Creo que esa es la única carrera que pasa, ¿no?)

NOTA: debe recordar que, como máximo, puede cargar hasta 10,000 partes en la API de varias partes de S3, por lo que debe establecer el valor de manera que se adapte al tamaño máximo del objeto. Internamente, en minio-go, el valor predeterminado es 128MiB, pero la idea es que debe calcular el tamaño de pieza óptimo en función de la longitud del contenido disponible.
Entonces, esencialmente tu mejor parte El tamaño es siempre

¡Gracias! Esto es útil, pero me pregunto si siempre es bueno configurar 10 000 partes. Por ejemplo, para un archivo de 1 MB, parece ineficaz enviar solo partes de 10 kb, ¿no? Dado que esto está bloqueando el lanzamiento de Thanos, estoy considerando revertir la corrección de la carrera, ya que parece que no nos afectará y luego figuraremos una solución a largo plazo): https://github.com/bwplotka/minio-go/commit/f9927e5255a6ade9d3728e2651c6ae24f4367692

Todavía tengo grandes esperanzas de alguna implementación de Reader que bloqueará, por ejemplo, ReadAt . Hará las cosas más lentas, pero hará el trabajo. Será un poco más lento que la llamada de red, ¿no?

¡Gracias! Esto es útil, pero me pregunto si siempre es bueno configurar 10 000 partes. Por ejemplo, para un archivo de 1 MB, parece ineficaz enviar solo partes de 10 kb, ¿no? Dado que esto está bloqueando el lanzamiento de Thanos, estoy considerando revertir la corrección de la carrera, ya que parece que no nos afectará y pensamos en una solución a largo plazo más adelante): bwplotka / minio-go @ f9927e5

El tamaño mínimo por pieza es 5MiB @bwplotka, solo la última parte puede ser <5MiB

¿Hay alguna forma de que la lógica de carga acepte algún tipo de lector que bloquee las cosas? ¿O la capacidad de decirle a minio que no usamos varios Uploads a la vez? (Creo que esa es la única carrera que pasa, ¿no?)

puede pasar un ReadAt () que bloquea las cargas una por una o cambia la concurrencia predeterminada de '4' a '1'

https://pkg.go.dev/github.com/minio/minio-go/v7#PutObjectOptions

opts.NumThreads=1