☰

每个进程的核心限制，以缓解系统/内核 CPU 使用率过高

tag-icon • tag-icon linux cpu-usage multi-core
每个进程的核心限制，以缓解系统/内核 CPU 使用率过高

我的理解是，高内核/系统 CPU 使用率是网络和磁盘 IO 或 RAM 吞吐量问题的症状。 #516139。但是，我怀疑在下面的情况下，过度分配线程会给内核（通过调度）带来太多的工作，从而影响实际的用户级进程计算。

我们已经在 R 中并行构建了许多模型，但没有意识到每个模型构建函数都具有 openMP 功能，并且默认将其自身分发（分发到所有可用核心！？）。

  1. 在没有可疑/编写不佳的代码进行推理的情况下，有没有办法判断 sy 使用率高是因为线程分配？
  2. 一旦运行，有没有办法设置例如ulimit单个进程或任何其他除了终止顶层进程之外的补救措施？

htop 截图

统计工具

Linux 4.9.0-4-amd64 (rhea.wpic.upmc.edu)        01/19/2018      _x86_64_        (72 CPU)

11:27:42 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
11:27:42 AM  all   13.28    0.00   30.09    0.17    0.00    0.03    0.00    0.00    0.00   56.42

iostat

Linux 4.9.0-4-amd64 (rhea.wpic.upmc.edu)        01/19/2018      _x86_64_        (72 CPU)
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          13.28    0.00   30.16    0.17    0.00   56.40

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               5.90       182.64       532.33  175621086  511871712
sdb               4.26        10.68      1014.29   10268992  975304572
sdc               0.82        14.68        20.13   14111683   19354860
sdd               0.00         0.02         0.00      18100          0

猫/ proc / self / mountstats

device skynet:/Volumes/Phillips/ mounted on /Volumes/Phillips with fstype nfs statvers=1.1
        opts:   rw,vers=3,rsize=65536,wsize=65536,namlen=255,acregmin=3,acregmax=60,acdirmin=30,acdirmax=60,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=xxxxxxx,mountvers=3,mountport=748,mountproto=udp,local_lock=none
        age:    960031
        caps:   caps=0x3fc7,wtmult=512,dtsize=32768,bsize=0,namlen=255
        sec:    flavor=1,pseudoflavor=1
        events: 22290816 111452957 1493156 351729 8727855 16583649 130526167 54024016 266 1063322 0 8965212 14276120 4723 2406702 480455 238 1439836 0 615 53950807 7 0 0 0 0 0 
        bytes:  1584954051456 218684872379 0 0 742185394287 219176285117 181264042 53636171 
        RPC iostats version: 1.0  p/v: 100003/3 (nfs)
        xprt:   tcp 1017 1 75 0 0 66894351 66887373 6904 256266328938 0 802 1887233163 595159288
        per-op statistics
                NULL: 0 0 0 0 0 0 0 0
             GETATTR: 22290802 22290914 0 3154213512 2496568872 18446744073371231314 88830744 118185897
             SETATTR: 5616 5618 0 942564 808704 122600 893047 1025591
              LOOKUP: 16586987 16586993 0 3230313244 3836903464 18446744073421412542 29327650 31652035
              ACCESS: 5630423 5630439 0 810455208 675650520 2233531 21149691 23526686
            READLINK: 60834 60834 0 9245324 9267896 269 957051 958788
                READ: 11461667 11461844 0 1688228580 743652637248 160174235 1277881121 1438304121
               WRITE: 4246754 4259238 220 220002658844 679480640 30785630990 5061286597 35853150454
              CREATE: 7464 7467 0 1485604 1970496 801177 746707 1551420
               MKDIR: 83 83 0 16296 21912 1749 1164 2986
             SYMLINK: 30 30 0 8504 7920 0 16 34
               MKNOD: 0 0 0 0 0 0 0 0
              REMOVE: 9276 9278 0 1742408 1335744 143237 439704 583661
               RMDIR: 78 78 0 13080 11232 0 68 78
              RENAME: 908 908 0 214236 236080 2906 27182 30095
                LINK: 0 0 0 0 0 0 0 0
             READDIR: 204340 204340 0 32694564 6032970656 42323 1722666 1771971
         READDIRPLUS: 6343408 6343410 0 1040350176 31022488528 1465418 136921691 138608729
              FSSTAT: 2834 2834 0 388096 476112 67600 532404 600234
              FSINFO: 2 2 0 224 328 0 0 0
            PATHCONF: 1 1 0 112 140 0 0 0
              COMMIT: 35880 35964 1 5029968 5453760 41064204 31974116 73123499

编辑：

这种情况的存在是因为 openblas 默认为并行计算。参见

答案1

乍一看，对于 72 个 CPU 核心的机器来说，400 的平均负载似乎有点高。准备运行的任务比核心多通常意味着其中一些任务正在等待。

系统时间可以是多种因素。对于像您这样的计算密集型工作负载，30% 的系统 CPU 似乎很高。

要确切了解正在发生的事情，你可以对整个系统的调用图进行采样，然后将它们制作成一种整洁的可视化图形，称为火焰图。

# Looks like you have a Debian install
# Install debug symbols for the kernel and Linux perf
apt-get install linux-image-amd64-dbg linux-tools
git clone https://github.com/brendangregg/FlameGraph  # or download it from github
cd FlameGraph
perf record -F 99 -a -g -- sleep 60
perf script | ./stackcollapse-perf.pl > out.perf-folded
./flamegraph.pl out.perf-folded > perf-kernel.svg

图表中最宽的平台应该表示花费时间最多的地方。

如何处理这个问题取决于你发现的情况。我不熟悉 openMP，但如果它确实已经并行运行，请限制并发作业的数量。不要让它们相互争夺资源。

任务的 CPU 使用率达到 800% 确实意味着您有多线程任务，可能使用 8 个内核。如果这是典型情况，运行其中的 8 个或 9 个将保持 72 个内核的使用率。有多种方法可以并行运行脚本，直到达到某个负载水平，特别是 GNU 并行。

相关内容