Rsync hat den Linux-OOM-Killer für eine einzelne 50-GB-Datei ausgelöst

Ich habe eine einzelne 50-GB-Datei auf Server_A und kopiere sie auf Server_B. ich renne

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

Server_B verfügt über 32 GB RAM mit 2 GB Swap. Es ist größtenteils inaktiv und sollte viel freien Arbeitsspeicher haben. Es hat viel Speicherplatz. Bei ca. 32 GB wird die Übertragung abgebrochen, da die Remote-Seite die Verbindung geschlossen hat.

Server_B hat jetzt das Netzwerk verlassen. Wir bitten das Rechenzentrum, es neu zu starten. Wenn ich mir das Kernel-Protokoll von vor dem Absturz ansehe, sehe ich, dass es 0 Bytes Swap verwendete und die Prozessliste sehr wenig Arbeitsspeicher beanspruchte (der Rsync-Prozess wurde mit 600 KB RAM aufgelistet), aber der oom_killer war es Das letzte, was im Protokoll steht, ist, wo der Kernel-Reader-Prozess von metalog beendet wird.

Dies ist der 32-Bit-Kernel 3.2.59 (daher kann kein Prozess ohnehin mehr als 4 GB zuordnen).

Es ist fast so, als hätte Linux dem Caching mehr Priorität als den langlebigen Daemons. Was gibt?? Und wie kann ich verhindern, dass es wieder passiert?

Hier ist die Ausgabe des 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

Hier ist die 'Top'-Ausgabe, nachdem ich meinen rsync-Befehl als Nicht-Root-Benutzer wiederholt habe:

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

Hier sind die sysctl vm-Parameter:

# 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

— Datenlos
quelle

Ich bin kein Experte für das Lesen von Kernel-Absturzmeldungen, aber ich kann keinen Hinweis darauf sehen, dass B 32 GB Core verwendet hat. Bevor wir davon ausgehen, dass dies der Fall ist, können Sie bestätigen, dass dies der Fall ist? Denn es gibt einen großen Unterschied zwischen einer speicherintensiven Box mit 32 GB Kern und einer mit nur 4 GB.

— MadHatter

Aktualisiert mit Top-Ausgabe. Dies geschieht, nachdem derselbe Befehl rsync wie ein Benutzer ohne Rootberechtigung ausgeführt wurde. Bis auf 1 GB wird im Moment so ziemlich alles für den Cache verwendet.

— Datum

Vielen Dank. Wie gesagt, ich bin kein Experte - aber es schien sich zu lohnen, es zu überprüfen.

— MadHatter

Sie sollten auch sicherstellen, dass Ihr Kernel das Auslagern zulässt (dh, das Auslagern ist nicht deaktiviert) (und Sie sollten einen größeren Teil des Festplattenspeichers reservieren, z. B. 16 GB oder sogar 32 GB). Einige seltsame Personen im Netz empfehlen, das Tauschen auszuschalten, was sehr falsch ist.

— Olivier Dulac

@OlivierDulac auf welche einstellung beziehst du dich? Die Swap-Unterstützung ist kompiliert, oder wir könnten Swap nicht bereitstellen, und die "Swap-Fähigkeit" ist auf 60 gesetzt. Würde das das Problem bei einem 32-Bit-Kernel nicht noch verschlimmern? Die Antwort scheint zu sein, dass Kernel-Datenstrukturen uns umgebracht haben. Wir betreiben keine 32 GB Benutzerprozesse, wir wollen nur so viel RAM für den Festplatten-Cache, für die Leistung.

— Datum

Antworten:

178

Lesen wir also die Ausgabe von oom-killer und sehen, was wir daraus lernen können.

Bei der Analyse von OOM-Killer-Protokollen ist es wichtig, die Auslöser zu untersuchen. Die erste Zeile Ihres Protokolls gibt uns einige Hinweise:

[kernel] [1772321.850644] clamd hat oom-killer aufgerufen: gfp_mask = 0x84d0, order = 0

