Rsyncは単一の50 GBファイルでLinux OOMキラーをトリガーしました
Server_Aに50 GBのファイルが1つあり、それをserver_Bにコピーしています。走る
server_A$ rsync --partial --progress --inplace --append-verify 50GB_file root@server_B:50GB_file
Server_Bには32 GBのRAM 2 GBのスワップがあります。ほとんどがアイドル状態であり、十分な空きRAMが必要でした。十分なディスク容量が必要です。約32 GBになると、転送が中止されます。リモート側が接続を閉じました。
Server_Bがネットワークから切断されました。データセンターに再起動を依頼します。クラッシュする前のカーネルログを見ると、0バイトのスワップを使用しており、プロセスリストが使用しているメモリはごくわずかです（rsyncプロセスは600 KBのRAMを使用していると表示されています）が、oom_killerはワイルドになり、ログの最後の部分で、Metalogのカーネルリーダープロセスが強制終了されます。
これはカーネル3.2.59、32ビットです（したがって、いずれのプロセスも4 GBを超えるマッピングはできません）。
それはまるでLinuxが長命の実行中のデーモンよりもキャッシュを優先するかのようです。何が？そして、どうすれば再発を防ぐことができますか？
以下は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
Root以外のユーザーとしてrsyncコマンドを繰り返した後の「トップ」出力は次のとおりです。
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
次に、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
それでは、oom-killerの出力を読んで、そこから何が学べるか見てみましょう。
OOMキラーログを分析する場合、それをトリガーしたものを確認することが重要です。ログの最初の行はいくつかの手掛かりを与えてくれます：
[カーネル] [1772321.850644] clamdがoom-killerを呼び出しました：gfp_mask = 0x84d0、order =
order=0は、要求されているメモリの量を示しています。カーネルのメモリ管理は2の累乗でのみページ番号を管理できるため、clamdは2を要求しました メモリのページまたは4KB。
GFP_MASK（フリーページマスクの取得）の最下位2ビットは、いわゆるゾーンマスクどのゾーンからメモリを取得するかをアロケータに伝える ：
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
メモリゾーン は、主に互換性の理由で作成された概念です。簡略化したビューでは、x86カーネルには3つのゾーンがあります。
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
あなたの場合、zonemaskは0です。つまり、clamdはZONE_NORMALからメモリを要求しています。
他のフラグは解決しています
/*
* 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 */
Linux MMドキュメント によると、要求にはGFP_ZERO、GFP_REPEAT、GFP_FS、GFP_IO、GFP_WAITのフラグがあり、特にうるさいというわけではありません。
では、ZONE_NORMALはどうなっているのでしょうか。いくつかの一般的な統計は、OOM出力でさらに見つけることができます。
[カーネル] [1772321.850770]通常free：8056kB min：8048kB low：10060kBhigh：12072kB active_anon：0kB inactive_anon：0kB active_file ：248kB inactive_file：388kB使用不可：0kB分離（anon）：0kB分離（ファイル）：0kB存在：890008kB
ここで注目すべきは、freeがminからわずか8Kであり、lowの下にあることです。これは、ホストのメモリマネージャーがやや困っており、kswapdが下のグラフのyellowフェーズにあるので、すでにページをスワップアウトしている必要があることを意味します： 
ゾーンのメモリの断片化についての詳細は、次のとおりです。
[カーネル] [1772321.850795]通常：830 * 4kB 80 * 8kB 0 * 16kB 0 * 32kB 0 * 64kB 0 * 128kB 0 * 256kB 0 * 512kB 0 * 1024kB 0 * 2048kB 1 * 4096kB = 8056kB
基本的に、4MBの単一の連続したページがあり、残りは主に4KBページに大きく断片化されていると述べています。
要約してみましょう：
- ユーザーランドプロセス（
clamd）がZONE_NORMALからメモリを取得しているのに対し、非特権メモリ割り当ては通常ZONE_HIMEMから実行されます - この段階では、メモリマネージャーは要求された4Kページを提供できているはずですが、
ZONE_NORMALに大きなメモリ負荷がかかっているようです - システムは
kswapdの規則により、すべきはいくつかのページングアクティビティを事前に見ましたが、明確な原因なしに、ZONE_NORMALのメモリ負荷下でも、何もスワップアウトされていません - 上記のいずれも、
oom-killerが呼び出された理由について明確な理由を与えません
これらはすべて奇妙に見えますが、少なくとも、John O'Gormanの優れた「Linux仮想メモリマネージャについて」の本の セクション2.5に記載されている内容と関連しています ：
カーネル（ZONE_NORMAL）が使用できるアドレス空間のサイズには制限があるため、カーネルはハイメモリの概念をサポートしています。 [...] 1GiBと4GiBの範囲のメモリにアクセスするために、カーネルはkmap（）を使用して、一時的にハイメモリのページをZONE_NORMALにマップします。 [...]
つまり、1GiBのメモリを説明するには、約11MiBのカーネルメモリが必要です。したがって、16GiBでは176MiBのメモリが消費され、ZONE_NORMALに大きなプレッシャーがかかります。これは、ZONE_NORMALを使用する他の構造が考慮に入れられるまで、それほど悪く聞こえません。ページテーブルエントリ（PTE）などの非常に小さな構造でも、最悪の場合、約16 MiBが必要です。 これにより、x86上のLinuxで利用可能な物理メモリの実用的な制限が16GiBになります。
（強調は私のものです）
3.2は2.6を超えるメモリ管理で多くの進歩を遂げているため、これは明確な答えではありませんが、最初に追求する本当に強力なヒントです。 mem=カーネルパラメータを使用するか、DIMMの半分をサーバーからリッピングして、ホストの使用可能なメモリを最大16Gに減らします。
最終的に、64ビットカーネルを使用する。
おい、それは2015年です。
いくつかのこと...
私のスワップ領域の目安は、物理RAMの量の少なくとも2倍にすることです。これにより、ページ/スワップデーモンがメモリを効率的に再編成できるようになります。
Server_Bには32GBのRAMがあるため、64GBのスワップ用に構成してみてください。 IMO、サーバーにある2GBのスワップ領域はwayで、特にサーバーの場合は低すぎます。
スワップパーティションにできる追加のパーティションがない場合は、ファイルを作成し、それをスワップパーティションとしてマウントすることでテストできます[遅いです]。 https://www.maketecheasier.com/swap-partitions-on-linux/ を参照してください
Server_Bには十分なディスク領域があるため、-inplaceは不要であり、rsyncが32GBを使用する原因となっている可能性があるため、望ましくありません。 --inplaceが本当に役立つのは、ファイルシステムのスペースが不足している場合（そうでない場合）、または特別なパフォーマンス要件がある場合のみです。
私の推測では、rsyncは現在のオプションで50GBのRAM [ファイルサイズ]を使用することになるでしょう。通常、rsyncはその処理にそれほど多くのメモリを必要としないため、1つ以上のオプションが問題である可能性があります。 200GBのファイルを問題なく定期的に転送しています。
オプションを使用せずにテストを実行します。これを小さいファイル、たとえば10GBで実行します。これにより、カーネルパニックを防ぐことができますが、問題の原因となっている動作を監視することができます。 rsyncのメモリ使用量を監視します。
徐々に、オプションを1つずつ追加して、どのオプション[またはオプションの組み合わせ]がrsyncにRAM=（転送が行われている間、rsyncのRAM使用量が増加している間）にピグアウトするようになるかを確認します。転送されるファイルデータの量などに比例します）。
RsyncにRAM内のファイルイメージを維持させるオプションが本当に必要な場合は、追加のスワップスペースが必要で、それに応じて最大ファイルサイズが制限されます。
さらにいくつか[更新]：
（1）カーネルスタックトレースバックは、rsyncがmmap領域でページフォールトであったことを示しています。おそらくファイルをマップしています。 mmapは、ディスクがまでフラッシュすることを保証しません（== --- ==）ファイルが閉じられます[読み取り/書き込みとは異なり] FSすぐにブロックキャッシュ[フラッシュされる場所]
（2）転送サイズがRAMのサイズに達すると、カーネルクラッシュ/パニックが発生します。明らかにrsyncは、mallocまたはmmapを介してfs以外の多くのメモリを取得しています。ここでも、指定したオプションを使用して、rsyncは50 GBのメモリを割り当て、50 GBのファイルを転送します。
（3）24GBファイルを転送します。それはおそらくうまくいくでしょう。次に、mem = 16Gでカーネルを起動し、24GBファイルテストを再度実行します。 32GBではなく16GBで爆発します。これにより、rsyncが本当にメモリを必要とすることが確認されます。
（4）スワップの追加がばかげていると言う前に、[swap-to-fileメソッドを使用して]いくつか追加してみてください。これは、スワップがどのように必要とされないかに関するすべての学術的議論よりもはるかに簡単に実行およびテストできます。それが解決策でなくても、あなたはそれから何かを学ぶかもしれません。 mem = 16Gテストはパニック/クラッシュなしで成功することを確信しています。
（5）おそらくrsyncisがスワップをヒットしていますが、OOMが起動してrsyncを強制終了する前にtopで表示するには速すぎます。 rsyncが32GBに達するまでに、他のプロセスは、特にアイドル状態の場合は、すでに強制的にスワップされています。おそらく、「フリー」と「トップ」の組み合わせがより良い絵を与えるでしょう。
（6）rsyncが終了した後、mmapをFSにフラッシュするのに時間がかかります。 OOMに十分な速さではなく、他のものを殺し始めます[いくつかは明らかにミッションクリティカルです]。つまり、mmapフラッシュとOOMは競合しています。または、OOMにバグがあります。そうでなければ、クラッシュは発生しません。
（7）私の経験では、システムが「メモリの壁にぶつかる」と、Linuxが完全に回復するのに長い時間がかかります。そして、時にはそれが本当に適切に回復しないことがあり、それをクリアする唯一の方法は再起動です。たとえば、12GBのRAMがあります。 40GBのメモリを使用するジョブを実行して（大きなジョブに対応するために120GBのスワップがある場合）、それを強制終了すると、システムが通常の応答性に戻るまでに約10分かかります（ディスクライトが点灯している間）。 。
（8）オプションなしでrsyncを実行します。これは機能します。作業の基準となるサンプルを取得します。次に、-inplaceを追加して再テストします。次に、代わりに--append-verifyを実行します。次に、両方を試してください。巨大なmmapを実行するrsyncを取得するオプションを見つけます。次に、それなしで生活できるかどうかを決定します。 --inplaceが原因である場合、十分なディスク容量があるので、それは非常に簡単です。オプションが必要な場合は、rsyncが実行するmalloc/mmapに対応するためのスワップ領域を取得する必要があります。
2回目の更新：
上記のmem =および小さいファイルのテストを行ってください。
中心的な質問：rsyncがOOMによって強制終了されるのはなぜですか？誰が/何を噛んでいるのですか？
システムが32ビットであることを[忘れました]と読みました。したがって、私は同意します。rsyncは直接責任を負わない可能性があり（malloc/mmapを介して-glibcは匿名/プライベートmmapを介して大きなmallocを実装します）、rsyncのmmapページ違反は偶然にOOMをトリガーするだけです。次に、OOMはrsyncによって消費された合計メモリを直接的および間接的に計算し（FSキャッシュ、ソケットバッファーなど）、それが主要な候補であると決定します。そのため、合計メモリ使用量を監視すると役立つ場合があります。私はそれがファイル転送と同じ速度で忍び寄ると思います。当然、そうすべきではありません。
/ procまたは/ proc/rsync_pidで、Perlまたはpythonスクリプトを高速ループで監視することができるいくつかのこと-worldイベント]以下のすべてを数百回/秒で監視できます。rsyncよりも高い優先度でこれを実行できるので、RAMに保持され、実行して、物事を監視できます。クラッシュの直前、できればOOMの実行中に、OOMがおかしくなっている理由を確認できます。
/ proc/meminfo-「影響のあるポイント」でのスワップ使用量をより詳細に取得する実際には、RAMが使用されている合計量の最終的な数を取得することは、より便利かもしれません。topはこれを提供しますが、直前の宇宙の状態を表示するには十分に速くない場合があります。 「ビッグバン」（たとえば、最後の10ミリ秒）
/ proc/rsync_pid/fdディレクトリ。シンボリックリンクを読み取ると、ターゲットファイルで開かれているfdを識別できます（例：/ proc/rsync_pid/fd/5-> target_fileのreadlink）。これはおそらく、fd番号を取得するために1回だけ実行する必要があります[固定したままにする必要があります]
Fd番号がわかっているので、/ proc/rsync_pid/fdinfo/fdを見てください。これは次のようなテキストファイルです。
pos：<file_position> flags：blah_blah mnt_id：blah_blah
「最後のファイル位置」が役立つ可能性があるため、「pos」値の監視は役立ちます。さまざまなサイズとmem =オプションを使用して複数のテストを行う場合、最後のファイルの位置はこれらのどれかを追跡しますか[および方法]通常の容疑者：ファイルの位置==使用可能なRAM
しかし、最も簡単な方法は、「rsync local_file server：remote_file」で開始し、それが機能することを確認することです。 "ssh server rsync file_a file_b" [50GB file_aを最初に作成する必要があります]を実行すると、同様の（ただしより高速な）結果が得られる場合があります。 file_aを作成する簡単な方法はscp local_system：original_file server：file_aであり、これはそれ自体興味深いかもしれません（たとえば、rsyncがクラッシュしたときにこれは機能しますか？scpは機能するがrsyncが失敗した場合、これはrsyncを指します。scpが失敗した場合、これはポイントしますNIC driver）のようなものに変更します。sshrsyncを実行すると、NICが式から外れるため、役立つ場合があります。システムが、それから何かが本当に間違っています。成功した場合は、[前述したように]オプションを1つずつ追加し直します。
私は要領を踏みにじることを嫌いますが、swap-to-fileを介してスワップを追加すると、クラッシュの動作が変更/遅延され、診断ツールとして役立つ場合があります。スワップに16GBを追加すると、クラッシュ（メモリ使用量またはターゲットファイルの位置で測定）が32GBから46GBに遅延する場合、それは何かを意味します。
それは特定のプロセスではないかもしれませんが、メモリを消費している誤ったカーネルドライバーです。カーネルの内部vmallocは、スタッフを割り当て、スワップアウトできます。 IIRC、それはすべての状況下でのアドレス指定に拘束されません。
明らかに、OOMは混乱/パニックになっています。つまり、rsyncは強制終了されますが、メモリがタイムリーに解放されていないため、他の犠牲者を探しています。それらのいくつかは、おそらくシステムの操作に重要です。
malloc/mmapは別にして、これはフラッシュされていないFSキャッシュに長い時間がかかる（たとえば、30GBのフラッシュされていないデータで、300 MB /秒のディスクレートを想定すると、100秒かかる可能性がある）その速度でも、OOMは焦りすぎるかもしれません。または、OOM kill rsyncが起動しないFS十分に速くフラッシュする[またはまったく]]またはFSフラッシュは十分に高速に行われますが、ページの「遅延」リリースがフリープールに戻ります。制御するために設定できるいくつかの/ procオプションがありますFS cache振る舞い[私は彼らが何であるか思い出せない]。
Mem = 4Gまたは他の小さな数字で起動してみてください。これにより、FSキャッシュが削減され、フラッシュ時間が短縮されて、OOMが他の強制終了対象を探すことがなくなります（たとえば、フラッシュ時間が100秒から1秒未満に短縮されます）。 32ビットシステムなどで物理RAMが4GBを超えると処理できないOOMバグのマスクを解除します。
また、重要なポイント：非rootとして実行します。ルートユーザーはリソースを噛むことを決して期待されていないため、より寛容な制限が与えられます（たとえば、メモリの99％と非ルートユーザーの95％）。これは、なぜOOMがこのような状態にあるのかを説明している可能性があります。また、これによりOOMなどが得られます。 al。メモリを再利用するためのヘッドルームが増えました。
どう？ ClamAVを使用していて、オンアクセススキャンが有効になっていて、アンチウイルスエンジンが開いているファイルのウイルスをスキャンしようとしているようです他のプロセスによって開かれたすべてのファイルのコンテンツ全体をメモリにロードすることにより。
セキュリティ状況とこの転送の必要性に応じて、転送を実行する間、ClamAVオンアクセススキャンを無効にすることを評価する必要があります。