服务器 Gind.cn
  1. 服务器 Gind.cn
  3. Rsync在一个50 GB的文件上触发了Linux OOM杀手
Intereting Posts
如何在云端设置子域名 通过Cloudflare为具有自定义域名的GitHub页面网站提供服务 启用.htacess中的ReWriteLog后，我无法打开我的网站。 在HTML文件中运行ColdFusion命令？ Windows CA颁发证书来authenticationSSH到Linux服务器 App-V进程在服务器任务pipe理器中 Fedora 8升级PHP> 5.2.4 sbsnetworking上的XP客户端对特定网站的访问权限有限或无法访问，赢了7 Exchange 2010 VMDK磁盘devise 保存文件后，EFSencryption的Office文档会丢失额外的用户 使用Hyper-V，我可以在dynamic扩展的VHD上安装客户操作系统吗？ 基准的Linux服务器？ 串口到以太网电缆：如何连接到设备 批量电子邮件validation 我的服务器托pipe的一些网站不能从一些地方到达

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时，由于远程端closures了连接，传输将中止。

Server_B现在已经退出了networking。 我们要求数据中心重新启动它。 当我查看崩溃之前的内核日志时，发现它使用了0字节的交换，进程列表使用的内存非常小（rsync进程被列为使用600 KB的RAM），但是oom_killer是而且日志里的最后一件事就是杀死metalog的内核读者进程。

这是内核3.2.59,32位（因此无论如何都不能映射超过4GB的进程）。

就好像Linux比caching更优先于长期运行的守护进程。 是什么赋予了？？ 我怎样才能阻止它再次发生？

