Tengo un solo archivo de 50 GB en server_A, y lo estoy copiando en server_B. Corro
server_A$ rsync --partial --progress --inplace --append-verify 50GB_file root@server_B:50GB_file
Server_B tiene 32 GB de RAM con 2 GB de intercambio. En su mayoría está inactivo y debería haber tenido mucha RAM libre. Tiene mucho espacio en disco. Aproximadamente a 32 GB, la transferencia se cancela porque el lado remoto cierra la conexión.
Server_B ahora se ha caído de la red. Le pedimos al centro de datos que lo reinicie. Cuando miro el registro del kernel antes de que se bloquee, veo que estaba usando 0 bytes de intercambio, y la lista de procesos estaba usando muy poca memoria (el proceso rsync estaba listado como usando 600 KB de RAM), pero el oom_killer estaba enloqueciendo, y lo último en el registro es donde mata el proceso del lector del núcleo del metalog.
Este es el kernel 3.2.59, 32 bits (de modo que ningún proceso puede asignar más de 4 GB de todos modos).
Es casi como si Linux diera más prioridad al almacenamiento en caché que a los demonios en ejecución de larga duración. ¿¿Lo que da?? ¿Y cómo puedo evitar que vuelva a suceder?
Aquí está la salida del oom_killer:
Sep 23 02:04:16 [kernel] [1772321.850644] clamd invoked oom-killer: gfp_mask=0x84d0, order=0, oom_adj=0, oom_score_adj=0
Sep 23 02:04:16 [kernel] [1772321.850649] Pid: 21832, comm: clamd Tainted: G C 3.2.59 #21
Sep 23 02:04:16 [kernel] [1772321.850651] Call Trace:
Sep 23 02:04:16 [kernel] [1772321.850659] [<c01739ac>] ? dump_header+0x4d/0x160
Sep 23 02:04:16 [kernel] [1772321.850662] [<c0173bf3>] ? oom_kill_process+0x2e/0x20e
Sep 23 02:04:16 [kernel] [1772321.850665] [<c0173ff8>] ? out_of_memory+0x225/0x283
Sep 23 02:04:16 [kernel] [1772321.850668] [<c0176438>] ? __alloc_pages_nodemask+0x446/0x4f4
Sep 23 02:04:16 [kernel] [1772321.850672] [<c0126525>] ? pte_alloc_one+0x14/0x2f
Sep 23 02:04:16 [kernel] [1772321.850675] [<c0185578>] ? __pte_alloc+0x16/0xc0
Sep 23 02:04:16 [kernel] [1772321.850678] [<c0189e74>] ? vma_merge+0x18d/0x1cc
Sep 23 02:04:16 [kernel] [1772321.850681] [<c01856fa>] ? handle_mm_fault+0xd8/0x15d
Sep 23 02:04:16 [kernel] [1772321.850685] [<c012305a>] ? do_page_fault+0x20e/0x361
Sep 23 02:04:16 [kernel] [1772321.850688] [<c018a9c4>] ? sys_mmap_pgoff+0xa2/0xc9
Sep 23 02:04:16 [kernel] [1772321.850690] [<c0122e4c>] ? vmalloc_fault+0x237/0x237
Sep 23 02:04:16 [kernel] [1772321.850694] [<c08ba7e6>] ? error_code+0x5a/0x60
Sep 23 02:04:16 [kernel] [1772321.850697] [<c08b0000>] ? cpuid4_cache_lookup_regs+0x372/0x3b2
Sep 23 02:04:16 [kernel] [1772321.850700] [<c0122e4c>] ? vmalloc_fault+0x237/0x237
Sep 23 02:04:16 [kernel] [1772321.850701] Mem-Info:
Sep 23 02:04:16 [kernel] [1772321.850703] DMA per-cpu:
Sep 23 02:04:16 [kernel] [1772321.850704] CPU 0: hi: 0, btch: 1 usd: 0
Sep 23 02:04:16 [kernel] [1772321.850706] CPU 1: hi: 0, btch: 1 usd: 0
Sep 23 02:04:16 [kernel] [1772321.850707] CPU 2: hi: 0, btch: 1 usd: 0
Sep 23 02:04:16 [kernel] [1772321.850709] CPU 3: hi: 0, btch: 1 usd: 0
Sep 23 02:04:16 [kernel] [1772321.850711] CPU 4: hi: 0, btch: 1 usd: 0
Sep 23 02:04:16 [kernel] [1772321.850713] CPU 5: hi: 0, btch: 1 usd: 0
Sep 23 02:04:16 [kernel] [1772321.850714] CPU 6: hi: 0, btch: 1 usd: 0
Sep 23 02:04:16 [kernel] [1772321.850716] CPU 7: hi: 0, btch: 1 usd: 0
Sep 23 02:04:16 [kernel] [1772321.850718] Normal per-cpu:
Sep 23 02:04:16 [kernel] [1772321.850719] CPU 0: hi: 186, btch: 31 usd: 70
Sep 23 02:04:16 [kernel] [1772321.850721] CPU 1: hi: 186, btch: 31 usd: 116
Sep 23 02:04:16 [kernel] [1772321.850723] CPU 2: hi: 186, btch: 31 usd: 131
Sep 23 02:04:16 [kernel] [1772321.850724] CPU 3: hi: 186, btch: 31 usd: 76
Sep 23 02:04:16 [kernel] [1772321.850726] CPU 4: hi: 186, btch: 31 usd: 29
Sep 23 02:04:16 [kernel] [1772321.850728] CPU 5: hi: 186, btch: 31 usd: 61
Sep 23 02:04:16 [kernel] [1772321.850731] CPU 7: hi: 186, btch: 31 usd: 17
Sep 23 02:04:16 [kernel] [1772321.850733] HighMem per-cpu:
Sep 23 02:04:16 [kernel] [1772321.850734] CPU 0: hi: 186, btch: 31 usd: 2
Sep 23 02:04:16 [kernel] [1772321.850736] CPU 1: hi: 186, btch: 31 usd: 69
Sep 23 02:04:16 [kernel] [1772321.850738] CPU 2: hi: 186, btch: 31 usd: 25
Sep 23 02:04:16 [kernel] [1772321.850739] CPU 3: hi: 186, btch: 31 usd: 27
Sep 23 02:04:16 [kernel] [1772321.850741] CPU 4: hi: 186, btch: 31 usd: 7
Sep 23 02:04:16 [kernel] [1772321.850743] CPU 5: hi: 186, btch: 31 usd: 188
Sep 23 02:04:16 [kernel] [1772321.850744] CPU 6: hi: 186, btch: 31 usd: 25
Sep 23 02:04:16 [kernel] [1772321.850746] CPU 7: hi: 186, btch: 31 usd: 158
Sep 23 02:04:16 [kernel] [1772321.850750] active_anon:117913 inactive_anon:9942 isolated_anon:0
Sep 23 02:04:16 [kernel] [1772321.850751] active_file:106466 inactive_file:7784521 isolated_file:0
Sep 23 02:04:16 [kernel] [1772321.850752] unevictable:40 dirty:0 writeback:61 unstable:0
Sep 23 02:04:16 [kernel] [1772321.850753] free:143494 slab_reclaimable:128312 slab_unreclaimable:4089
Sep 23 02:04:16 [kernel] [1772321.850754] mapped:6706 shmem:308 pagetables:915 bounce:0
Sep 23 02:04:16 [kernel] [1772321.850759] DMA free:3624kB min:140kB low:172kB high:208kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolate
d(file):0kB present:15808kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:240kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tm
p:0kB pages_scanned:0 all_unreclaimable? yes
Sep 23 02:04:16 [kernel] [1772321.850763] lowmem_reserve[]: 0 869 32487 32487
Sep 23 02:04:16 [kernel] [1772321.850770] Normal free:8056kB min:8048kB low:10060kB high:12072kB active_anon:0kB inactive_anon:0kB active_file:248kB inactive_file:388kB unevictable:0kB isolated(anon)
:0kB isolated(file):0kB present:890008kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:513008kB slab_unreclaimable:16356kB kernel_stack:1888kB pagetables:3660kB unstable:0
kB bounce:0kB writeback_tmp:0kB pages_scanned:1015 all_unreclaimable? yes
Sep 23 02:04:16 [kernel] [1772321.850774] lowmem_reserve[]: 0 0 252949 252949
Sep 23 02:04:16 [kernel] [1772321.850785] lowmem_reserve[]: 0 0 0 0
Sep 23 02:04:16 [kernel] [1772321.850788] DMA: 0*4kB 7*8kB 3*16kB 6*32kB 4*64kB 6*128kB 5*256kB 2*512kB 0*1024kB 0*2048kB 0*4096kB = 3624kB
Sep 23 02:04:16 [kernel] [1772321.850795] Normal: 830*4kB 80*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 8056kB
Sep 23 02:04:16 [kernel] [1772321.850802] HighMem: 13*4kB 14*8kB 2*16kB 2*32kB 0*64kB 0*128kB 2*256kB 2*512kB 3*1024kB 0*2048kB 136*4096kB = 561924kB
Sep 23 02:04:16 [kernel] [1772321.850809] 7891360 total pagecache pages
Sep 23 02:04:16 [kernel] [1772321.850811] 0 pages in swap cache
Sep 23 02:04:16 [kernel] [1772321.850812] Swap cache stats: add 0, delete 0, find 0/0
Sep 23 02:04:16 [kernel] [1772321.850814] Free swap = 1959892kB
Sep 23 02:04:16 [kernel] [1772321.850815] Total swap = 1959892kB
Sep 23 02:04:16 [kernel] [1772321.949081] 8650736 pages RAM
Sep 23 02:04:16 [kernel] [1772321.949084] 8422402 pages HighMem
Sep 23 02:04:16 [kernel] [1772321.949085] 349626 pages reserved
Sep 23 02:04:16 [kernel] [1772321.949086] 7885006 pages shared
Sep 23 02:04:16 [kernel] [1772321.949087] 316864 pages non-shared
Sep 23 02:04:16 [kernel] [1772321.949089] [ pid ] uid tgid total_vm rss cpu oom_adj oom_score_adj name
(rest of process list omitted)
Sep 23 02:04:16 [kernel] [1772321.949656] [14579] 0 14579 579 171 5 0 0 rsync
Sep 23 02:04:16 [kernel] [1772321.949662] [14580] 0 14580 677 215 5 0 0 rsync
Sep 23 02:04:16 [kernel] [1772321.949669] [21832] 113 21832 42469 37403 0 0 0 clamd
Sep 23 02:04:16 [kernel] [1772321.949674] Out of memory: Kill process 21832 (clamd) score 4 or sacrifice child
Sep 23 02:04:16 [kernel] [1772321.949679] Killed process 21832 (clamd) total-vm:169876kB, anon-rss:146900kB, file-rss:2712kB
Aquí está la salida 'superior' después de repetir mi comando rsync como usuario no root:
top - 03:05:55 up 8:43, 2 users, load average: 0.04, 0.08, 0.09
Tasks: 224 total, 1 running, 223 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0% us, 0.0% sy, 0.0% ni, 99.9% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 33204440k total, 32688600k used, 515840k free, 108124k buffers
Swap: 1959892k total, 0k used, 1959892k free, 31648080k cached
Aquí están los parámetros de sysctl vm:
# sysctl -a | grep '^vm'
vm.overcommit_memory = 0
vm.panic_on_oom = 0
vm.oom_kill_allocating_task = 0
vm.oom_dump_tasks = 1
vm.overcommit_ratio = 50
vm.page-cluster = 3
vm.dirty_background_ratio = 1
vm.dirty_background_bytes = 0
vm.dirty_ratio = 0
vm.dirty_bytes = 15728640
vm.dirty_writeback_centisecs = 500
vm.dirty_expire_centisecs = 3000
vm.nr_pdflush_threads = 0
vm.swappiness = 60
vm.lowmem_reserve_ratio = 256 32 32
vm.drop_caches = 0
vm.min_free_kbytes = 8192
vm.percpu_pagelist_fraction = 0
vm.max_map_count = 65530
vm.laptop_mode = 0
vm.block_dump = 0
vm.vfs_cache_pressure = 100
vm.legacy_va_layout = 0
vm.stat_interval = 1
vm.mmap_min_addr = 4096
vm.vdso_enabled = 2
vm.highmem_is_dirtyable = 0
vm.scan_unevictable_pages = 0
rsync
oom
oom-killer
sin datos
fuente
fuente
Respuestas:
Así que leamos la salida de Oom-Killer y veamos qué se puede aprender de allí.
Al analizar los registros asesinos de OOM, es importante observar qué lo desencadenó. La primera línea de su registro nos da algunas pistas:
order=0nos dice cuánta memoria se solicita. La administración de memoria del núcleo solo puede administrar números de página en potencias de 2, por lo que clamd ha solicitado 2 0 páginas de memoria o 4KB.Los dos bits más bajos de GFP_MASK (obtener la máscara de página libre) constituyen la llamada máscara de zona que le dice al asignador de qué zona obtener la memoria :
Zonas de memoria es un concepto creado principalmente por razones de compatibilidad. En una vista simplificada, hay tres zonas para un Kernel x86:
En su caso, la máscara de zona es 0, lo que significa que clamd solicita memoria
ZONE_NORMAL.Las otras banderas están resolviendo
de acuerdo con la documentación de Linux MM , por lo que su petición de éstos tiene las banderas de
GFP_ZERO,GFP_REPEAT,GFP_FS,GFP_IOyGFP_WAIT, siendo por lo tanto no es particularmente exigente.Entonces, ¿qué pasa con
ZONE_NORMAL? Algunas estadísticas genéricas se pueden encontrar más adelante en la salida de OOM:Notable aquí es que
freees solo 8K desdeminy muy por debajolow. Esto significa que el administrador de memoria de su host está algo angustiado y kswapd ya debería estar intercambiando páginas, ya que está en la fase amarilla del gráfico a continuación:Aquí se proporciona más información sobre la fragmentación de la memoria de la zona:
básicamente afirmando que tiene una sola página contigua de 4MB con el resto muy fragmentado en páginas principalmente de 4KB.
Entonces recapitulemos:
clamd) que obtiene memoria,ZONE_NORMALmientras que la asignación de memoria no privilegiada generalmente se realizaría desdeZONE_HIMEMZONE_NORMALkswapdlas reglas, debería haber visto alguna actividad de paginación de antemano, pero no se está intercambiando nada, incluso bajo presión de memoriaZONE_NORMAL, sin causa aparenteoom-killerse ha invocadoTodo esto parece bastante extraño, pero al menos está relacionado con lo que se describe en la sección 2.5 del excelente libro de John O'Gorman "Comprender el administrador de memoria virtual de Linux" :
(el énfasis es mío)
Dado que 3.2 tiene numerosos avances en la administración de memoria sobre 2.6, esta no es una respuesta definitiva, sino una pista realmente fuerte que buscaría primero. Reduzca la memoria utilizable del host a 16G como máximo utilizando el
mem=parámetro del núcleo o extrayendo la mitad de los DIMM del servidor.En última instancia, use un kernel de 64 bits .
Amigo, es 2015.
fuente
Unas pocas cosas ...
Mi regla general para el espacio de intercambio ha sido tener al menos 2 veces la cantidad de ram físico. Esto permite al demonio de página / intercambio la capacidad de reorganizar la memoria de manera eficiente.
Server_B tiene 32 GB de RAM, así que intente configurarlo para 64 GB de intercambio. OMI, los 2 GB de espacio de intercambio es el servidor dispone de manera demasiado baja, especialmente para un servidor.
Si no tiene una partición adicional que pueda convertir en una partición de intercambio, puede probar esto creando un archivo y montándolo como una partición de intercambio [será lento]. Ver https://www.maketecheasier.com/swap-partitions-on-linux/
Dado que server_B tiene mucho espacio en disco, --inplace no es necesario, y puede no ser deseado, ya que puede ser lo que está causando que rsync use 32GB. --inplace solo es realmente útil si le falta espacio en el sistema de archivos [que no tiene] o si tiene algún requisito especial de rendimiento.
Supongo que rsync querrá usar 50 GB de RAM [el tamaño del archivo] con sus opciones actuales. Normalmente, rsync no necesita tanta memoria para hacer su trabajo, por lo que una o más de sus opciones pueden ser el problema. Rutinariamente transfiero archivos de 200GB sin ningún problema.
Realice algunas pruebas sin usar opciones. Haga esto con archivos más pequeños, digamos 10GB; esto debería evitar el pánico del kernel, pero aún así permitirle monitorear el comportamiento que está causando el problema. Monitoree el uso de memoria de rsync.
Gradualmente, agregue las opciones, una a la vez, para ver qué opción [o combinación de opciones] hace que rsync comience a expandirse en la RAM (por ejemplo, mientras se realiza la transferencia, el uso de ram de rsync crece proporcionalmente a la cantidad de datos de archivo transferidos, etc.)
Si realmente necesita las opciones que hacen que rsync conserve algo de imagen de archivo ram, necesitará el espacio de intercambio adicional y su tamaño máximo de archivo se limitará en consecuencia.
Algunas cosas más [ACTUALIZADO]:
(1) El seguimiento de la pila del kernel muestra que rsync estaba fallando en la página en un área de mmap. Probablemente esté mapeando el archivo. mmap no ofrece ninguna garantía de que se vaciará en el disco hasta que se cierre el archivo [a diferencia de lectura / escritura] que va al caché de bloques FS de inmediato [donde se vaciará]
(2) El bloqueo / pánico del kernel se produce cuando el tamaño de la transferencia alcanza el tamaño de la RAM. Claramente, rsync está aprovechando esa cantidad de memoria no fscache a través de malloc o mmap. Una vez más, con las opciones que ha especificado, rsync asignará 50 GB de memoria para transferir un archivo de 50 GB.
(3) Transfiera un archivo de 24GB. Eso probablemente funcionará. Luego, inicie el kernel con mem = 16G y vuelva a hacer la prueba del archivo de 24GB. Estallará a 16 GB en lugar de 32 GB. Esto confirmará que rsync realmente necesita la memoria.
(4) Antes de decir que agregar swap es ridículo, intente agregar algunos [a través del método swap-to-file]. Esto es mucho más fácil de hacer y probar que todos los argumentos académicos sobre cómo no se requiere el intercambio. Incluso si no es la solución, puede aprender algo de ella. Apuesto a que la prueba mem = 16G tendrá éxito sin pánico / bloqueo.
(5) Lo más probable es que rsync esté golpeando el intercambio, pero sucede demasiado rápido para ver con la parte superior antes de que OOM entre en acción y mate a rsync. Para cuando rsync llega a 32 GB, otros procesos ya se han visto obligados a intercambiar, especialmente si están inactivos. Quizás, una combinación de "gratis" y "top" le dará una mejor imagen.
(6) Después de que rsync es asesinado, lleva tiempo descargar mmap en el FS. No es lo suficientemente rápido para OOM y comienza a matar otras cosas [algunas obviamente son de misión crítica]. Es decir, mlush flush y OOM están compitiendo. O, OOM tiene un error. De lo contrario, no habría un accidente.
(7) En mi experiencia, una vez que un sistema "golpea la pared de la memoria", Linux tarda mucho en recuperarse por completo. Y, a veces, nunca se recupera correctamente y la única forma de borrarlo es reiniciando. Por ejemplo, tengo 12 GB de RAM. Cuando ejecuto un trabajo que usa 40 GB de memoria [tengo 120 GB de intercambio para acomodar trabajos grandes] y luego lo mato, el sistema tarda unos 10 minutos en volver a la capacidad de respuesta normal [con la luz del disco encendida todo el tiempo] .
(8) Ejecute rsync sin opciones. Esto funcionará Obtenga un ejemplo de referencia para trabajar. Luego agregue de nuevo - en el lugar y vuelva a probar. Luego haga --append-verificar en su lugar. Entonces, prueba ambos. Descubra qué opción obtiene rsync haciendo el enorme mmap. Luego decida si puede vivir sin él. Si --inplace es el culpable, es obvio, ya que tienes mucho espacio en disco. Si debe tener la opción, deberá obtener el espacio de intercambio para acomodar el malloc / mmap que hará rsync.
SEGUNDA ACTUALIZACIÓN:
Haga las pruebas de archivos mem = y más pequeños de lo anterior.
Las preguntas centrales: ¿por qué OOM mata a rsync? ¿Quién / Qué está masticando la memoria?
Leí [pero olvidé] que el sistema tiene 32 bits. Entonces, estoy de acuerdo, rsync puede no ser directamente responsable (a través de malloc / mmap - glibc implementa mallocs grandes a través de mapas anónimos / privados), y la falla de la página mmap de rsync solo dispara OOM por coincidencia. Luego, OOM calcula la memoria total consumida por rsync directa e indirectamente [caché FS, buffers de socket, etc.] y decide que es el candidato principal. Por lo tanto, monitorear el uso de memoria total puede ser útil. Sospecho que se arrastra al mismo ritmo que la transferencia de archivos. Obviamente, no debería.
Algunas cosas que puede monitorear en / proc o / proc / rsync_pid a través de un script perl o python en un bucle rápido [un script bash probablemente no será lo suficientemente rápido para el evento del fin del mundo] que puede monitorear todo los siguientes varios cientos de veces / seg. Puede ejecutar esto con una prioridad más alta que rsync para que se mantenga en RAM y se ejecute para que pueda monitorear las cosas justo antes del bloqueo y, con suerte, durante OOM para que pueda ver por qué OOM se vuelve loco:
/ proc / meminfo: para obtener más grano fino en el uso de intercambio en el "punto de impacto". En realidad, obtener el número final de la cantidad total de RAM que se está utilizando puede ser más útil. Si bien top proporciona esto, puede que no sea lo suficientemente rápido como para mostrar el estado del universo justo antes del "big bang" (por ejemplo, los últimos 10 milisegundos)
/ proc / rsync_pid / directorio fd. Leer los enlaces simbólicos le permitirá identificar qué fd se abre en el archivo de destino (por ejemplo, el enlace de lectura de / proc / rsync_pid / fd / 5 -> target_file). Esto probablemente solo debe hacerse una vez para obtener el número fd [debe permanecer fijo]
Conociendo el número fd, mira / proc / rsync_pid / fdinfo / fd. Es un archivo de texto que se parece a:
Monitorear el valor "pos" puede ser útil ya que la "última posición del archivo" puede ser útil. Si realiza varias pruebas con diferentes tamaños y opciones mem =, ¿la última posición del archivo rastrea alguno de estos [y cómo]? El sospechoso habitual: posición del archivo == RAM disponible
Pero, la forma más simple es comenzar con "rsync local_file server: remote_file" y verificar que funciona. Puede obtener resultados similares [pero más rápidos] haciendo "ssh server rsync file_a file_b" [primero necesitaría crear un archivo de 50GB_a]. Una manera simple de crear file_a es scp local_system: original_file server: file_a y esto puede ser interesante en sí mismo (por ejemplo, ¿funciona esto cuando se bloquea el rsync? Si scp funciona, pero rsync falla, esto apunta a rsync. Si scp falla, esto apunta a algo más como el controlador NIC). Hacer el ssh rsync también elimina la NIC de la ecuación, lo que puede ser útil. Si eso manguea el sistema, entonces algo está realmente mal. Si tiene éxito, [como he mencionado], comience a agregar las opciones una por una.
Odio desmentir el punto, pero agregar algo de intercambio a través de intercambio a archivo puede cambiar / retrasar el comportamiento del bloqueo y puede ser útil como herramienta de diagnóstico. Si agregar, digamos 16 GB, de intercambio retrasa el bloqueo [medido por el uso de memoria o la posición del archivo de destino] de 32 GB a 46 GB, entonces eso dirá algo.
Puede que no sea un proceso en particular, sino un controlador de kernel errante que está masticando memoria. El vmalloc interno del núcleo asigna cosas y puede intercambiarse. IIRC, no está sujeto a la direccionamiento en todas las circunstancias.
Claramente, la OOM se está confundiendo / entrando en pánico. Es decir, mata a rsync, pero no ve la memoria liberada de manera oportuna y busca a otras víctimas. Algunos de ellos son probablemente críticos para la operación del sistema.
Dejando a un lado malloc / mmap, esto podría ser causado por un caché FS sin vaciar que lleva mucho tiempo (por ejemplo, con 30 GB de datos no vaciados, suponiendo una velocidad de disco de 300 MB / seg, puede tomar 100 segundos vaciarlo). Incluso a ese ritmo, OOM puede ser demasiado impaciente. O, OOM que mata a rsync no inicia el lavado de FS lo suficientemente rápido [o en absoluto]. O la descarga FS ocurre lo suficientemente rápido, pero tiene una versión "perezosa" de las páginas de regreso al grupo libre. Hay algunas opciones / proc que puede configurar para controlar el comportamiento de la caché FS [No recuerdo cuáles son].
Intente arrancar con mem = 4G o algún otro número pequeño. Esto podría reducir el caché de FS y acortar el tiempo de descarga para evitar que OOM busque otras cosas que matar (por ejemplo, el tiempo de descarga se reduce de 100 segundos a <1 segundo). También puede desenmascarar un error OOM que no puede manejar ram física> 4GB en un sistema de 32 bits o algo así.
Además, un punto importante: ejecutar como no root. Nunca se espera que los usuarios raíz mastiquen recursos, por lo que se les otorgan límites más permisivos (por ejemplo, el 99% de la memoria frente al 95% para usuarios no root). Esto puede explicar por qué OOM está en tal estado. Además, esto le da a OOM et. Alabama. más espacio para hacer su trabajo de reclamar memoria.
fuente
clamd? Parece que está utilizando ClamAV y tiene habilitado el escaneo en acceso donde el motor antivirus intenta escanear archivos abiertos en busca de virus, cargando en la memoria, todo el contenido de cada archivo abierto por cualquier otro proceso .
Dependiendo de su postura de seguridad y la necesidad de esta transferencia, debe evaluar deshabilitar el escaneo de acceso ClamAV mientras realiza la transferencia.
fuente