order=0sagt uns, wie viel Speicher angefordert wird. Die Speicherverwaltung des Kernels kann nur die Seitenzahlen in den Potenzen von 2 verwalten, so clamd 2 angefordert hat ⁰ Seiten des Speichers oder 4 KB.

Die niedrigsten zwei Bits des GFP_MASK (erhalten kostenlose Seite Maske) bilden die sogenannte Zonenmaske die allocator erklärt , welche Zone aus dem Speicher zu erhalten :

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

Speicherzonen sind ein Konzept, das hauptsächlich aus Kompatibilitätsgründen erstellt wurde. In einer vereinfachten Ansicht gibt es drei Zonen für einen x86-Kernel:

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

In Ihrem Fall ist die Zonenmaske 0, was bedeutet, dass clamd Speicher von anfordert ZONE_NORMAL.

Die anderen Flags werden in aufgelöst

/*
 * 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 */

nach der Dokumentation Linux MM , so hat Ihre requst die Flaggen für GFP_ZERO, GFP_REPEAT, GFP_FS, GFP_IOund GFP_WAIT, also nicht besonders wählerisch zu sein.

Also, was ist ZONE_NORMALlos mit ? Einige allgemeine Statistiken finden Sie weiter unten in der OOM-Ausgabe:

[kernel] [1772321.850770] Normal frei: 8056kB min: 8048kB niedrig: 10060kB hoch: 12072kB active_anon: 0kB inactive_anon: 0kB active_file: 248kB inactive_file: 388kB unevictable: 0kB isolated (anon): 0kB present (file: 0kB)

Hier fällt auf, dass freees nur 8 km von minund weit darunter sind low. Dies bedeutet, dass der Speichermanager Ihres Hosts etwas in Bedrängnis ist und kswapd die Seiten bereits auslagern sollte, da es sich in der gelben Phase des folgenden Diagramms befindet:

Weitere Informationen zur Speicherfragmentierung der Zone finden Sie hier:

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

Grundsätzlich besagt dies, dass Sie eine einzelne zusammenhängende Seite von 4 MB haben, während der Rest stark in hauptsächlich 4-KB-Seiten fragmentiert ist.

Fassen wir also zusammen:

Sie haben einen Userland-Prozess ( clamd), von dem Speicher abgerufen wird , ZONE_NORMALwährend die Zuweisung von nicht privilegiertem Speicher normalerweise von ausgeführt wirdZONE_HIMEM
Der Speichermanager sollte zu diesem Zeitpunkt in der Lage sein, die angeforderte 4K-Seite zu bedienen, obwohl Sie anscheinend einen erheblichen Speicherdruck haben ZONE_NORMAL
das System, durch kswapd‚s Regeln, sollten einige Paging - Aktivität haben vorher gesehen, aber nichts wird ausgelagert, auch unter Speicherdruck in ZONE_NORMAL, ohne erkennbare Ursache
Keiner der oben genannten Gründe gibt einen eindeutigen Grund für oom-killerdie Inanspruchnahme

All dies scheint ziemlich seltsam zu sein, aber es hängt zumindest damit zusammen, was in Abschnitt 2.5 von John O'Gormans exzellentem Buch "Das Verständnis des virtuellen Linux-Speichermanagers" beschrieben ist :

Da der vom Kernel verwendbare Adressraum (ZONE_NORMAL) begrenzt ist, unterstützt der Kernel das Konzept des hohen Speichers. [...] Um auf Speicher zwischen 1 GB und 4 GB zuzugreifen, ordnet der Kernel mit kmap () vorübergehend Seiten aus dem hohen Speicher in ZONE_NORMAL zu. [...]

Das bedeutet, dass zur Beschreibung von 1 GB Speicher ca. 11 MB Kernelspeicher erforderlich sind. Mit 16 GB werden 176 MB Speicher verbraucht, was ZONE_NORMAL erheblich belastet. Dies klingt erst dann schlecht, wenn andere Strukturen berücksichtigt werden, die ZONE_NORMAL verwenden. Selbst sehr kleine Strukturen wie Page Table Entries (PTEs) benötigen im schlimmsten Fall ca. 16MiB. Dies macht 16GiB zur praktischen Grenze für den verfügbaren physischen Speicher von Linux auf einem x86 .

