Как обнаружить горячий стек процессора? - PullRequest
0 голосов
/ 02 ноября 2019

Я собираюсь пройтись по лабораториям метода и производительности Брэндана Грегга USE , которые вы можете найти здесь и метод USE здесь . В лабораторной работе 1 я запускаю команду top и вижу, что у меня есть следующая статистика:

top - 14:12:21 up  6:52,  3 users,  load average: 1.00, 1.00, 1.00
Tasks: 177 total,   2 running, 142 sleeping,   0 stopped,   0 zombie
%Cpu(s): 98.7 us,  0.9 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.4 si,  0.0 st
KiB Mem :  2038768 total,   212784 free,   514224 used,  1311760 buff/cache
KiB Swap:   483800 total,   211392 free,   272408 used.  1341344 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
32130 connor    20   0    4372    788    728 R 97.7  0.0  71:59.53 lab001

очень ясно, что это проблема, связанная с процессором, в частности, проблема исходит из пространства пользователя (некоторые приложения работают)(это видно по метрике us в строке 3 ), и после дополнительного анализа вы можете увидеть, что большая часть процессорного времени тратится вхолостую (вы можете увидеть это по метрике id настрока 3).

Круто, так что это, очевидно, проблема с процессором. Тем не менее, рассматриваемая программа является явно бесконечно работающим процессом благодаря написанному в ней C-коду.

Заголовок файла говорит о чем-то интересном, хотя CPU hot stack - это ответ на проблему,

  • Что такое горячий стек? Я нигде не могу найти определения для этого.

  • Как вы точно проверяете стек, чтобы видеть, что данные файла постоянно записываются в него и зависают.

Полагаю, что я пытаюсь сказать, как вы логически делаете переход от процесса с экстремальной загрузкой процессора к выводу, что в стеке возникают проблемы?

Моя попытка

Вот вывод strace самого файла:

user@VirtualBox:~/Desktop/sre-prep/perf-labs/src$ clear
user@VirtualBox:~/Desktop/sre-prep/perf-labs/src$ strace -t ./lab001
14:57:14 execve("./lab001", ["./lab001"], 0x7ffdb0599758 /* 25 vars */) = 0
14:57:14 brk(NULL)                      = 0x559735f39000
14:57:14 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
14:57:14 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
14:57:14 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
14:57:14 fstat(3, {st_mode=S_IFREG|0644, st_size=84089, ...}) = 0
14:57:14 mmap(NULL, 84089, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fe524ab2000
14:57:14 close(3)                       = 0
14:57:14 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
14:57:14 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
14:57:14 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\34\2\0\0\0\0\0"..., 832) = 832
14:57:14 fstat(3, {st_mode=S_IFREG|0755, st_size=2030544, ...}) = 0
14:57:14 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe524ab0000
14:57:14 mmap(NULL, 4131552, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe5244af000
14:57:14 mprotect(0x7fe524696000, 2097152, PROT_NONE) = 0
14:57:14 mmap(0x7fe524896000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e7000) = 0x7fe524896000
14:57:14 mmap(0x7fe52489c000, 15072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fe52489c000
14:57:14 close(3)                       = 0
14:57:14 arch_prctl(ARCH_SET_FS, 0x7fe524ab14c0) = 0
14:57:14 mprotect(0x7fe524896000, 16384, PROT_READ) = 0
14:57:14 mprotect(0x55973545a000, 4096, PROT_READ) = 0
14:57:14 mprotect(0x7fe524ac7000, 4096, PROT_READ) = 0
14:57:14 munmap(0x7fe524ab2000, 84089)  = 0

, и я могу видеть, что память сопоставлена, но нет "традиционных" переменных, которые дажев этой программе, поэтому я не мог думать, что это проблема стека в первую очередь.

Вот сам файл:

/*
 * lab001 - CPU hot stack.
 *
 * 21-May-2015  Brendan Gregg   Created this.
 */

void
func_c()
{
    for(;;){}
}

void
func_b()
{
    func_c();
}

void
func_a()
{
    func_b();
}

int
main(int argc, char *argv[])
{
    func_a();
    return (0);
}

Заранее спасибо за любые идеи, которые вы можетедоля!

...