'real','user'和'sys'在time(1)的输出中意味着什么?

1622 unix time benchmarking

$ time foo
real        0m0.003s
user        0m0.000s
sys         0m0.004s
$

"真实","用户"和"系统"在时间输出中意味着什么?

在对我的应用进行基准测试时哪一个有意义?

ConcernedOfT.. 1930

Real,User和Sys处理时间统计信息

其中一件事与另一件事情不同.实际是指实际经过的时间; User和Sys指的是仅由进程使用的CPU时间.

  • 真实是挂钟时间 - 从通话开始到结束的时间.这是所有经过的时间,包括其他进程使用的时间片和进程花费的时间(例如,如果它等待I/O完成).

  • 用户是进程用户模式代码(内核外)花费的CPU时间.这只是执行过程时使用的实际CPU时间.流程花费的其他流程和时间不计入此数字.

  • Sys是进程内核中花费的CPU时间.这意味着执行内核中系统调用所花费的CPU时间,而不是仍在用户空间中运行的库代码.与'user'一样,这只是进程使用的CPU时间.有关内核模式(也称为"管理程序"模式)和系统调用机制的简要说明,请参见下文.

User+Sys将告诉您进程使用的实际CPU时间.请注意,这是跨所有CPU的,因此如果进程有多个线程(并且此进程在具有多个处理器的计算机上运行),则可能超过报告的挂钟时间Real(通常会发生).请注意,在输出中,这些数字包括所有子进程(及其后代)的时间UserSys时间,以及它们是否可以被收集,例如通过wait(2)或者waitpid(2),尽管底层系统调用会分别返回进程及其子进程的统计信息.

报告统计数据的起源 time (1)

报告的统计数据time来自各种系统调用."用户"和"系统"来自wait (2)(POSIX)或times (2)(POSIX),具体取决于特定系统."真实"是根据从gettimeofday (2)通话中收集的开始和结束时间计算得出的.根据系统的版本,还可以收集各种其他统计信息,例如上下文切换的数量time.

在多处理器计算机上,多线程进程或分叉子进程的进程可能会比CPU总时间小 - 因为不同的线程或进程可能并行运行.此外,报告的时间统计来自不同的来源,因此对于非常短的运行任务记录的时间可能受到舍入误差的影响,如原始海报给出的示例所示.

关于内核与用户模式的简要介绍

在Unix或任何受保护的内存操作系统上,"内核"或"超级用户"模式是指CPU可以操作的特权模式.某些可能影响安全性或稳定性的特权操作只能在CPU运行时完成这种模式; 这些操作不适用于应用程序代码.这种动作的一个例子可能是操纵MMU以获得对另一个进程的地址空间的访问.通常,用户模式代码不能这样做(有充分的理由),尽管它可以从内核请求共享内存,这可能由多个进程读取或写入.在这种情况下,通过安全机制从内核显式请求共享内存,并且两个进程必须显式附加到它才能使用它.

特权模式通常称为"内核"模式,因为内核由在此模式下运行的CPU执行.为了切换到内核模式,您必须发出一个特定的指令(通常称为陷阱),它将CPU切换到以内核模式运行,并从跳转表中保存的特定位置运行代码. 出于安全原因,您无法切换到内核模式并执行任意代码 - 陷阱通过无法写入的地址表进行管理,除非CPU以管理员模式运行.使用显式陷阱编号进行陷阱,并在跳转表中查找地址; 内核具有有限数量的受控入口点.

C库中的"系统"调用(特别是手册页第2节中描述的那些)具有用户模式组件,这是您实际从C程序调用的组件.在幕后,他们可以向内核发出一个或多个系统调用来执行特定服务(如I/O),但是他们仍然可以在用户模式下运行代码.如果需要,也可以从任何用户空间代码直接向内核模式发出陷阱,尽管您可能需要编写汇编语言片段来为调用正确设置寄存器.可以在此处找到描述Linux内核提供的系统调用的页面以及设置寄存器的约定.

关于'sys'的更多信息

您的代码无法通过用户模式执行某些操作 - 例如分配内存或访问硬件(HDD,网络等).这些都在内核的监督下,只有它才能做到.您执行的某些操作(如/ malloc或)将调用这些内核函数,然后将计为"sys"时间.不幸的是,它并不像"每次调用malloc都会计入'sys'时间"那么简单.调用将自己进行一些处理(仍然计入'用户'时间),然后在它可能调用内核函数的某个地方(在'sys'时间内计算).从内核调用返回后,'user'中会有更多的时间然后freadfwritemallocmalloc将返回您的代码.至于何时发生切换,以及在内核模式下花费了多少......你不能说.这取决于库的实现.此外,其他看似无辜的功能也可能malloc在后台使用等,这将在'sys'中再次有一些时间.

  • 子进程花费的时间是否计入real/sys? (13认同)
  • User + Sys允许您测量进程的CPU使用情况.您可以使用它来衡量性能.这对于多线程代码特别有用,其中多个CPU内核可能正在进行计算. (3认同)

