web-dev-qa-db-fra.com

Rsync a déclenché le tueur de MOO Linux sur un seul fichier de 50 Go

J'ai un seul fichier de 50 Go sur server_A et je le copie sur server_B. je cours

server_A$ rsync --partial --progress --inplace --append-verify 50GB_file root@server_B:50GB_file

Server_B a 32 Go de RAM avec 2 Go de swap. Il est principalement inactif et aurait dû avoir beaucoup de RAM libre. Il a beaucoup d'espace disque. À environ 32 Go, le transfert s'interrompt car le le côté éloigné a fermé la connexion.

Server_B a maintenant abandonné le réseau. Nous demandons au centre de données de le redémarrer. Quand je regarde le journal du noyau avant qu'il ne plante, je vois qu'il utilisait 0 octet de swap, et la liste des processus utilisait très peu de mémoire (le processus rsync était répertorié comme utilisant 600 Ko de RAM), mais le oom_killer était se déchaîne, et la dernière chose dans le journal est où il tue le processus de lecture du noyau de Metalog.

Il s'agit du noyau 3.2.59, 32 bits (donc aucun processus ne peut mapper plus de 4 Go de toute façon).

C'est presque comme si Linux accordait plus de priorité à la mise en cache qu'aux démons en cours d'exécution de longue durée. Ce qui donne?? Et comment puis-je empêcher que cela se reproduise?

Voici la sortie de l'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

Voici la sortie 'top' après avoir répété ma commande rsync en tant qu'utilisateur non 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

Voici les paramètres 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
rsyncoomoom-killer
67
dataless

Alors lisons la sortie oom-killer et voyons ce qui peut être appris de là.

Lors de l'analyse des journaux de tueur OOM, il est important de regarder ce qui l'a déclenché. La première ligne de votre journal nous donne quelques indices:

[noyau] [1772321.850644] clamd a appelé oom-killer: gfp_mask = 0x84d0, order = 0

order=0 nous indique la quantité de mémoire demandée. La gestion de la mémoire du noyau ne peut gérer que les numéros de page avec des puissances de 2, donc clamd en a demandé 2 pages de mémoire ou 4 Ko.

Les deux bits les plus bas de GFP_MASK (obtenir un masque de page gratuit) constituent ce qu'on appelle masque de zoneindiquant à l'allocateur de quelle zone obtenir la mémoire :

Flag            value      Description
                0x00u      0 implicitly means allocate from ZONE_NORMAL
__GFP_DMA       0x01u      Allocate from ZONE_DMA if possible
__GFP_HIGHMEM   0x02u      Allocate from ZONE_HIGHMEM if possible

Zones mémoire est un concept créé principalement pour des raisons de compatibilité. Dans une vue simplifiée, il existe trois zones pour un noyau x86:

Memory range   Zone       Purpose 

0-16 MB        DMA        Hardware compatibility (devices)
16 - 896 MB    NORMAL     space directly addressable by the Kernel, userland 
> 896 MB       HIGHMEM    userland, space addressable by the Kernel via kmap() calls

Dans votre cas, le masque de zone est 0, ce qui signifie que clamd demande de la mémoire à ZONE_NORMAL.

Les autres indicateurs se résolvent à

/*
 * Action modifiers - doesn't change the zoning
 *
 * __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt
 * _might_ fail.  This depends upon the particular VM implementation.
 *
 * __GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller
 * cannot handle allocation failures.
 *
 * __GFP_NORETRY: The VM implementation must not retry indefinitely.
 */
#define __GFP_WAIT      0x10u   /* Can wait and reschedule? */
#define __GFP_HIGH      0x20u   /* Should access emergency pools? */
#define __GFP_IO        0x40u   /* Can start physical IO? */
#define __GFP_FS        0x80u   /* Can call down to low-level FS? */
#define __GFP_COLD      0x100u  /* Cache-cold page required */
#define __GFP_NOWARN    0x200u  /* Suppress page allocation failure warning */
#define __GFP_REPEAT    0x400u  /* Retry the allocation.  Might fail */
#define __GFP_NOFAIL    0x800u  /* Retry for ever.  Cannot fail */
#define __GFP_NORETRY   0x1000u /* Do not retry.  Might fail */
#define __GFP_NO_GROW   0x2000u /* Slab internal usage */
#define __GFP_COMP      0x4000u /* Add compound page metadata */
#define __GFP_ZERO      0x8000u /* Return zeroed page on success */
#define __GFP_NOMEMALLOC 0x10000u /* Don't use emergency reserves */
#define __GFP_NORECLAIM  0x20000u /* No realy zone reclaim during allocation */

