再续《linux 3.10 一次softlock排查》，看运行态进程数量之多：

crash> machMACHINE TYPE: x86_64MEMORY SIZE: 90 GBCPUS: 24HYPERVISOR: KVMPROCESSOR SPEED: 2394 MhzHZ: 1000PAGE SIZE: 4096KERNEL VIRTUAL BASE: ffff880000000000KERNEL VMALLOC BASE: ffffc90000000000KERNEL VMEMMAP BASE: ffffea0000000000KERNEL START MAP: ffffffff80000000KERNEL MODULES BASE: ffffffffc0000000KERNEL STACK SIZE: 16384IRQ STACK SIZE: 16384IRQ STACKS:CPU 0: ffff880b52a00000CPU 1: ffff880b52a40000CPU 2: ffff880b52a80000CPU 3: ffff880b52ac0000CPU 4: ffff880b52b00000CPU 5: ffff880b52b40000CPU 6: ffff880b52b80000CPU 7: ffff880b52bc0000CPU 8: ffff880b52c00000CPU 9: ffff880b52c40000CPU 10: ffff880b52c80000CPU 11: ffff880b52cc0000CPU 12: ffff881692200000CPU 13: ffff881692240000CPU 14: ffff881692280000CPU 15: ffff8816922c0000CPU 16: ffff881692300000CPU 17: ffff881692340000CPU 18: ffff881692380000CPU 19: ffff8816923c0000CPU 20: ffff881692400000CPU 21: ffff881692440000CPU 22: ffff881692480000CPU 23: ffff8816924c0000
DOUBLEFAULT STACK SIZE: 4096

但是，我们来看，有多少个running进程呢？

ps |grep -i RU
>     0      0   0  ffffffff81a09480  RU   0.0       0      0  [swapper/0]0      0   1  ffff88016e798fd0  RU   0.0       0      0  [swapper/1]0      0   2  ffff88016e799fa0  RU   0.0       0      0  [swapper/2]0      0   3  ffff88016e79af70  RU   0.0       0      0  [swapper/3]0      0   4  ffff88016e79bf40  RU   0.0       0      0  [swapper/4]0      0   5  ffff88016e79cf10  RU   0.0       0      0  [swapper/5]0      0   6  ffff88016e79dee0  RU   0.0       0      0  [swapper/6]0      0   7  ffff88016e79eeb0  RU   0.0       0      0  [swapper/7]
>     0      0   8  ffff88016e008000  RU   0.0       0      0  [swapper/8]0      0   9  ffff88016e008fd0  RU   0.0       0      0  [swapper/9]0      0  10  ffff88016e009fa0  RU   0.0       0      0  [swapper/10]
>     0      0  11  ffff88016e00af70  RU   0.0       0      0  [swapper/11]
>     0      0  12  ffff880beeaceeb0  RU   0.0       0      0  [swapper/12]0      0  13  ffff880beeacdee0  RU   0.0       0      0  [swapper/13]0      0  14  ffff880beeaccf10  RU   0.0       0      0  [swapper/14]
>     0      0  15  ffff880beeacbf40  RU   0.0       0      0  [swapper/15]0      0  16  ffff880beeacaf70  RU   0.0       0      0  [swapper/16]0      0  17  ffff880beeac9fa0  RU   0.0       0      0  [swapper/17]0      0  18  ffff880beeb10000  RU   0.0       0      0  [swapper/18]0      0  19  ffff880beeb10fd0  RU   0.0       0      0  [swapper/19]0      0  20  ffff880beeb11fa0  RU   0.0       0      0  [swapper/20]0      0  21  ffff880beeb12f70  RU   0.0       0      0  [swapper/21]0      0  22  ffff880beeb13f40  RU   0.0       0      0  [swapper/22]0      0  23  ffff880beeb14f10  RU   0.0       0      0  [swapper/23]1      0  21  ffff880beeac8000  RU   0.0  201332  14472  systemd10      2   4  ffff88016e726eb0  RU   0.0       0      0  [rcu_sched]12      2   1  ffff88016e00eeb0  RU   0.0       0      0  [watchdog/1]14      2   1  ffff88016e00cf10  RU   0.0       0      0  [ksoftirqd/1]17      2   2  ffff88016e040fd0  RU   0.0       0      0  [watchdog/2]22      2   3  ffff88016e045ee0  RU   0.0       0      0  [watchdog/3]24      2   3  ffff88016e098000  RU   0.0       0      0  [ksoftirqd/3]27      2   4  ffff88016e09af70  RU   0.0       0      0  [watchdog/4]42      2   7  ffff88016e111fa0  RU   0.0       0      0  [watchdog/7]52      2   9  ffff88016e163f40  RU   0.0       0      0  [watchdog/9]57      2  10  ffff88016e198fd0  RU   0.0       0      0  [watchdog/10]73      2  13  ffff880beeb3bf40  RU   0.0       0      0  [watchdog/13]83      2  15  ffff880beeb7dee0  RU   0.0       0      0  [watchdog/15]88      2  16  ffff880beebaaf70  RU   0.0       0      0  [watchdog/16]93      2  17  ffff880beebf0000  RU   0.0       0      0  [watchdog/17]98      2  18  ffff880beebf4f10  RU   0.0       0      0  [watchdog/18]103      2  19  ffff880bee021fa0  RU   0.0       0      0  [watchdog/19]108      2  20  ffff880bee026eb0  RU   0.0       0      0  [watchdog/20]110      2  20  ffff880bee050fd0  RU   0.0       0      0  [ksoftirqd/20]113      2  21  ffff880bee053f40  RU   0.0       0      0  [watchdog/21]118      2  22  ffff880bee078fd0  RU   0.0       0      0  [watchdog/22]409  22481  10  ffff880b06e15ee0  RU   0.5 13597708 511816  zte_uep1410  22481  21  ffff88077fe08000  RU   0.5 13597708 511816  zte_uep1413  22481   1  ffff8814af3fbf40  RU   0.5 13597708 511816  zte_uep1425  17770  10  ffff8807967d6eb0  RU   0.5 2267176 439500  java636      1  15  ffff880b4f5b5ee0  RU   0.0   45452   1740  systemd-journal865  22481  23  ffff8809a4aacf10  RU   0.5 13597708 511816  zte_uep1924  22481  17  ffff880036a6cf10  RU   0.5 13597708 511816  zte_uep1932      2  13  ffff880036022f70  IN   0.0       0      0  [xfs_mru_cache]。。。。。。。。。。。。。。。。。。。。列不完

看看个数：

crash> ps |grep -w RU |wc -l
1654

经常敲top的人肯定知道，running的进程数，一般是小于等于cpu的核数的，那为啥这个机器上这么多的running呢？为了排除是crash工具的问题，在从runqueue的角度来看下：

crash> p runqueues
PER-CPU DATA TYPE:struct rq runqueues;
PER-CPU ADDRESSES:[0]: ffff880b52a17c00[1]: ffff880b52a57c00 [2]: ffff880b52a97c00 [3]: ffff880b52ad7c00 [4]: ffff880b52b17c00 [5]: ffff880b52b57c00 [6]: ffff880b52b97c00 [7]: ffff880b52bd7c00 [8]: ffff880b52c17c00 [9]: ffff880b52c57c00 [10]: ffff880b52c97c00 [11]: ffff880b52cd7c00 [12]: ffff881692217c00 [13]: ffff881692257c00 [14]: ffff881692297c00 [15]: ffff8816922d7c00 [16]: ffff881692317c00 [17]: ffff881692357c00 [18]: ffff881692397c00 [19]: ffff8816923d7c00 [20]: ffff881692417c00 [21]: ffff881692457c00 [22]: ffff881692497c00 [23]: ffff8816924d7c00 crash> struct rq.nr_running ffff880b52a17c00 nr_running = 7 crash> struct rq.nr_running ffff880b52a57c00 nr_running = 152

挨个查看一下nr_running个数，然后脚本统计如下：

grep 'nr_running =' 1.txt |awk '{print $3}BEGIN{sum=0;num=0}{sum+=$3;num+=1}END{printf "%d\n",sum}'
7
152
113
138
65
4
4
38
4
148
43
1
1
141
4
43
107
102
91
110
108
105
98
3
1630-------------总数

为什么这个总数和我们ps看到的RU状态的总数不一致呢？一开始还以为是percpu统计的瞬时值问题，但是这两个总数的相差：1654-1630=24，刚好和cpu的核数一致。

ps |grep -w 'RU'|grep 'swapper'
>     0      0   0  ffffffff81a09480  RU   0.0       0      0  [swapper/0]0      0   1  ffff88016e798fd0  RU   0.0       0      0  [swapper/1]0      0   2  ffff88016e799fa0  RU   0.0       0      0  [swapper/2]0      0   3  ffff88016e79af70  RU   0.0       0      0  [swapper/3]0      0   4  ffff88016e79bf40  RU   0.0       0      0  [swapper/4]0      0   5  ffff88016e79cf10  RU   0.0       0      0  [swapper/5]0      0   6  ffff88016e79dee0  RU   0.0       0      0  [swapper/6]0      0   7  ffff88016e79eeb0  RU   0.0       0      0  [swapper/7]
>     0      0   8  ffff88016e008000  RU   0.0       0      0  [swapper/8]0      0   9  ffff88016e008fd0  RU   0.0       0      0  [swapper/9]0      0  10  ffff88016e009fa0  RU   0.0       0      0  [swapper/10]
>     0      0  11  ffff88016e00af70  RU   0.0       0      0  [swapper/11]
>     0      0  12  ffff880beeaceeb0  RU   0.0       0      0  [swapper/12]0      0  13  ffff880beeacdee0  RU   0.0       0      0  [swapper/13]0      0  14  ffff880beeaccf10  RU   0.0       0      0  [swapper/14]
>     0      0  15  ffff880beeacbf40  RU   0.0       0      0  [swapper/15]0      0  16  ffff880beeacaf70  RU   0.0       0      0  [swapper/16]0      0  17  ffff880beeac9fa0  RU   0.0       0      0  [swapper/17]0      0  18  ffff880beeb10000  RU   0.0       0      0  [swapper/18]0      0  19  ffff880beeb10fd0  RU   0.0       0      0  [swapper/19]0      0  20  ffff880beeb11fa0  RU   0.0       0      0  [swapper/20]0      0  21  ffff880beeb12f70  RU   0.0       0      0  [swapper/21]0      0  22  ffff880beeb13f40  RU   0.0       0      0  [swapper/22]0      0  23  ffff880beeb14f10  RU   0.0       0      0  [swapper/23]

原来是因为idle进程默认在running态，但是并不算到nr_running的计数中：

crash> ps |grep -w 'RU' |grep -w '12'
>     0      0  12  ffff880beeaceeb0  RU   0.0       0      0  [swapper/12]12      2   1  ffff88016e00eeb0  RU   0.0       0      0  [watchdog/1]-----------这个不是12cpu的进程22237      1  12  ffff881254b5eeb0  RU   1.0 14321692 912420  1_scheduler
crash> struct rq.nr_running ffff881692217c00nr_running = 1

为啥running这么多呢？查看处于running状态的task，堆栈都是 __schedule ，也就是就绪队列很长，

来挑一些看看堆栈：

crash> bt 30507
PID: 30507  TASK: ffff8809d42daf70  CPU: 3   COMMAND: "java"#0 [ffff88099eb93d58] __schedule at ffffffff816b6165#1 [ffff88099eb93dc0] schedule at ffffffff816b6ae9#2 [ffff88099eb93dd0] schedule_hrtimeout_range_clock at ffffffff816b5852#3 [ffff88099eb93e68] schedule_hrtimeout_range at ffffffff816b5903#4 [ffff88099eb93e78] ep_poll at ffffffff812526de#5 [ffff88099eb93f30] sys_epoll_wait at ffffffff81253b9d#6 [ffff88099eb93f80] system_call_fastpath at ffffffff816c2789RIP: 00007ffa43a652c3  RSP: 00007ffa2595b818  RFLAGS: 00010202RAX: 00000000000000e8  RBX: ffffffff816c2789  RCX: 00000000e14ef930RDX: 0000000000002000  RSI: 00000000047a5000  RDI: 0000000000000067RBP: 00007ffa2595b630   R8: 0000000000000000   R9: 0000000000000003R10: 0000000000007530  R11: 0000000000000293  R12: 0000016547341bcaR13: 0000000000000067  R14: 0000000000007530  R15: 00000000047a5000ORIG_RAX: 00000000000000e8  CS: 0033  SS: 002b
crash> bt 31606
PID: 31606  TASK: ffff8809cbe03f40  CPU: 9   COMMAND: "java"#0 [ffff880a4eedbd58] __schedule at ffffffff816b6165#1 [ffff880a4eedbdc0] schedule at ffffffff816b6ae9#2 [ffff880a4eedbdd0] schedule_hrtimeout_range_clock at ffffffff816b5852#3 [ffff880a4eedbe68] schedule_hrtimeout_range at ffffffff816b5903#4 [ffff880a4eedbe78] ep_poll at ffffffff812526de#5 [ffff880a4eedbf30] sys_epoll_wait at ffffffff81253b9d#6 [ffff880a4eedbf80] system_call_fastpath at ffffffff816c2789RIP: 00007f7bb9bb72c3  RSP: 00007f7b8f060510  RFLAGS: 00000246RAX: 00000000000000e8  RBX: ffffffff816c2789  RCX: 00000000ffffffffRDX: 0000000000002000  RSI: 0000000005be3000  RDI: 0000000000000151RBP: 00007f7b8f060310   R8: 0000000000000000   R9: 0000000000000003R10: 00000000000003e8  R11: 0000000000000293  R12: 0000016547349167R13: 0000000000000151  R14: 00000000000003e8  R15: 0000000005be3000ORIG_RAX: 00000000000000e8  CS: 0033  SS: 002b
crash> task_struct.state ffff8809cbe03f40state = 0

看看状态值的宏：

#define TASK_RUNNING        0
#define TASK_INTERRUPTIBLE    1
#define TASK_UNINTERRUPTIBLE    2
#define __TASK_STOPPED        4
#define __TASK_TRACED        8

再看看占有cpu的进程的堆栈，发现基本都在等锁，原本大家很快都能执行完，然后放到等待队列里面去，但是由于前面某个进程执行占着cpu不放，那么因为等待资源而得到唤醒的，处于就绪队列里面的进程自然得不到调度。当然这个是非抢占式内核的特点，高优先级的进程，也得等低优先级的进程主动放弃cpu，哪怕你已经在就绪队列，哪怕你的状态已经被改成了running，但就得等着。

转载于:https://www.cnblogs.com/10087622blog/p/9582606.html

linux 再多的running也挡不住锁相关推荐

  1. 再好的接口也挡不住程序员敏锐的眼睛

    今天主要是来跟大家分享下刷赞的基本思路,实践就用我最爱的CSDN. 前言 现在总是有好多求赞的信息,有时候看到那些求赞票数低的,还感到心疼.曾经我也是用刷赞的技术跟爱人跟一个新开的健身中心刷到前几名, ...

  2. 数据我爬定了，限流也挡不住，我说的

    万事万物都存在对立面,有正就反,有对亦有错,有阳也有阴,有好也有坏,正是因为这样的"对立"才能够对事情的本身达到一种均衡和制衡,否则结果导向只有一方只会让事情变得极端. 废话不多说 ...

  3. 有时候缘分来了，挡也挡不住，我们终究能等到对的那个人。

    ψ 豆瓣Top1电影--肖申克的救赎| 第131篇 It is not crowded on the way up. It is crowded where many people choose to ...

  4. Google何以挡都挡不住 Google山景城总部探密

    Google何以挡都挡不住 Google山景城总部探密[@more@]这个夏天,科技再度回到热门话题焦点.其中最热门的关键词,就是Google. 如果没有Google,那斯达克(NASDAQ)没有让人 ...

  5. 火了，挡不住了：Facebook Move编程语言入门

    火了,挡不住了:Facebook Move编程语言入门 Facebook区块链项目Libra的其中一个技术亮点,就是它使用了一种称为Move的新编程语言,那么这种语言是怎样的呢,今天我们就从其官方的概 ...

  6. 疫情挡不住上市步伐：视频模拟敲锣 A股云上市了解一下

    "谢谢大家,我们上市了!良品加油,武汉加油,中国加油!" 在淘宝直播间,创始人.董事长杨红春宣布良品铺子成功在上交所挂牌,成为湖北A股第一家远程上市的互联网企业. 受新冠肺炎疫情影 ...

  7. 华为云郑叶来：优势挡不住趋势，技术创新是主旋律

    2020年7月20日,华为云举办TechWave技术峰会.基于华为30年ICT技术积累和长期服务政企客户的经验,华为云阐述了面向未来的使命,为政企提供智能升级的数字基础设施,并重磅发布了七大新品,包括 ...

  8. 忧伤岁月，挡不住四季的温暖

    花儿,一朵朵凋零,绿叶,一片片枯萎,谁在秋天的时光里嗅到感伤的味道?谁又在古道西风瘦马里感受流浪的悲凉?谁是断肠人在天涯的主角?梦里,回首,看不清的背景,在岁月沉淀成一杯苦酒,一饮而尽,才知,我喝下了 ...

  9. 张驰课堂：老板会武术，谁也挡不住！六西格玛培训的魅力

    在一次聚会中,朋友告诉我一件令他很烦恼的事情,他最近在运作一个新项目,前天刚拿到工商注册,当晚就接到百度公司的客服电话,给他介绍百度推广业务,令他惊讶的是那位百度客服不但准确说出他的姓名,而且一字不差 ...

最新文章

  1. Golang内建库学习笔记（1）－sort和container
  2. GPass：GNOME 暗码治理器
  3. eclipse jdbc mysql下载_在eclipse里jdbc连接mysql 怎么安装
  4. YOLO v3解析与实现
  5. 使用代码执行organization unit determination逻辑
  6. 非常好用的轮播图插件
  7. 程序员必知--代码规范
  8. prometheus命令_Prometheus
  9. hd530黑苹果硬解_黑苹果案例之—笔记本核显HD515_520_530_540_550
  10. excel2007加载宏的两种方法
  11. 计算机网络（2.12）物理层- 宽带接入技术-FTTx技术
  12. 两步彻底关闭Windows默认共享文件夹（含IPC$）
  13. 9月7日冬瓜哥与你见面畅谈！
  14. SpringCloud项目搭建(六) —elastic-job的使用，以及consul的配置使用（衔接上篇）
  15. android仿ppt,android 仿ppt进入动画效果合集
  16. 微信小程序 php 手机授权登录
  17. JS中的indexof()解释
  18. line-height的理解
  19. 使用 python 写出诗一样的代码 (一)
  20. 寒假思雨姐摸底A题，题解

热门文章

  1. 第02篇：C#星夜拾遗之Windows窗体
  2. 在vue单页应用中使用jquery
  3. 《Internet 路由结构（第2版•修订版）》一7.5 常见问题
  4. Cocos数据篇[3.4](4) ——plist文件操作
  5. hdu 2871 Memory Control(线段树)
  6. Oracle数据库基础教程：入门其实很简单
  7. cognos report在做同比时遇到的问题解决方法
  8. InfoPath开发经验小节
  9. java基础File的简单使用记录
  10. runloop - 介绍