lensovet.. 262

为了扩展已接受的答案,我只是想提供另一个理由realuser+ sys.

请记住,real表示实际经过的时间,而值usersys值表示CPU执行时间.因此,在多核系统上,user和/或sys时间(以及它们的总和)实际上可能超过实时.例如,在我正在为类运行的Java应用程序中,我得到以下值:

real    1m47.363s
user    2m41.318s
sys     0m4.013s

  • 另一个潜在的问题可能是I/O:如果您的应用程序花费大量时间等待接收文件或流,那么显然实时将大大超过用户/系统时间,因为在等待访问时没有使用CPU时间到文件或类似的东西. (17认同)
  • 我总是想知道这件事.既然我知道我的程序是单线程的,那么用户和实时之间的区别必须是VM开销,对吗? (10认同)
  • 不必要; Solaris机器上的Sun JVM以及Mac OS X上的Apple JVM即使在单线程应用程序中也可以使用多个核心.如果你做一个java进程的样本,你会发现像垃圾收集这样的东西在不同的线程上运行(还有一些其他的东西,我不记得了我的头脑).我不知道你是否真的想要称之为"VM开销". (7认同)
  • 我想现在投票的数量给了你足够的声誉:D.那你怎么看待`real`超过'user`和`sys`总数?诸如线程上下文切换的操作系统开销可能是? (4认同)

varun.. 31

real:从开始到结束运行过程所花费的实际时间,就好像是由带有秒表的人测量的

user:计算期间所有CPU花费的累计时间

sys:所有CPU在系统相关任务(如内存分配)期间所累积的时间.

请注意,有时user + sys可能大于real,因为多个处理器可能并行工作.


Ciro Santill.. 19

最少的可运行POSIX C示例

为了使事情更具体,我想time用一些最小的C测试程序来举例说明一些极端的情况。

可以使用以下命令编译和运行所有程序:

gcc -ggdb3 -o main.out -pthread -std=c99 -pedantic-errors -Wall -Wextra main.c
time ./main.out

并已在Ubuntu 18.10,GCC 8.2.0,glibc 2.28,Linux内核4.18,ThinkPad P51笔记本电脑,Intel Core i7-7820HQ CPU(4核/ 8线程),2个Samsung M471A2K43BB1-CRC RAM(2个16GiB)中进行了测试。

睡觉

非繁忙睡眠不计任何usersysreal

例如,一个睡眠一秒钟的程序:

#define _XOPEN_SOURCE 700
#include <stdlib.h>
#include <unistd.h>

int main(void) {
    sleep(1);
    return EXIT_SUCCESS;
}

GitHub上游

输出类似:

real    0m1.003s
user    0m0.001s
sys     0m0.003s

对于在IO上可用而被阻止的程序也是如此。

例如,以下程序等待用户输入字符并按Enter:

#include <stdio.h>
#include <stdlib.h>

int main(void) {
    printf("%c\n", getchar());
    return EXIT_SUCCESS;
}

GitHub上游

而且,如果您等待大约一秒钟,它会像睡眠示例一样输出:

real    0m1.003s
user    0m0.001s
sys     0m0.003s

因此,time可以帮助您区分CPU和IO绑定的程序:“ CPU绑定”和“ I / O绑定”是什么意思?

多线程

以下示例nitersnthreads线程进行无用的CPU繁重工作的迭代:

#define _XOPEN_SOURCE 700
#include <assert.h>
#include <inttypes.h>
#include <pthread.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

uint64_t niters;

void* my_thread(void *arg) {
    uint64_t *argument, i, result;
    argument = (uint64_t *)arg;
    result = *argument;
    for (i = 0; i < niters; ++i) {
        result = (result * result) - (3 * result) + 1;
    }
    *argument = result;
    return NULL;
}