(Schwerpunkt liegt bei mir)

Da 3.2 gegenüber 2.6 zahlreiche Fortschritte in der Speicherverwaltung aufweist, ist dies keine eindeutige Antwort, sondern ein wirklich starker Hinweis, den ich zuerst verfolgen möchte. Reduzieren Sie den verwendbaren Arbeitsspeicher des Hosts auf maximal 16 GB, indem Sie entweder den mem=Kernel-Parameter verwenden oder die Hälfte der DIMMs aus dem Server rippen.

Verwenden Sie letztendlich einen 64-Bit-Kernel .

Alter, es ist 2015.

— das-wabbit
quelle

Als ich oben sagte " Ich bin kein Experte ", hoffte ich , dies zu lesen. +1000, wenn ich nur könnte; +1 sicher. Was für eine großartige Antwort!

— MadHatter

Das war schön. Es gibt immer noch Hoffnung für SF.

— Roman

@dataless Ja. Ich vermute, dass Ihre gesamte ZONE_NORMAL mit Metadaten zu den oberen Speicherbereichen gefüllt ist. Wenn ein Userland-Prozess Speicherseiten anfordert, fordert er höchstwahrscheinlich ZONE_HIGHMEM an (das möglicherweise von der MM auf ZONE_NORMAL aktualisiert wird, wenn HIGHMEM keine freien Seiten mehr für die Anforderung hat, NORMAL jedoch), sofern ZONE_HIGHMEM nicht unter Speicherdruck steht (Ihre nicht), ZONE_NORMAL hat keine Seiten für User-Space-Prozesse.

— the-wabbit

[schlägt die Fäuste auf die Tastatur] Gib diesem Wabbit das Kopfgeld

— underscore_d

@ the-wabbit Heiße Netzwerkfragen.

— CodesInChaos

Ein paar Dinge ...

Meine Faustregel für den Swap Space war, mindestens die doppelte Menge an physischem RAM zu haben. Auf diese Weise kann der Page / Swap-Daemon den Speicher effizient neu ordnen.

Server_B hat 32 GB RAM. Versuchen Sie daher, ihn für 64 GB Swap zu konfigurieren. IMO, die 2 GB Swap-Speicherplatz auf Ihrem Server sind viel zu niedrig, insbesondere für einen Server.

Wenn Sie keine zusätzliche Partition haben, die Sie in eine Auslagerungspartition umwandeln können, können Sie dies testen, indem Sie eine Datei erstellen und als Auslagerungspartition bereitstellen (dies ist langsam). Siehe https://www.maketecheasier.com/swap-partitions-on-linux/

Da server_B über viel Festplattenspeicher verfügt, wird --inplace nicht benötigt und ist möglicherweise unerwünscht, da dies dazu führen kann, dass rsync 32 GB verwendet. --inplace ist nur dann wirklich nützlich, wenn Sie wenig Speicherplatz im Dateisystem haben oder besondere Leistungsanforderungen haben.

Ich vermute, dass rsync 50 GB RAM [die Dateigröße] mit Ihren aktuellen Optionen verwenden möchte. Normalerweise benötigt rsync nicht so viel Speicher, um seine Arbeit zu erledigen, daher können eine oder mehrere Ihrer Optionen das Problem sein. Ich übertrage routinemäßig 200 GB Dateien ohne Probleme.

Führen Sie einige Testläufe ohne Optionen durch. Tun Sie dies mit kleineren Dateien, z. B. 10 GB - dies sollte die Kernel-Panik verhindern, aber Sie können trotzdem das Verhalten überwachen, das das Problem verursacht. Überwachen Sie die Speichernutzung von rsync.

Fügen Sie nach und nach Optionen nacheinander hinzu, um festzustellen, welche Option (oder Optionskombination) dazu führt, dass rsync den RAM-Speicher auffüllt (z. B. wächst die RAM-Nutzung von rsync proportional zur Menge der übertragenen Dateidaten). usw.).

