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
quelle
Antworten:
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:
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 0 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 :
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:
In Ihrem Fall ist die Zonenmaske 0, was bedeutet, dass clamd Speicher von anfordert
ZONE_NORMAL.Die anderen Flags werden in aufgelöst
nach der Dokumentation Linux MM , so hat Ihre requst die Flaggen für
GFP_ZERO,GFP_REPEAT,GFP_FS,GFP_IOundGFP_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:Hier fällt auf, dass
freees nur 8 km vonminund weit darunter sindlow. 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:
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:
clamd), von dem Speicher abgerufen wird ,ZONE_NORMALwährend die Zuweisung von nicht privilegiertem Speicher normalerweise von ausgeführt wirdZONE_HIMEMZONE_NORMALkswapd‚s Regeln, sollten einige Paging - Aktivität haben vorher gesehen, aber nichts wird ausgelagert, auch unter Speicherdruck inZONE_NORMAL, ohne erkennbare Ursacheoom-killerdie InanspruchnahmeAll 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 :
(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.
quelle
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:
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.
quelle
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.
quelle