int main(int argc, char **argv) {
    size_t nthreads;
    pthread_t *threads;
    uint64_t rc, i, *thread_args;

    /* CLI args. */
    if (argc > 1) {
        niters = strtoll(argv[1], NULL, 0);
    } else {
        niters = 1000000000;
    }
    if (argc > 2) {
        nthreads = strtoll(argv[2], NULL, 0);
    } else {
        nthreads = 1;
    }
    threads = malloc(nthreads * sizeof(*threads));
    thread_args = malloc(nthreads * sizeof(*thread_args));

    /* Create all threads */
    for (i = 0; i < nthreads; ++i) {
        thread_args[i] = i;
        rc = pthread_create(
            &threads[i],
            NULL,
            my_thread,
            (void*)&thread_args[i]
        );
        assert(rc == 0);
    }

    /* Wait for all threads to complete */
    for (i = 0; i < nthreads; ++i) {
        rc = pthread_join(threads[i], NULL);
        assert(rc == 0);
        printf("%" PRIu64 " %" PRIu64 "\n", i, thread_args[i]);
    }

    free(threads);
    free(thread_args);
    return EXIT_SUCCESS;
}

GitHub上游+绘图代码

然后,在我的8个超线程CPU上,针对固定的10 ^ 10迭代,将wall,user和sys绘制为线程数的函数:

绘制数据

从图中可以看到:

  • 对于CPU密集型单核应用程序,wall和user大致相同

  • 对于2核,用户大约是2倍墙,这意味着用户时间是在所有线程中计算的。

    用户基本上翻了一番,而墙保持不变。

  • 这最多可以持续8个线程,这与我计算机中超线程的数量相匹配。

    8点之后,墙也开始增加,因为我们没有任何额外的CPU在给定的时间内进行更多工作!

    此时的比率平稳。

系统工作繁重 sendfile

我想承担的最重的sys工作负载是使用sendfile,它在内核空间上执行文件复制操作:以理智,安全,高效的方式复制文件

因此,我认为此内核memcpy将是CPU密集型操作。

首先,我使用以下命令初始化一个较大的10GiB随机文件:

dd if=/dev/urandom of=sendfile.in.tmp bs=1K count=10M

然后运行代码:

#define _GNU_SOURCE
#include <assert.h>
#include <fcntl.h>
#include <stdlib.h>
#include <sys/sendfile.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>

int main(int argc, char **argv) {
    char *source_path, *dest_path;
    int source, dest;
    struct stat stat_source;
    if (argc > 1) {
        source_path = argv[1];
    } else {
        source_path = "sendfile.in.tmp";
    }
    if (argc > 2) {
        dest_path = argv[2];
    } else {
        dest_path = "sendfile.out.tmp";
    }
    source = open(source_path, O_RDONLY);
    assert(source != -1);
    dest = open(dest_path, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
    assert(dest != -1);
    assert(fstat(source, &stat_source) != -1);
    assert(sendfile(dest, source, 0, stat_source.st_size) != -1);
    assert(close(source) != -1);
    assert(close(dest) != -1);
    return EXIT_SUCCESS;
}

GitHub上游

基本上可以提供预期的系统时间:

real    0m2.175s
user    0m0.001s
sys     0m1.476s

我也很好奇,看看是否time可以区分不同进程的系统调用,所以我尝试了:

time ./sendfile.out sendfile.in1.tmp sendfile.out1.tmp &
time ./sendfile.out sendfile.in2.tmp sendfile.out2.tmp &

结果是:

real    0m3.651s
user    0m0.000s
sys     0m1.516s

real    0m4.948s
user    0m0.000s
sys     0m1.562s

两者的系统时间与单个进程的时间大致相同,但是挂墙时间较长,因为进程可能争用磁盘读取访问权限。

因此,似乎实际上是在考虑哪个进程启动了给定的内核工作。

Bash源代码

当您仅time <cmd>在Ubuntu上执行操作时,它可以使用Bash关键字,如下所示:

type time

输出:

time is a shell keyword

因此我们在Bash 4.19源代码中为输出字符串使用grep源代码:

git grep '"user\b'

这导致我们执行execute_cmd.c函数time_command,该函数使用:

  • gettimeofday()getrusage()如果两者都可用
  • times() 除此以外

所有这些都是Linux系统调用POSIX函数

GNU Coreutils源代码

如果我们称其为:

/usr/bin/time

然后使用GNU Coreutils实现。

这个有点复杂,但是相关的资源似乎在resuse.c上,它确实:

  • 非POSIX BSD wait3呼叫(如果有)
  • timesgettimeofday否则


小智.. 14

Real表示流程的总周转时间; 用户显示用户定义指令的执行时间,而Sys用于执行系统调用的时间!

实时包括等待时间(I/O的等待时间等)


归档时间:

查看次数:

415027 次

最近记录:

10 月,3 周 前