Linux中异常定位消耗的线程实战

在我们的嵌入式linux开发过程中，我们在开发过程中经常会用到多进程、多线程开发。在这么多线程的使用过程中，很有可能某个线程会长时间占用cpu，导致设备性能异常。通常只有四五个线程。我们可以一个一个调试捕获异常线程。如果你开发了大概三十、四十个线程运行在设备上，我们很难一下子看出哪个线程有问题，也不好用。按枚举搜索。这时候我们就需要配合一些工具，对我们执行的进程下的线程进行监控和检查。我举一个我在自己工作中实际遇到的例子。剧情简介：在工作中，我遇到了这样一个问题。我的设备在运行的时候，发现机器运行在一些怪异的状态，对某些机制的响应不够及时。最后查看top，发现是在运行的某个进程中有一些线程运行时CPU占用率高，导致其他一些线程无法及时运行。我们发现了问题，然后我们开始寻找对应的线程，然后修改。如前所述，进程中有一个或两个线程。幸运的是，我们可以使用一些基本的方法从日志或其他方式中输出信息，一一列举，但是如果遇到单个进程中有多个线程，我们如何检查呢？初步概述使用的工具：ps组合命令、top组合命令、pstack、strace、ltrace、gdbattach实时调试、kill、coredumpFileViewThreadStack以上是我使用的一些命令和操作。接下来，我将一一分析介绍：首先，我将详细介绍每个工具和命令，然后用我自己的一个小例子来组合这些工具。使用说明。工具和组合命令的详细介绍首先，我们来详细介绍一下这些工具手册：ps选项参数介绍：Linux中的ps命令大家应该都不陌生了。ps是ProcessStatus的缩写，用来列出当前正在运行的进程。使用该命令可以判断哪些进程正在运行及其状态，进程是否终止，进程是否死亡，哪些进程占用资源过多等。ps命令列出的进度是当前进程的快照，即不是动态的，而是命令执行时那一刻的状态。ps的参数很多，这里只介绍几个常用的参数，简单介绍一下它们的含义-A列出所有进程-wdisplayswiderinformation显示更多的信息-au显示更详细的信息-aux显示allincluded我平时用的ps-aux为其他用户的行程查看后台运行进程的pid。再补充一下今天要用到的ps组合命令，查看进程对应的线程。pid可以自己替换）第一行是对应的进程ID，第二行是对应的线程ID查看进程对应线程的执行时间ps-eLopid,lwp,pcpu|grep1780(1780这里是真实进程的pid替换）第一行是进程pid，第二行是进程中线程对应的pid，第三行是线程的执行时间，单位ms。我们通过线程执行时间的长短，配合线程的栈信息，线程频繁进行IO操作或者线程频繁执行的库函数来判断线程是否误占用了CPU资源。top组合命令介绍：top命令也是大家比较熟悉的一个命令。它可以显示有关系统当前正在执行的进程的信息，包括进程ID、内存使用情况和CPU使用情况。也可以向指定进程发送信号。-b批处理-c显示完整信息-I忽略失效进程-s秘密模式-S累积模式-i设置间隔时间-u<用户名>指定用户名-p<进程号>指定进程-n显示的循环次数首先，我们一般直接使用top命令查看进程信息。这里再多说明一下，因为后续使用strace工具还是ltrace工具是从top命令的cpu信息区来判断的。我们使用特定的工具。.test@test:~#toptop-02:32:07up17min,2users,loadaverage:3.17,3.26,2.17Tasks:165total,3running,162sleeping,0stopped,0zombie%Cpu(s):31.3us,7.0sy,0.0ni,60.9id,0.0wa,0.0hi,0.9si,0.0stMiBMem:3845.3total,3424.3free,240.9used,180.1buff/cacheMiBSwap:0.0total,0.0free,0.0used.3566.7availMemPIDUSERPRNIVIRTRESSHRS%CPU%MEMTIME+COMMAND461root-9282516783482516788342516783451.518:15.07ex375root-20000S5.90.00:04.23RTW_RECV_THREAD430root200682204225366880S5.90.60:55.69python16913root200000S5.90.00:02.46kworker/u12:022219root200330021001628R5.90.10:00.02top1root2001892620556S0.00.00:00.41init2root200000S0.00.00:00.01kthreadd3root200000S0.00.00:00.14ksoftirqd/05root0-20000S0.00.00:00.00kworker/0:0H7root200000R0.00.00:02.24rcu_sched8root200000S0.00.00:00.00rcu_bh9rootrt0000S0.00.00:00.16migration/010rootrt0000topS0.00.000S0.00.00:00.00rcu_bh9rootrt0000S0.00.00:00.16migration/010rootrt0000topS0.00.000:00.00显示当前五个分区的整体系统信息/dog关于这部分统计信息的解释，参考文章《top命令》：第一行，任务队列信息，和uptime命令test@test的执行结果一样：~#uptime13:46:08up1:04,1user,loadaverage:0.00,0.00,0.00参数说明如下：02:32:07—当前系统时间up17min,—系统已运行17分钟2users—当前有2个用户终端登录进入系统loadaverage:3.17,3.26,2.17——loadaverage后面三个数字分别为1分钟、5分钟、15分钟负载。loadaverage数据是每5秒查看活跃进程数，然后根据特定算法计算出来的值。如果用这个数字除以逻辑CPU的数量，结果大于5表示系统过载。第二行，Tasks——任务（进程），具体信息如下：系统现在有165个进程，其中3个正在运行，162个处于睡眠状态（sleep），0个处于停止状态，僵尸状态（Zombie）有0。第三行，cpu状态信息，具体属性如下：31.3us——用户空间占用CPU百分比。7.0sy——内核空间占用的CPU百分比。0.0ni—改变优先级的进程占用CPU百分比60.9id—空闲CPU百分比0.0wa—IO等待占用CPU百分比0.0hi—硬件中断(HardwareIRQ)占用CPU百分比0.0st百分比当hypervisor服务于另一个处理器（从虚拟机窃取）时，虚拟cpu非自愿等待所花费的时间Amount(3.8GB)3424.3free—空闲内存总量(3.2GB)240.9used—内存总量use(240.9MB)180.1buff/cache—缓存内存量(180M)第五行是swap分区信息，具体信息说明如下：0.0total—swap区总量(0.0GB)0.0free—totalamountoffreeswaparea(0MB)0.0used—已使用的swap区域总量(0MB)3566.7availMem—缓冲swap区域总量(3.5GB)第六行，空行。第七行以下：各进程（任务）状态监控，item栏信息说明如下：PID—进程idUSER—进程所有者PR—进程优先级NI—nice值。负值表示高优先级，正值表示低优先级VIRT——进程使用的虚拟内存总量，单位为kb。VIRT=SWAP+RESRES——进程使用的且未换出的物理内存大小，以kb为单位。RES=CODE+DATASHR——共享内存大小，单位kbS——进程状态。D=不可中断的睡眠状态R=运行S=睡眠T=trace/stopZ=僵尸进程,unit1/100secondCOMMAND——进程名（命令名/命令行）这是经常使用top得到的信息。我们一般都是组合使用命令。我一般用top-Hp461（这里461才是真正的进程可以自己替换pid）通过-Hp命令，可以查看指定进程的线程。在统计信息的第三行，可以看到CPU占用主要是在用户态。那么我们应该优先使用ltrace来调用和查询用户态库函数。当然strace也是可以的，但是由于内核占用CPU占用率不高，所以你trace的IO操作应该远少于用户态库函数调用。pstack的选项参数介绍：pstack是Linux系统下的一个命令行工具。该命令可以显示指定进程各个线程的堆栈快照，方便排查程序异常和性能评估。此命令允许的唯一选项是要检查PID的进程。如果你想使用这个包，你需要在你使用的linuxlib和bin目录下添加这个工具。例子sudopstack16634（pid是我自己的测试机对应的进程，使用时可以换成自己对应的pid）在一段时间内可以多次执行pstack。如果发现代码栈总是停在同一个位置，那个位置需要重点关注，很可能就是问题所在；ltrace选项参数介绍：ltrace可以跟踪进程的库函数调用，会显示调用了哪个库函数，而strace是跟踪进程的每次系统调用。ltracetrace进程调用库函数参数选项有哪些？ltrace选项参数介绍：-c统计库函数每次调用的时间，并在程序退出时打印摘要。-C将低级名称（内核级）解码为用户级名称。-d打印调试信息。-eexpr输出过滤器，通过表达式，可以过滤掉你不想要的输出。-eprintf表示只查看printf函数调用。-e!printf表示查看除printf函数外的所有函数调用。-f跟踪子进程。-oflename将ltrace的输出写入文件filename。-ppid指定要跟踪的进程pid。-r打印每次调用的相对时间。-S显示系统调用。-t在输出中的每一行之前加上时间信息。-tt在输出中的每一行之前加上时间信息，精确到微秒。-ttt在输出的每一行前添加时间信息，精确到微秒，时间以UNIX时间戳表示。-T显示每次调用所用的时间。strace选项参数介绍：strace常用来跟踪进程执行过程中的系统调用和接收到的信号。在Linux世界中，进程不能直接访问硬件设备。当进程需要访问硬件设备（如读取磁盘文件、接收网络数据等）时，必须从用户态切换到内核态，通过系统调用访问硬件设备。strace可以跟踪进程产生的系统调用，包括参数、返回值和执行时间。-f跟踪目标进程，目标进程创建的所有子进程-t在输出的每一行前加上时间信息（-tt表示微秒）-T通过观察系统调用来显示每次系统调用所花费的时间我们可以确认当前程序的行为，分析其消耗的时间，返回值是否正常。您可以过滤指定的线程号以确认当前线程的行为是否符合预期。如果执行完命令后完全没有输出，可以怀疑是不是网络、IO等阻塞了，或者程序死锁了。pstree的选项和参数介绍：该命令将以树状视图显示所有进程。树视图将使用pid（如果指定）或init的基本进程作为根（root）。如果指定了用户id，树将是状态图将只显示用户拥有的进程。如果你想使用这个包，你需要在你使用的linuxlib和bin目录下添加这个工具。-A：每个进程树之间的连接用ASCII码字符连接-U：每个进程树之间的连接用utf8字符连接，部分终端可能有错误-p：同时列出每个进程的PID-u:同时列出每个进程的账户名:pstree-up输出进程和子进程树数据kill和coredump文件查看线程堆栈:因为有时候我们使用的linux环境可能没有非常综合工具，比如上面提到的查看对应线程的pstack，后面会有其他的命令和工具代替，这里介绍一下我用的两种查看自己实际栈和对应pid线程信息的方法。kill-11461对应的进程会出现Segmentationfault(coredumped)，我们已经设置了coredump文件的生成。生成条件中有段错误信号，所以我给进程发送了11信号。如果不知道自己需要的信号对应的编号，可以使用kill-l命令查询。至于通过coredump查看相应的堆栈信息，我之前的文章比较全面，这里就不赘述了。Linux开发coredump文件实战分析分享可点此查看。除了使用kill命令杀死指定进程外，我们还可以使用top组合命令杀死进程：首先使用top输入top显示的信息，如果我们选择了进程461则杀死：首先输入k进入topOptionPIDtosignal/kill[defaultpid=1451]PIDUSERPRNIVIRTRESSHRS%CPU%MEMTIME+COMMAND461root-96-2020814642867217756S21.71.40:07.05exc然后按提示输入指定pid461PIDtosignal/kill[defaultpid=1451]461输入信号，之后我按照提示输入信号选择11(segmentfaultsignal)sendpid461signal[15/sigterm]11这个操作相当于kill-11461gdbattach实时调试：这是gdb中的一个实时调试工具，它指定了进程的实时调试，但是在实践中，遇到大代码太卡调试，所以我基本不用它来实时调试。我用它来实时查看一些堆栈信息，检查线程id和实际代码是否匹配。操作也比较简单。从上面我们可以知道你正在运行的进程的pid。您可以使用gdbattach指定要调试的pid。进入后的运行命令是gdb调试的命令。可以看到gdbattach一进来，前面就显示了对应的lwp线程pid。这个pid与top命令、ps命令、strace、ltrace打印的pid信息是一致的。通过同一个pid，我们可以知道进程或线程下进行的具体操作。输入gdb命令threadapplyallbt，我们可以看到对应线程的栈，通过栈的信息可以反向查找代码。下面是一个截取，显示了一个lwp790(threadpid==790)的栈信息。通过#3可以知道even_manager.cpp的40行线程代码的组合使用。通过上面命令的介绍，我们也知道了在Linux下可以使用哪些工具来分析我们异常的进程和线程。接下来，我将通过我实际遇到的一个情况，向大家介绍这些工具的组合。首先，我使用top命令检查我的cpu使用情况。从这个角度来看，ex进程居然占用了176%的cpu（我的设备是多核设备），也就是说cpu几乎两个核都被占满了。此时可以看到占用的cpu资源主要是用户态的资源，所以推荐使用ltrace查看，但是我现在的设备没有这个包，所以直接使用strace查看。接下来想知道进程下是哪个线程，线程对应的是哪部分代码，经常执行哪些操作。所以我先用top-Hp461查看我对进程下的所有线程执行的cpu百分比。也可以使用ps-T-p461查看进程对应的线程pid信息ps-eLopid,lwp,pcpu|grep461查看线程执行耗时strace-p461-f查看最内核本进程下执行的交互函数执行部分最左边是对应执行IO函数下的线程PID。同时我们可以直接指定线程pid来查询线程运行情况。比如我们看到线程845正在读一个fd为13的设备，我们可以单独strace-p845本来strace、ltrace、pstack应该一起使用，但是我用的设备没有ltrace和pstack，所以我使用gdbattach直接调试进程，查看对应的线程堆栈信息，并用它来确认top组合命令的输出，线程pid信息与实际代码映射。gdbattach461实时调试查看线程堆栈信息与实际代码部分相符进入后直接使用threadapplyallbt查看对应的线程堆栈信息。通过栈信息，我们可以知道对应代码部分的各个栈顶信息，如果lwp有显示，可以对照代码查看。这个时候，我们知道了进程下有哪些线程，那么我们还需要知道线程对应的是哪部分代码，线程具体执行了哪些操作。strace和gdbattach命令从开发之初都是很好的技术，但是在实际使用中，由于代码的复杂性，以及c和cpu的限制，在我使用strace和gdbattach的时候，这些工具不得不一直监控进程，会非常占用你的cpu资源，连gdbattach启动调试，机器直接运行很慢，远程ssh登录卡死。所以只能使用一些消耗资源较少的操作来查看信息，就像内存分析中的mtrace和valgrind，一旦开始使用，机器就会直接停止。所以很多时候，工具虽然好，但也只能辅助一些。更重要的是，我们需要规范代码编写。结论这就是我在工作中使用的一些linux线程监控操作的分享方式。如果您有更好的想法和需求，欢迎加我好友一起交流分享。作者：还是有良心的，白天努力工作，晚上创建公众号主。公众号内容除了技术，还有一些生活感悟。一个认真输出内容的职场老司机，也是一个在科技、摄影、音乐、篮球之外丰富生活的人。跟随我，与我同行。