Wenn Sie wirklich die Optionen benötigen, die dazu führen, dass rsync ein bestimmtes RAM-Dateibild beibehält, benötigen Sie den zusätzlichen Auslagerungsspeicher, und Ihre maximale Dateigröße wird entsprechend begrenzt.

Noch ein paar Dinge [AKTUALISIERT]:

(1) Der Kernel-Stack-Traceback zeigt, dass bei rsync in einem mmap-Bereich ein Seitenfehler aufgetreten ist. Wahrscheinlich wird die Datei gemappt. mmap übernimmt keine Garantie dafür, dass die Datei auf die Festplatte gespült wird, bis sie geschlossen wird (anders als beim Lesen / Schreiben) und sofort in den FS-Blockcache gelangt (wo sie gespült wird).

(2) Der Kernel-Absturz / die Kernel-Panik tritt auf, wenn die Übertragungsgröße die RAM-Größe erreicht. Offensichtlich greift rsync über malloc oder mmap auf so viel Nicht-fscache-Speicher zu. Erneut weist rsync mit den von Ihnen angegebenen Optionen 50 GB Arbeitsspeicher für die Übertragung einer 50-GB-Datei zu.

(3) Übertragen Sie eine 24-GB-Datei. Das wird wahrscheinlich funktionieren. Starten Sie dann den Kernel mit mem = 16G und führen Sie den 24-GB-Dateitest erneut durch. Es wird bei 16 GB statt 32 GB ausblasen. Dadurch wird bestätigt, dass rsync den Speicher wirklich benötigt.

(4) Bevor Sie sagen, das Hinzufügen von Swap ist lächerlich, versuchen Sie es mit [über die Swap-to-File-Methode]. Dies ist viel einfacher zu tun und zu testen als alle akademischen Argumente darüber, wie Swap nicht erforderlich ist. Auch wenn es nicht die Lösung ist, können Sie etwas daraus lernen. Ich wette, dass der mem = 16G-Test ohne Panik / Absturz erfolgreich sein wird.

(5) Die Chancen stehen gut, dass rsync ist Swap schlagen, aber es passiert zu schnell mit oben vor OOM Tritte zu sehen in und tötet rsync. Bis rsync 32 GB erreicht, wurden bereits andere Prozesse zum Auslagern gezwungen, insbesondere wenn sie inaktiv sind. Vielleicht ergibt eine Kombination aus "frei" und "oben" ein besseres Bild.

(6) Nachdem rsync beendet wurde, dauert es einige Zeit, die MMAP auf den FS zu übertragen. Nicht schnell genug für OOM und es beginnt andere Dinge zu töten [einige sind offensichtlich geschäftskritisch]. Das heißt, die MMAP Flush und OOM rennen. Oder OOM hat einen Fehler. Sonst würde es keinen Absturz geben.

(7) Nach meiner Erfahrung dauert es lange, bis ein System vollständig wiederhergestellt ist, sobald es die Speicherwand erreicht hat. Und manchmal wird es nie richtig wiederhergestellt, und der einzige Weg, dies zu beheben, ist ein Neustart. Zum Beispiel habe ich 12 GB RAM. Wenn ich einen Job mit 40 GB Arbeitsspeicher ausführe (für große Jobs stehen 120 GB Swap-Speicher zur Verfügung) und ihn dann beende, dauert es ungefähr 10 Minuten, bis das System wieder normal reagiert (wobei die Festplattenanzeige ständig leuchtet). .

(8) Führen Sie rsync ohne Optionen aus. Das wird funktionieren. Holen Sie sich ein Basisbeispiel zum Arbeiten. Fügen Sie dann back - inplace hinzu und wiederholen Sie den Test. Führen Sie stattdessen --append-verify aus. Probieren Sie dann beide aus. Finden Sie heraus, mit welcher Option rsync die große mmap ausführt. Dann entscheide dich, ob du ohne leben kannst. Wenn --inplace der Täter ist, ist das ein Kinderspiel, da Sie genügend Speicherplatz haben. Wenn Sie die Option haben müssen, müssen Sie den Swap-Platz erhalten, um die Malloc / MMAP aufzunehmen, die rsync ausführen wird.