这是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: GC 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”输出： 

 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虚拟机参数： 

 # 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杀手日志时，重要的是看看触发它的原因。 你的日志的第一行给了我们一些线索：

    [kernel] [1772321.850644] clamd调用了oom-killer： gfp_mask = 0x84d0，order = 0

    order=0告诉我们有多less内存正在被请求。 内核的内存pipe理只能pipe理2个幂的页码，所以clamd要求2 0页的内存或者4KB。

    GFP_MASK的最低两位（获得空闲页面掩码）构成了所谓的区域掩码， 告诉分配器从哪个区域获得内存 ： 

     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

    内存区域是主要为兼容性原因而创build的概念。 在一个简化的视图中，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

    在你的情况下，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输出中find：

    [kernel] [1772321.850770]正常空闲：8056kB最低：8048kB低：10060kB高：12072kB active_anon：0kB inactive_anon：0kB active_file：248kB inactive_file：388kB unevicetable：0kB隔离（anon）：0kB隔离（文件）：0kB当前：890008kB

    这里值得注意的是， free min只有8K， min 。 这意味着你的主机的内存pipe理器有点困难，kswapd应该已经换出了页面，因为它在下图的黄色阶段： Linux内存管理器图

    有关该区域的内存碎片的更多信息在此处给出：

    [kernel] [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_HIMEM获取内存，而非特权内存分配通常是从ZONE_HIMEM
    • 在这个阶段，内存pipe理器应该能够处理所请求的4K页面，尽pipe在ZONE_NORMAL似乎有很大的内存压力
    • 根据kswapd的规则，系统应该事先看过一些调页活动，但即使在ZONE_NORMAL内存压力下也没有任何被换出，没有明显的原因
    • 以上都没有给出明确的理由，为什么oom-killer被引用

    所有这些看起来都很奇怪，但至less与John O'Gorman出色的“了解Linux虚拟内存pipe理器”一书第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内存pipe理方面有很多进步，所以这不是一个确定的答案，而是一个我首先追求的真正强大的提示。 通过使用mem= kernel参数或将一半DIMM从服务器中取出，可将主机的可用内存降至16G以下。

    最终， 使用64位内核 。

    伙计，这是2015年。

    一些东西 …

    我的交换空间的经验法则是至less有2倍的物理内存。 这使得页面/交换守护进程能够有效地重组内存。

    Server_B有32GB的RAM，所以请尝试configuration64GB交换。 国际海事组织，2GB的交换空间你的服务器有太低，特别是对于服务器。

    如果你没有额外的分区，你可以做一个交换分区，你可以通过创build一个文件并将其挂载为一个交换分区来进行testing[速度很慢]。 请参阅https://www.maketecheasier.com/swap-partitions-on-linux/

    由于server_B有足够的磁盘空间，因此可能不需要使用-inplace，因为它可能是导致rsync使用32GB的原因。 – 只有在文件系统空间不足的情况下（或者你不是）或者有一些特殊的性能需求，这才是真正有用的。

    我的猜测是，rsync将希望使用50GB的RAM（文件大小）与您当前的选项。 通常，rsync不需要太多的内存来完成它的工作，所以你的一个或多个选项可能是问题。 我经常传输200GB文件没有问题。

    使用无选项进行一些testing运行。 用较小的文件做这个，例如10GB – 这应该可以防止内核恐慌，但仍然允许您监视导致问题的行为。 监视rsync的内存使用情况。

    逐渐地，逐个添加选项，看看哪个选项[或多个选项的组合]导致rsync开始在RAM上清除（例如，当传输正在进行时，rsync的ram使用率与传输的文件数据量成比例增长，等等。）。

    如果您确实需要使rsync保留一些内部文件映像的选项，则需要额外的交换空间，并且相应地限制您的最大文件大小。

    更多的东西[更新]：

    （1）内核堆栈回溯显示rsync是mmap区域的页面错误。 这可能是压缩文件。 mmap不保证它会刷新到磁盘， 直到文件被closures[不像读/写]，它立即进入FS块caching[它将被刷新]

    （2）当传输大小达到RAM的大小时发生内核崩溃/恐慌。 很明显，rsync通过malloc或mmap抓取那些非fscache内存。 再一次，用你指定的选项，rsync将分配50GB的内存来传输一个50GB的文件。

    （3）传输24GB文件。 这可能会奏效。 然后，用mem = 16G启动内核，再次执行24GB文件testing。 它会吹到16GB而不是32GB。 这将确认rsync确实需要内存。

    （4）在添加swap之前，请尝试添加一些[通过swap-to-file方法]。 这比做所有关于如何不需要交换的学术论证要容易得多。 即使这不是解决办法，你也可以从中学到一些东西。 我敢打赌，mem = 16Gtesting会成功，没有恐慌/崩溃。

    （5）有可能是rsync正在进行交换，但在OOM踢入并杀死rsync之前，发生的事情太快了。 在rsync达到32GB的时候，其他进程已经被强制掉了，特别是在闲置的时候。 也许，“自由”和“顶”的组合会给你一个更好的图片。

    （6）在rsync被杀之后，需要花费时间将mmap刷新到FS。 OOM速度不够快，并开始杀死其他东西[有些显然是关键任务]。 也就是说，mmap flush和OOM正在竞速。 或者，OOM有一个bug。 否则，不会有一个崩溃。

    （7）根据我的经验，一旦系统“撞墙”，Linux需要很长时间才能完全恢复。 而且，有时它从来没有真正恢复正常，清除它的唯一方法是重新启动。 例如，我有12GB的RAM。 当我运行一个使用40GB内存的作业（我有120GB的交换空间来容纳大型作业），然后杀掉它，系统恢复到正常的响应时间大约需要10分钟[光盘始终​​处于稳定状态] 。

    （8）运行没有选项的rsync。 这将工作。 获取一个基准的例子来工作。 然后加回来 – 重新testing。 然后做–append – validation。 然后，尝试两个。 找出哪个选项可以让rsync进行巨大的mmap。 然后决定是否可以没有它的生活。 如果 – inplace是罪魁祸首，那么这是一个不容易的事情，因为你有足够的磁盘空间。 如果你必须有选项，你必须得到交换空间来容纳rsync将要做的malloc / mmap。

    第二次更新：

    请从上面进行mem =和更小的文件testing。

    核心问题：为什么rsync被OOM杀死？ 谁/什么是咀嚼记忆？

    我读了[但忘记]有关系统是32位。 所以，我同意，rsync可能不是直接负责（通过malloc / mmap – glibc通过匿名/私有mmaps实现大型mallocs），rsync的mmap页面错误恰巧触发了OOM。 然后，OOM直接或间接计算rsync消耗的总内存（FScaching，套接字缓冲区等），并决定它是主要的候选项。 所以，监视内存使用总量可能会有所帮助。 我怀疑它和文件传输的速度一样。 显然，它不应该。

    有些东西可以在/ proc或/ proc / rsync_pid中通过perl或python脚本以快速循环的方式监视[bash脚本可能不会足够快到达世界末日事件]，可以监视所有以下几百次/秒。 你可以以比rsync更高的优先级运行它，所以它将自己保存在RAM中并运行，所以你可以在崩溃之前监视一些事情，希望在OOM期间，所以你可以看到为什么OOM疯了：

    / proc / meminfo – 在“影响点”的交换使用上获得更多的优质谷物。 实际上，得到总共使用多lessRAM的最终数字可能会更有用。 虽然top提供了这一点，但在“大爆炸”之前（例如最近10毫秒），可能不足以显示宇宙的状态，

    / proc / rsync_pid / fd目录。 读取符号链接将允许您确定在目标文件上打开哪个fd（例如/ proc / rsync_pid / fd / 5 – > target_file的readlink）。 这可能只需要做一次就可以得到fd号[它应该保持不变]

    知道fd号码，看看/ proc / rsync_pid / fdinfo / fd。 这是一个文本文件，看起来像： 

     pos：<file_position>
标志：blah_blah
 mnt_id：blah_blah

    监视“pos”值可能是有用的，因为“最后的文件位置”可能是有用的。 如果你用不同的尺寸和内存=选项进行多个testing，最后一个文件位置是否跟踪这些[以及如何]？ 通常的嫌疑犯：文件位置==可用的RAM

    但是，最简单的方法是从“rsync local_file server：remote_file”开始并validation是否可行。 您可以通过执行“ssh服务器rsync file_a file_b”获得类似的（但更快的）结果[您需要先创build一个50GB的file_a]。 创buildfile_a的一个简单的方法是scp local_system：original_file server：file_a，这可能对自己很有意思（例如，当rsync崩溃时它是否工作？如果scp工作，但rsync失败，则指向rsync。如果scp失败，到其他东西像网卡驱动程序）。 做rsync的rsync也使得NIC不在等式中，这可能是有帮助的。 如果这个系统软化，那么事情就是错的。 如果成功的话，（正如我所提到的）开始逐个添加选项。

    我讨厌这点，但通过交换文件添加一些交换可能会改变/延迟崩溃的行为，并可能有用的诊断工具。 如果添加交换，比如说16GB的交换，将内存使用量或目标文件位置的testing延迟从32GB延迟到46GB，那么就会说一些话。

    它可能不是一个特定的进程，而是一个咀嚼记忆的错误的内核驱动程序。 内核的内部vmalloc分配的东西，它可以被换出。 IIRC，在任何情况下都不受限制。

    显然，OOM变得困惑/恐慌。 也就是说，它杀死rsync，但没有及时地看到内存释放，并寻找其他受害者。 其中一些可能对系统运行至关重要。

    抛开malloc / mmap，这可能是由于需要很长时间的未刷新的FScaching（例如30GB的未刷新数据，假设磁盘速率为300 MB /秒，可能需要100秒才能刷新）。 即使这样，OOM也可能太不耐烦了。 或者，OOM查杀rsync并不能以足够快的速度启动FS刷新[或者根本就不行]。 或者FS刷新发生得足够快，但是它有一个“懒惰”的版本释放回免费池。 有一些/ proc选项可以设置来控制FScaching行为[我不记得他们是什么]。

    尝试用mem = 4G或其他一些小号码启动。 这可能会减lessFScaching，并缩短其刷新时间，以防止OOM寻找其他要杀的东西（例如，刷新时间从100秒减less到<1秒）。 它也可能揭露一个OOM的bug，在32位系统或其他类似的系统上无法处理大于4GB的物理内存。

    另外，重要的一点是：以非root用户身份运行。 根用户永远不会被咀嚼资源，所以他们被赋予更多的宽容限制（例如，99％的内存比非root用户的95％）。 这可以解释为什么OOM处于这样的状态。 另外，这给了OOM等。 人。 做更多的空间来回收记忆。

    clamd的？ 这听起来像是在使用ClamAV，并且在反病毒引擎试图扫描已打开文件的病毒时，启用了读写扫描， 通过将任何其他进程打开的每个文件的全部内容加载到内存中 。

    根据您的安全状况和此次传输的必要性，您应该在执行传输时评估禁用的ClamAV读写扫描。