selon la documentation Linux MM , donc votre requst a les drapeaux pour GFP_ZERO, GFP_REPEAT, GFP_FS, GFP_IO et GFP_WAIT, donc pas particulièrement pointilleux.

Alors quoi de neuf avec ZONE_NORMAL? Certaines statistiques génériques peuvent être trouvées plus loin dans la sortie OOM:

[noyau] [1772321.850770] Normal gratuit: 8056kB min: 8048kB bas: 10060kB haut: 12072kB active_anon: 0kB inactive_anon : 0 Ko fichier_actif: 248 Ko fichier inactif: 388 Ko non prévisible: 0 Ko isolé (anon): 0 Ko isolé (fichier): 0 Ko présent: 890008 Ko

On remarque ici que free est à seulement 8K de min et bien en dessous low. Cela signifie que le gestionnaire de mémoire de votre hôte est quelque peu en détresse et que kswapd devrait déjà échanger des pages comme dans la phase jaune du graphique ci-dessous: Linux memory manager graph

Quelques informations supplémentaires sur la fragmentation de la mémoire de la zone sont fournies ici:

[noyau] [1772321.850795] Normal: 830 * 4 Ko 80 * 8 Ko 0 * 16 Ko 0 * 32 Ko 0 * 64 Ko 0 * 128 Ko 0 * 256 Ko 0 * 512 Ko 0 * 1024 Ko 0 * 2048 Ko 1 * 4096 Ko = 8056 Ko

indiquant essentiellement que vous avez une seule page contiguë de 4 Mo, le reste étant fortement fragmenté en pages principalement de 4 Ko.

Récapitulons donc:

  • vous disposez d'un processus utilisateur (clamd) récupérant la mémoire de ZONE_NORMAL alors que l'allocation de mémoire non privilégiée serait généralement effectuée à partir de ZONE_HIMEM
  • à ce stade, le gestionnaire de mémoire aurait dû être en mesure de diffuser la page 4K demandée, même si vous semblez avoir une pression mémoire importante dans ZONE_NORMAL
  • le système, selon les règles de kswapd, devrait a déjà vu une activité de pagination, mais rien n'est échangé, même sous la pression de la mémoire dans ZONE_NORMAL, sans cause apparente
  • Rien de ce qui précède ne donne une raison précise pour laquelle oom-killer a été invoqué

Tout cela semble plutôt étrange, mais doit au moins être lié à ce qui est décrit dans section 2.5 de l'excellent livre de John O'Gorman "Comprendre le gestionnaire de mémoire virtuelle Linux" :

Comme l'espace d'adresses utilisable par le noyau (ZONE_NORMAL) est de taille limitée, le noyau prend en charge le concept de mémoire élevée. [...] Pour accéder à la mémoire comprise entre 1 Go et 4 Go, le noyau mappe temporairement les pages de la mémoire haute vers ZONE_NORMAL avec kmap (). [...]

Cela signifie que pour décrire 1 Go de mémoire, environ 11 Mo de mémoire noyau sont nécessaires. Ainsi, avec 16 Go, 176 Mo de mémoire sont consommés, ce qui exerce une pression importante sur ZONE_NORMAL. Cela ne sonne pas trop mal jusqu'à ce que d'autres structures soient prises en compte qui utilisent ZONE_NORMAL. Même les très petites structures telles que les entrées de table de page (PTE) nécessitent environ 16 Mo dans le pire des cas. Cela fait 16 Go sur la limite pratique de la mémoire physique disponible Linux sur un x86.