ZWEITES UPDATE:

Bitte führen Sie die oben genannten Tests für mem = und kleinere Dateien durch.

Die zentralen Fragen: Warum wird rsync von OOM getötet? Wer / Was kaut Erinnerung?

Ich habe gelesen [aber vergessen], dass das System 32-Bit ist. Ich bin damit einverstanden, dass rsync möglicherweise nicht direkt verantwortlich ist (über malloc / mmap - glibc implementiert große mallocs über anonyme / private mmaps), und der mmap-Seitenfehler von rsync löst OOM nur zufällig aus. Anschließend berechnet OOM den von rsync direkt und indirekt belegten Gesamtspeicher [FS-Cache, Socket-Puffer usw.] und entscheidet, ob dies der Hauptkandidat ist. Daher kann die Überwachung der gesamten Speichernutzung hilfreich sein. Ich vermute, es kriecht mit der gleichen Geschwindigkeit wie die Dateiübertragung. Offensichtlich sollte es nicht.

Einige Dinge, die Sie in / proc oder / proc / rsync_pid über ein Perl- oder Python-Skript in einer schnellen Schleife überwachen können [ein Bash-Skript ist wahrscheinlich nicht schnell genug für das End-of-the-World-Ereignis], das alle überwachen kann die folgenden mehrere hundert mal / sek. Sie können dies mit einer höheren Priorität als rsync ausführen, damit es sich selbst im Arbeitsspeicher hält und ausgeführt wird, damit Sie die Dinge kurz vor dem Absturz und hoffentlich während OOM überwachen können, damit Sie sehen können, warum OOM verrückt wird:

/ proc / meminfo - um die Swap-Nutzung am "Aufprallpunkt" genauer kennenzulernen. Tatsächlich kann es sinnvoller sein, die endgültige Anzahl der insgesamt verwendeten RAMs zu ermitteln. Obwohl top dies vorsieht, ist es möglicherweise nicht schnell genug, um den Zustand des Universums kurz vor dem "Urknall" anzuzeigen (z. B. die letzten 10 Millisekunden).

/ proc / rsync_pid / fd verzeichnis. Durch Lesen der Symlinks können Sie feststellen, welche FD in der Zieldatei geöffnet ist (z. B. Readlink von / proc / rsync_pid / fd / 5 -> Zieldatei). Dies muss wahrscheinlich nur einmal gemacht werden, um die FD-Nummer zu erhalten [es sollte fest bleiben]

Wenn Sie die fd-Nummer kennen, lesen Sie / proc / rsync_pid / fdinfo / fd. Es ist eine Textdatei, die so aussieht:

pos: <Dateiposition>
flags: blah_blah
mnt_id: blah_blah

Das Überwachen des "pos" -Werts kann hilfreich sein, da die "letzte Dateiposition" hilfreich sein kann. Wenn Sie mehrere Tests mit unterschiedlichen Größen und mem = -Optionen durchführen, verfolgt die letzte Dateiposition eine dieser Angaben [und wie]? Der übliche Verdacht: Dateiposition == verfügbarer RAM

Am einfachsten ist es jedoch, mit "rsync local_file server: remote_file" zu beginnen und zu überprüfen, ob dies funktioniert. Möglicherweise können Sie ähnliche [aber schnellere] Ergebnisse erzielen, indem Sie "ssh server rsync file_a file_b" ausführen [Sie müssen zuerst eine 50-GB-Datei_a erstellen]. Eine einfache Möglichkeit, file_a zu erstellen, ist scp local_system: original_file server: file_a. Dies könnte für sich selbst interessant sein. Funktioniert dies beispielsweise, wenn der rsync abstürzt? Wenn scp funktioniert, aber rsync fehlschlägt, zeigt dies auf rsync zu etwas anderem wie dem NIC-Treiber). Durch Ausführen von ssh rsync wird auch die Netzwerkkarte aus der Gleichung entfernt, was hilfreich sein kann. Wenn dies das System verschlaucht, stimmt etwas nicht. Wenn dies gelingt, [wie bereits erwähnt] fügen Sie die Optionen nacheinander wieder hinzu.

