Я собираюсь пройтись по лабораториям метода и производительности Брэндана Грегга 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);
}
Заранее спасибо за любые идеи, которые вы можетедоля!