Rsyncは単一の50 GBファイルでLinux OOMキラーをトリガーしました

server_Aに単一の50 GBファイルがあり、それを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 = 0

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のドキュメントので、あなたrequstはのための旗を持っているGFP_ZERO、GFP_REPEAT、GFP_FS、GFP_IOおよびGFP_WAITので、特に好き嫌いはないという。

どうしたのZONE_NORMAL？いくつかの一般的な統計は、OOM出力でさらに見つけることができます。

[カーネル] [1772321.850770]通常の空き：8056kB最小：8048kB低：10060kB高：12072kB active_anon：0kB inactive_anon：0kB active_file：248kB inactive_file：388kB unevictable：0kB isolated（anon）：0kB isolated（file）：0kB present：890008kB

ここで注目に値するのは、freeからわずか8Kで、minその下にあることlowです。これは、ホストのメモリマネージャが多少苦しんでいることを意味し、kswapdは下のグラフの黄色の段階にあるように既にページをスワップアウトしている必要があります。

ゾーンのメモリフラグメンテーションに関する詳細情報は、次のとおりです。

[カーネル] [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もが呼び出された理由に関して明確な理由を与えません

これらはすべて奇妙に思えますが、少なくともジョン・オゴーマンの優れた「Understanding the Linux Virtual Memory Manager」本のセクション2.5に記載されているものに関連しているはずです。

カーネル（ZONE_NORMAL）が使用できるアドレススペースのサイズは制限されているため、カーネルはハイメモリの概念をサポートしています。[...] 1GiBと4GiBの範囲のメモリにアクセスするために、カーネルはkmap（）を使用してページを一時的に高メモリからZONE_NORMALにマップします。[...]

つまり、1GiBのメモリを記述するには、約11MiBのカーネルメモリが必要です。したがって、16GiBでは、176MiBのメモリが消費され、ZONE_NORMALに大きな負荷がかかります。これは、ZONE_NORMALを使用する他の構造が考慮されるまで、それほど悪くは聞こえません。ページテーブルエントリ（PTE）などの非常に小さな構造でも、最悪の場合は約16MiBが必要です。これにより、16GiBは、x86で使用可能な物理メモリLinuxの実用的な制限について認識します。

（強調は私のものです）

3.2には2.6よりも多くのメモリ管理の進歩があるため、これは明確な答えではありませんが、最初に追求する非常に強力なヒントです。mem=カーネルパラメーターを使用するか、DIMMの半分をサーバーから取り出すことにより、ホストの使用可能なメモリを最大16Gに減らします。

最終的に、64ビットカーネルを使用します。

おい、2015年です。

いくつかのこと...

私のスワップスペースの経験則では、物理RAMの少なくとも2倍の容量が必要です。これにより、ページ/スワップデーモンはメモリを効率的に再編成できます。

Server_Bには32GBのRAMがあるため、64GBのスワップ用に構成してみてください。IMO、スワップ領域2GBのは、あなたのサーバがありました方法、特に、サーバ用に、低すぎます。

スワップパーティションに追加できる追加のパーティションがない場合は、ファイルを作成し、それをスワップパーティションとしてマウントすることでテストできます[低速になります]。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がインラムファイルイメージを保持するオプションが本当に必要な場合は、追加のスワップスペースが必要になり、それに応じて最大ファイルサイズが制限されます。

さらにいくつかの[更新]：

（1）カーネルスタックトレースバックは、rsyncがmmap領域でページフォールトしたことを示しています。おそらくファイルをmmapしています。mmapは、ファイルが閉じられるまでディスクにフラッシュすることを保証しません[読み取り/書き込みとは異なり] FSブロックキャッシュにすぐに移動します[フラッシュされる場所]

（2）転送サイズがRAMのサイズに達すると、カーネルクラッシュ/パニックが発生します。明らかに、rsyncは、mallocまたはmmapを介して、多くの非fscacheメモリを取得しています。ここでも、指定したオプションを使用して、rsyncは50GBのメモリを割り当てて50GBファイルを転送します。

（3）24GBファイルを転送します。それはおそらく動作します。次に、mem = 16Gでカーネルを起動し、24GBファイルテストを再度実行します。32GBではなく16GBで爆発します。これにより、rsyncが実際にメモリを必要とすることが確認されます。

（4）スワップの追加はばかげていると言う前に、[swap-to-fileメソッドを介して]いくつか追加してみてください。これは、スワップが必要ではないという学術的な議論よりも、実行とテストがはるかに簡単です。それが解決策でなくても、そこから何かを学ぶことができます。mem = 16Gテストはパニック/クラッシュなしで成功すると確信します。

（5）rsync がスワップにヒットしている可能性がありますが、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を実行します。次に、両方を試してください。rsyncが巨大なmmapを実行するオプションを見つけます。次に、それなしで生活できるかどうかを判断します。--inplaceが原因である場合、十分なディスク容量があるため、これは簡単です。オプションが必要な場合は、rsyncが行うmalloc / mmapに対応するためのスワップスペースを取得する必要があります。

2回目の更新：

上記のmem =およびより小さいファイルのテストを実行してください。

中心的な質問：なぜrsyncはOOMによって殺されるのですか？咀memory記憶とは誰ですか？

私は、システムが32ビットであることを読みました（忘れていました）。したがって、rsyncは直接責任を負わないかもしれません（malloc / mmapを介して--glibcは匿名/プライベートmmapsを介して大きなmallocを実装します）、rsyncのmmapページフォルトは偶然OOMをトリガーするだけです。次に、OOMはrsyncが直接および間接的に消費する合計メモリ[FSキャッシュ、ソケットバッファなど]を計算し、それが主要な候補であると判断します。そのため、合計メモリ使用量を監視することが役立つ場合があります。ファイル転送と同じ速度で忍び寄ると思います。当然、そうすべきではありません。

/ procまたは/ proc / rsync_pidで高速ループ内のperlまたはpythonスクリプトを介して監視できるもの[bashスクリプトは、おそらく世界の終わりのイベントに対して十分に高速ではない]を監視できます。次の数百回/秒。これをrsyncよりも高い優先度で実行すると、RAM内に自身を保持して実行するので、クラッシュの直前に、できればOOM中に物事を監視して、OOMがおかしくなる理由を確認できます。

/ proc / meminfo-「影響のポイント」でのスワップの使用についてより詳細な情報を取得します。実際には、合計RAM使用量の最終的な数値を取得する方が便利な場合があります。topはこれを提供しますが、「ビッグバン」の直前（たとえば、最後の10ミリ秒）に宇宙の状態を表示するのに十分な速度ではない場合があります

/ proc / rsync_pid / fdディレクトリ。シンボリックリンクを読み取ると、ターゲットファイルで開かれているfdを識別できます（たとえば、/ proc / rsync_pid / fd / 5のreadlink-> target_file）。これはおそらく、fd番号を取得するために1回だけ行う必要があります[固定されたままにする必要があります]

fd番号がわかっている場合は、/ proc / rsync_pid / fdinfo / fdをご覧ください。次のようなテキストファイルです。

pos：<ファイル位置>
フラグ：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がクラッシュしたときに動作しますか？ NICドライバのような他のものに）。ssh rsyncを実行すると、式からNICが削除されるため、役に立つ場合があります。それがシステムに影響を与える場合、何かが本当に間違っています。それが成功した場合、[前述したように]オプションを1つずつ追加し直します。

私はその点に注意を払うことを嫌いますが、swap-to-fileを介していくつかのスワップを追加すると、クラッシュの動作が変更/遅延される可能性があり、診断ツールとして役立つ場合があります。たとえば16GBのスワップを追加すると、クラッシュ（メモリ使用量またはターゲットファイルの位置で測定）が32GBから46GBに遅延する場合、それは何かを意味します。

特定のプロセスではなく、メモリを噛んでいる誤ったカーネルドライバーの可能性があります。カーネルの内部vmallocが割り当てを行い、スワップアウトできます。IIRC、すべての状況下でアドレス可能性に拘束されるわけではありません。

明らかに、OOMは混乱/パニック状態になっています。つまり、rsyncを強制終了しますが、メモリがタイムリーに解放されることはなく、他の犠牲者を探します。それらのいくつかは、おそらくシステム操作にとって重要です。

malloc / mmapは別として、これは長時間かかるフラッシュされていないFSキャッシュによって引き起こされる可能性があります（たとえば、300 GB /秒のディスクレートを想定すると、フラッシュするのに100秒かかる場合がある30 GBのフラッシュされていないデータ）。その速度であっても、OOMは短すぎます。または、rsyncを強制終了するOOMは、FSフラッシュを十分な速さで（またはまったく）開始しません。または、FSフラッシュは十分高速に行われますが、ページの「遅延」リリースがあり、フリープールに戻ります。FSキャッシュの動作を制御するために設定できる/ procオプションがいくつかあります[それらが何であるか思い出せません]。

mem = 4Gまたは他の小さな数値で起動してみてください。これにより、FSキャッシュが削減され、フラッシュ時間が短縮され、OOMが他のキル対象を探すことがなくなります（たとえば、フラッシュ時間が100秒から1秒未満に短縮されます）。また、32ビットシステムなどで4 GBを超える物理RAMを処理できないOOMバグを明らかにする場合もあります。

また、重要なポイント：非ルートとして実行します。ルートユーザーはリソースを噛むことを決して期待されないので、より寛容な制限が与えられます（例：メモリの99％対非ルートユーザーの95％）。これは、なぜOOMがそのような状態にあるのかを説明するかもしれません。また、これによりOOM et。等 メモリーを回収するという仕事をするためのより多くの余裕がある。

clamd？ClamAVを使用していて、オンアクセススキャンが有効になっているようです。アンチウイルスエンジンは、他のプロセスによって開かれたすべてのファイルのコンテンツ全体をメモリにロードすることにより、開いているファイルをスキャンします。

セキュリティの状態とこの転送の必要性に応じて、転送の実行中にClamAVオンアクセススキャンの無効化を評価する必要があります。