Ich hasse es, den Punkt zu klären, aber das Hinzufügen von Swap über Swap-to-File kann das Absturzverhalten ändern / verzögern und als Diagnosetool nützlich sein. Wenn das Hinzufügen von beispielsweise 16 GB Swap den Absturz [gemessen an der Speichernutzung oder der Zieldateiposition] von 32 GB auf 46 GB verzögert, sagt dies etwas aus.

Möglicherweise handelt es sich nicht um einen bestimmten Prozess, sondern um einen fehlerhaften Kerneltreiber, der Speicherplatz beansprucht. Das interne vmalloc des Kernels ordnet Dinge zu und kann ausgetauscht werden. IIRC ist nicht unter allen Umständen an die Adressierbarkeit gebunden.

Offensichtlich wird die OOM verwirrt / in Panik versetzt. Das heißt, rsync wird beendet, der Speicher wird jedoch nicht rechtzeitig freigegeben, und es wird nach anderen Opfern gesucht. Einige von ihnen sind wahrscheinlich kritisch für den Systembetrieb.

Abgesehen von malloc / mmap kann dies durch einen nicht geleerten FS-Cache verursacht werden, der lange dauert (z. B. bei 30 GB nicht geleerten Daten und einer angenommenen Festplattenrate von 300 MB / s kann das Leeren 100 Sekunden dauern). Selbst bei dieser Rate kann OOM zu ungeduldig sein. Oder: OOM-Killing-Rsync startet den FS-Flush nicht schnell genug (oder überhaupt nicht). Oder FS-Flush geschieht schnell genug, aber es kommt zu einer "trägen" Freigabe der Seiten zurück in den freien Pool. Es gibt einige / proc-Optionen, mit denen Sie das Verhalten des FS-Cache steuern können [Ich kann mich nicht erinnern, was sie sind].

Versuchen Sie, mit mem = 4G oder einer anderen kleinen Zahl zu booten. Dies kann den FS-Cache einschränken und die Räumungszeit verkürzen, um zu verhindern, dass OOM nach anderen zu tötenden Dingen sucht (z. B. wird die Räumungszeit von 100 Sekunden auf <1 Sekunde verringert). Möglicherweise wird auch ein OOM-Fehler entlarvt, der auf einem 32-Bit-System oder ähnlichem keinen physischen RAM> 4 GB verarbeiten kann.

Außerdem ein wichtiger Punkt: Als Nicht-Root ausführen. Von Root-Benutzern wird nie erwartet, dass sie Ressourcen kauen, sodass ihnen mehr verzeihende Grenzen gesetzt werden (z. B. 99% des Arbeitsspeichers gegenüber 95% für Nicht-Root-Benutzer). Dies könnte erklären, warum sich OOM in einem solchen Zustand befindet. Auch dies gibt OOM et. al. mehr Spielraum für die Wiederherstellung des Gedächtnisses.

— Craig Estey
quelle

Siehe Wie viel SWAP-Speicherplatz auf einem System mit hohem Arbeitsspeicher? - und Sie möchten nicht, dass Ihr System 63 GB Swap verwendet. Es wird nicht verwendbar sein.

— Reinstate Monica - M. Schröder

Swap> RAM ist nur dann wirklich nützlich, wenn Sie ohne VM-Overcommit arbeiten. Daher muss der Kernel Auslagerungsspeicher für zugewiesene Seiten reservieren, bis sie verschmutzt sind und echte physische Seiten benötigen, die sie sichern. Gegenwärtig ist es üblich, eine Überbeanspruchung zuzulassen und mit einer geringen Menge an Auslagerungsspeicher zum Auslagern von Seiten zu arbeiten, die nur beim Start berührt wurden und im normalen Betrieb nicht benötigt werden. overcommit = 0 mit kleinem Swap ist in Ordnung, wenn Sie für die meisten Systeme über viel RAM verfügen.