(c'est moi qui souligne)

Étant donné que 3.2 a de nombreux progrès dans la gestion de la mémoire par rapport à 2.6, ce n'est pas une réponse définitive, mais un indice vraiment fort que je voudrais d'abord. Réduisez la mémoire utilisable de l'hôte à 16 Go au maximum en utilisant le mem= paramètre du noyau ou en extrayant la moitié des barrettes DIMM du serveur.

En fin de compte, utilisez un noyau 64 bits.

Mec, c'est 2015.

179
the-wabbit

Quelques choses ...

Ma règle générale pour l'espace d'échange a été d'avoir au moins 2x la quantité de RAM physique. Cela permet au démon page/swap de réorganiser efficacement la mémoire.

Server_B a 32 Go de RAM, alors essayez de le configurer pour 64 Go de swap. OMI, les 2 Go d'espace de swap dont dispose votre serveur sont trop bas , surtout pour un serveur.

Si vous ne disposez pas d'une partition supplémentaire que vous pouvez transformer en partition de swap, vous pouvez la tester en créant un fichier et en le montant en tant que partition de swap [ce sera lent]. Voir https://www.maketecheasier.com/swap-partitions-on-linux/

Puisque server_B a beaucoup d'espace disque, --inplace n'est pas nécessaire et peut être indésirable car cela peut être à l'origine de l'utilisation de 32 Go par rsync. --inplace n'est vraiment utile que si vous manquez d'espace sur le système de fichiers [ce que vous n'êtes pas] ou si vous avez des exigences de performances spéciales.

Je suppose que rsync voudra utiliser 50 Go de RAM [la taille du fichier] avec vos options actuelles. Normalement, rsync n'a pas besoin de beaucoup de mémoire pour faire son travail, donc une ou plusieurs de vos options peuvent être le problème. Je transfère régulièrement des fichiers de 200 Go sans problème.

Faites des tests sans utiliser d'options. Faites-le avec des fichiers plus petits, disons 10 Go - cela devrait éviter la panique du noyau, mais vous permet tout de même de surveiller le comportement à l'origine du problème. Surveillez l'utilisation de la mémoire de rsync.

Progressivement, ajoutez des options, une à la fois, pour voir quelle option [ou combinaison d'options] provoque le démarrage de rsync sur RAM (par exemple, pendant le transfert, l'utilisation du ram de rsync augmente) proportionnellement au volume de données transférées, etc.).

Si vous avez vraiment besoin des options qui permettent à rsync de conserver une image de fichier dans la mémoire RAM, vous aurez besoin de l'espace de swap supplémentaire et votre taille de fichier maximale sera limitée en conséquence.

Encore quelques choses [MISE À JOUR]:

(1) La trace de la pile du noyau montre que rsync était en défaut de page sur une zone mmap. Il est probablement en train de mapper le fichier. mmap n'offre aucune garantie qu'il videra le disque jusqu'à ce que le fichier soit fermé [contrairement à la lecture/écriture] qui va dans le FS bloquer le cache immédiatement [où il sera vidé]

(2) Le crash/panique du noyau se produit lorsque la taille du transfert atteint la taille de la RAM. Il est clair que rsync saisit autant de mémoire non fscache via malloc ou mmap. Encore une fois, avec les options que vous avez spécifiées, rsync allouera 50 Go de mémoire pour transférer un fichier de 50 Go.

(3) Transférez un fichier de 24 Go. Cela fonctionnera probablement. Ensuite, démarrez le noyau avec mem = 16G et refaites le test de fichier de 24 Go. Il soufflera à 16 Go plutôt qu'à 32 Go. Cela confirmera que rsync a vraiment besoin de la mémoire.

(4) Avant de dire que l'ajout de swap est ridicule, essayez d'en ajouter [via la méthode swap-to-file]. C'est beaucoup plus facile à faire et à tester que tous les arguments académiques sur la façon dont l'échange n'est pas nécessaire. Même si ce n'est pas la solution, vous pouvez en tirer des leçons. Je parie que le test mem = 16G réussira sans panique/crash.

(5) Il y a de fortes chances que rsync frappe swap, mais cela arrive trop vite pour voir avec top avant que le MOO intervienne et tue rsync. Au moment où rsync atteint 32 Go, d'autres processus ont déjà été contraints de s'échanger, en particulier s'ils sont inactifs. Peut-être qu'une combinaison de "gratuit" et de "top" vous donnera une meilleure image.

(6) Une fois que rsync a été tué, il faut du temps pour vider mmap sur le FS. Pas assez rapide pour MOO et cela commence à tuer d'autres choses [certaines sont évidemment essentielles à la mission]. Autrement dit, la chasse d'eau mmap et OOM sont en course. Ou, OOM a un bug. Sinon, il n'y aurait pas de plantage.

(7) D'après mon expérience, une fois qu'un système "atteint le mur de mémoire", Linux met beaucoup de temps à récupérer complètement. Et, parfois, il ne se rétablit jamais vraiment correctement et la seule façon de l'effacer est un redémarrage. Par exemple, j'ai 12 Go de RAM. Lorsque j'exécute un travail qui utilise 40 Go de mémoire [j'ai 120 Go de swap pour héberger des travaux volumineux], puis que je le tue, il faut environ 10 minutes au système pour revenir à une réactivité normale [avec le voyant du disque allumé en permanence] .

