Question

我创建一个后台线程B，并在B的func中创建

void func()
{
  system('gzip -f text-file'); // size of text-file is 100M
  xxx
}

我发现有时候一个cpu（我的服务器有多个cpu核心）的sys是100％。 strace进度，我发现克隆系统调用消耗超过3秒，这几乎是gzip的执行时间。

**17:46:04.545159** clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0x418dba38) = 39169
**17:46:07.432385** wait4(39169, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 39169

所以我的问题是， 1.系统（＆＃39; gzip -f text-file＆＃39;）导致100％cpu sys？ 2.根本原因是什么

Answer 1

根据{{3}}

，没有sys_clone的

CLONE_MM执行从父进程到子进程的虚拟内存映射的完整副本

343      Allocate a new mm
348-350  Copy the parent mm and initialise the process specific mm fields with init_mm()
352-353  Initialise the MMU context for architectures that do not automatically manage their MMU
355-357  Call dup_mmap() which is responsible for copying all the VMAs regions in use by the parent process

在2000 mmaps中处理60GB的进程的VMA数量很高，dup_mm可能需要很长时间。

你想做一些小的外部运行（gzip），但是fork不是这种大型程序的最佳解决方案。所有vma副本都将通过exec：https://www.kernel.org/doc/gorman/html/understand/understand021.html

进行删除

例如，fork / exec组合创建瞬态虚拟内存使用尖刺，几乎立即消失而没有破坏复制分叉页表中大多数页面的写入状态。从而如果一个大型进程分离出一个较小的进程，巨大的物理内存要求可能发生（就过度使用而言），但绝不会兑现。

所以，你可以更好地：

检查vfork + exec对（又名posix_spawn），这将暂停你的巨大进程一小段时间，直到孩子做exec或`退出）
在完成所有60GB的mmaps之前创建单独的帮助程序进程;使用管道/插座/ ipc /任何东西与它通信。帮手程序很小，大部分时间都会在ipc上睡觉。当您需要gzip时，您只需要帮助程序运行它。
或将压缩集成到您的程序中。 Gzip和bzip2都有很好的库，zlib和libbz2，并且还有一些包装器。

是系统（const char *命令）导致cpu sys 100％

1 个答案: