首先查看系统资源的消耗情况
top 资源负载不高
检查VS CODE的进程信息
ps -aux | grep code
打开了很多的进程,可以通过pid ppid观察进程间的父子关系。
查看VS CODE某个进程的详细信息
cat /proc/pid/status
Name 应用程序或命令的名字
State 任务的状态,运行/睡眠/僵死/
SleepAVG 任务的平均等待时间(以nanosecond为单位),交互式任务因为休眠次数多、时间长,它们的 sleep_avg 也会相应地更大一些,所以计算出来的优先级也会相应高一些。
Tgid 线程组号
Pid 任务ID
Ppid 父进程ID
TracerPid 接收跟踪该进程信息的进程的ID号
Uid Uid euid suid fsuid
Gid Gid egid sgid fsgid
FDSize 文件描述符的最大个数,file->fds
Groups
VmSize(KB) 任务虚拟地址空间的大小 (total_vm-reserved_vm),其中total_vm为进程的地址空间的大小,reserved_vm:进程在预留或特殊的内存间的物理页
VmLck(KB) 任务已经锁住的物理内存的大小。锁住的物理内存不能交换到硬盘 (locked_vm)
VmRSS(KB) 应用程序正在使用的物理内存的大小,就是用ps命令的参数rss的值 (rss)
VmData(KB) 程序数据段的大小(所占虚拟内存的大小),存放初始化了的数据; (total_vm-shared_vm-stack_vm)
VmStk(KB) 任务在用户态的栈的大小 (stack_vm)
VmExe(KB) 程序所拥有的可执行虚拟内存的大小,代码段,不包括任务使用的库 (end_code-start_code)
VmLib(KB) 被映像到任务的虚拟内存空间的库的大小 (exec_lib)
VmPTE 该进程的所有页表的大小,单位:kb
Threads 共享使用该信号描述符的任务的个数,在POSIX多线程序应用程序中,线程组中的所有线程使用同一个信号描述符。
SigQ 待处理信号的个数
SigPnd 屏蔽位,存储了该线程的待处理信号
ShdPnd 屏蔽位,存储了该线程组的待处理信号
SigBlk 存放被阻塞的信号
SigIgn 存放被忽略的信号
SigCgt 存放被俘获到的信号
CapInh Inheritable,能被当前进程执行的程序的继承的能力
CapPrm Permitted,进程能够使用的能力,可以包含CapEff中没有的能力,这些能力是被进程自己临时放弃的,CapEff是CapPrm的一个子集,进程放弃没有必要的能力有利于提高安全性
CapEff Effective,进程的有效能力
查看vs code的日志
vs code的打开后,会在当前用户的家目录下的.config目录中创建自己的用户相关的一些配置,其中日志也在该目录。各种软件皆是如此,如果软件出现打不开的问题,可能是该目录下的内容被破坏,可以尝试删除该目录,基本上问题都能得到解决(一次Chrome打不开就是这样,一直提示某个文件被锁定,没有提示具体的问题,将.config下生成的google-chrome删掉,问题就解决了,付出的代价就是你的用户相关的配置就没了)。
cd ~/.config/Code/logs
结论:
做过以上排查后,资源耗费不高,如果是假死肯定和资源无关。日志无明显异常,确定code本身应该没有大问题。我是远程桌面访问的远程主机上的vs code,切换软件都失效,点击vs code的c调试弹窗没有反应,以为是vs code假死导致系统假死。一直使用鼠标操作,后来使用键盘Tab尝试切换,关掉了vs code的弹框,一切就恢复正常了。
最后还是没有根因,不知是远程桌面的鼠标事件失效,还是xrdp server响应有问题。反正是确认vs code假死等待什么。本次仅做一次记录吧。