(8) Exécutez rsync sans les options . Cela fonctionnera. Obtenez un exemple de référence sur lequel travailler. Puis ajoutez à nouveau - en place et retestez. Faites ensuite --append-verify à la place. Ensuite, essayez les deux. Découvrez quelle option obtient rsync en faisant l'énorme mmap. Décidez ensuite si vous pouvez vous en passer. Si --inplace est le coupable, c'est une évidence, car vous avez beaucoup d'espace disque. Si vous devez avoir l'option, vous devrez obtenir l'espace de swap pour accueillir le malloc/mmap que rsync fera.

DEUXIÈME MISE À JOUR:

Veuillez effectuer les tests de fichiers mem = et plus petits ci-dessus.

Les questions centrales: pourquoi rsync est-il tué par OOM? Qui/Qu'est-ce que la mémoire à mâcher?

J'ai lu [mais j'ai oublié] que le système est 32 bits. Donc, je suis d'accord, rsync peut ne pas être directement responsable (via malloc/mmap - glibc implémente de grands mallocs via des mmaps anonymes/privés), et la défaillance de la page mmap de rsync déclenche juste OOM par coïncidence. Ensuite, OOM calcule la mémoire totale consommée par rsync directement et indirectement [cache FS, tampons de socket, etc.] et décide qu'il s'agit du candidat principal. La surveillance de l'utilisation totale de la mémoire peut donc être utile. Je soupçonne qu'il grimpe au même rythme que le transfert de fichiers. De toute évidence, cela ne devrait pas.

Certaines choses que vous pouvez surveiller dans/proc ou/proc/rsync_pid via un script Perl ou python dans une boucle rapide [un script bash ne sera probablement pas assez rapide pour la fin de la -world event] qui peut surveiller toutes les centaines de fois/s suivantes. Vous pouvez l'exécuter avec une priorité plus élevée que rsync afin qu'il se maintienne dans RAM et fonctionne pour vous permettre de surveiller les choses juste avant le crash et, espérons-le, pendant OOM afin que vous puissiez voir pourquoi OOM devient fou:

/ proc/meminfo - pour obtenir plus de détails sur l'utilisation du swap au "point d'impact". En fait, obtenir le nombre final sur combien RAM est utilisé au total peut être plus utile. Bien que top le fournisse, il peut ne pas être assez rapide pour montrer l'état de l'univers juste avant la "big bang" (par exemple les 10 dernières millisecondes)

/ proc/rsync_pid/fd. La lecture des liens symboliques vous permettra d'identifier le fd ouvert sur le fichier cible (par exemple, le lien de lecture de/proc/rsync_pid/fd/5 -> target_file). Cela ne doit probablement être fait qu'une seule fois pour obtenir le numéro fd [il doit rester fixe]

Connaissant le numéro fd, regardez/proc/rsync_pid/fdinfo/fd. C'est un fichier texte qui ressemble à:

 pos: <file_position> 
 drapeaux: blah_blah 
 mnt_id: blah_blah