— Peter Cordes

Es scheint , dass rsync wirklich ist zu verwenden versuchen , > 32 GB, so dass der Swap ist dafür erforderlich. Das heißt, rsync wird 50 GB für diese Datei verwenden. Das 2x ist seit 30 Jahren eine bewährte Metrik. Da eine 6-TB-Festplatte ~ 300 US-Dollar kostet, gibt es keinen Grund, dies nicht zu tun. Was läuft möglicherweise noch auf diesem Server, der gemeinsam die RAM-Grenze überschreitet?

— Craig Estey

@CraigEstey 64 GB Swap sind völlig lächerlich, da wir, wie bereits erwähnt, keine großen Benutzerprozesse haben, nur den Festplatten-Cache benötigen und, wie mein Protokoll zeigte, zum Zeitpunkt des Absturzes den ZERO-Swap verwendeten. NULL. Außerdem verwendet rsync 600 KB RAM, selbst bei einer 50-GB-Datei. Meine anfängliche Verwirrung war, dass Linux vielleicht aggressiv am Festplatten-Cache festhielt. Und schließlich möchte ich einige Zahlen oder Unterlagen darüber sehen, wie viel Speicher der Kernel verwendet, um seinen Auslagerungsspeicherplatz zu verfolgen, bevor ich mehr zu dieser Box hinzufügen würde.

— Datum

@dataless Ich habe zusätzliche Informationen hinzugefügt, die vollständig erklären, was passiert und warum. rsync ist packte den Speicher über malloc / mmap und es wird für 50 GB gehen , bevor es fertig ist. Siehe den aktualisierten Abschnitt. Es hat Tests, die beweisen / widerlegen können, was ich sage, und Sie können den hinzugefügten Swap zunächst überspringen, um zu testen. Übrigens, ich habe die Programmierung Kernel / Treiber für 40+ Jahre - ich könnte nur etwas wissen , dass Sie nicht, also bitte den Ton moderieren - ich bin versucht zu helfen.

— Craig Estey

Clamd? Es hört sich so an, als ob Sie ClamAV verwenden und die On-Access-Prüfung aktiviert haben, bei der die Antiviren-Engine versucht, geöffnete Dateien auf Viren zu prüfen, indem der gesamte Inhalt jeder Datei, die von einem anderen Prozess geöffnet wurde , in den Speicher geladen wird .

Abhängig von Ihrer Sicherheitslage und der Notwendigkeit dieser Übertragung sollten Sie die Deaktivierung des On-Access-Scans von ClamAV prüfen, während Sie die Übertragung durchführen.

— oo.
quelle

Mir war nicht bewusst, dass Clamav das überhaupt kann ... aber nein, wir scannen nur bestimmte Dateien, die von Clamc an Clamav weitergeleitet wurden. Auch 32-Bit, so dass keine Gefahr besteht, dass der gesamte Systemspeicher überlastet wird. (Sie sehen, warum wir dachten, 32-Bit war immer noch eine gute Idee?)

— Datum

Der Linux-Kernel meldet, dass clamd der Prozess ist, dessen Speicherzuweisungsanforderungen den OOM-Killer aufrufen. ClamAV ist mit ziemlicher Sicherheit die sekundäre Ursache (die primäre Ursache ist nicht genügend Speicher). Unabhängig davon, ob es sich um On-Access-Scans oder eine andere Konfiguration handelt, stehen alle Zeichen auf ClamAV.

— oo.

Führen Sie beim nächsten Start von rsync top aus und überwachen Sie die residente Größe des Clamd-Prozesses.

— oo.

clamd war der erste Prozess, der den Oom-Killer aufgerufen hat, aber auch der erste, der daran gestorben ist, da er fast 42 MB wiegt (einer der größeren Prozesse auf dem Server). Der oom_killer läuft danach so oft, bis selbst Metalog getötet wird.

— Datum