La surveillance de la valeur "pos" peut être utile car la "dernière position du fichier" peut être utile. Si vous effectuez plusieurs tests avec différentes tailles et options mem =, la dernière position du fichier suit-elle l'une de ces [et comment]? Le suspect habituel: position du fichier == RAM disponible

Mais, la manière la plus simple est de commencer par "rsync local_file server: remote_file" et de vérifier que cela fonctionne. Vous pouvez obtenir des résultats similaires [mais plus rapides] en exécutant "ssh server rsync file_a file_b" [vous devez d'abord créer un fichier_a de 50 Go]. Un moyen simple de créer file_a est scp local_system: original_file server: file_a et cela pourrait être intéressant pour lui-même (par exemple, cela fonctionne-t-il lorsque rsync se bloque? Si scp fonctionne, mais rsync échoue, cela pointe vers rsync. Si scp échoue, cela indique à quelque chose d'autre comme le pilote NIC). Faire le rshync ssh prend également le NIC hors de l'équation, ce qui peut être utile. Si cela arrose le système , alors quelque chose ne va vraiment pas. Si cela réussit, [comme je l'ai mentionné] commencez à ajouter les options une par une.

Je déteste développer ce point, mais l'ajout de swap via swap-to-file peut changer/retarder le comportement de crash et peut être utile comme outil de diagnostic. Si l'ajout, disons 16 Go, de swap retarde le crash [tel que mesuré par l'utilisation de la mémoire ou la position du fichier cible] de 32 Go à 46 Go, alors cela dira quelque chose.

Ce n'est peut-être pas un processus particulier, mais un pilote de noyau errant qui mâche de la mémoire. Le vmalloc interne du noyau alloue des trucs et il peut être échangé. IIRC, il n'est pas lié par l'adressibilité en toutes circonstances.

De toute évidence, le MOO devient confus/paniqué. Autrement dit, il tue rsync, mais ne voit pas la mémoire libérée en temps opportun et part à la recherche d'autres victimes. Certains d'entre eux sont probablement essentiels au fonctionnement du système.

malloc/mmap mis à part, cela pourrait être causé par un cache non vidangé FS qui prend beaucoup de temps (par exemple avec 30 Go de données non vidées, en supposant un débit de disque de 300 Mo/s, cela peut prendre 100 secondes). Même à ce rythme, OOM peut être trop impatient. Ou, OOM tuant rsync ne démarre pas le FS vidage assez rapide [ou pas du tout]. Ou FS flush se produit assez rapidement, mais il contient une version "paresseuse" des pages vers le pool gratuit. Il existe des options/proc que vous pouvez définir pour contrôler FS cache comportement [je ne me souviens pas ce qu'ils sont].

Essayez de démarrer avec mem = 4G ou un autre petit nombre. Cela pourrait réduire le FS cache et raccourcir son temps de vidage pour empêcher OOM de chercher d'autres choses à tuer (par exemple, le temps de vidage est réduit de 100 s à <1 s). Il pourrait également démasquer un bogue OOM qui ne peut pas gérer un ram physique> 4 Go sur un système 32 bits ou quelque chose du genre.

En outre, un point important: exécuter en tant que non root. Les utilisateurs root ne sont jamais censés mâcher des ressources, ils ont donc plus de limites de tolérance (par exemple 99% de mémoire contre 95% pour les utilisateurs non root). Cela peut expliquer pourquoi le MOO est dans un tel état. De plus, cela donne OOM et. Al. plus de marge pour faire son travail de récupération de la mémoire.

4
Craig Estey

palourde? Il semble que vous utilisiez ClamAV et que le contrôle sur accès soit activé lorsque le moteur antivirus tente de rechercher des virus dans les fichiers ouverts, en chargeant en mémoire, le contenu entier de chaque fichier ouvert par tout autre processus.

En fonction de votre sécurité et de la nécessité de ce transfert, vous devez évaluer la désactivation de l'analyse à l'accès ClamAV pendant que vous effectuez le transfert.

2
oo.