如何解决ksoftirqdcpu占用过高怎么解决高

查看: 12772|回复: 6
注册时间最后登录在线时间142 小时阅读权限90积分18225帖子主题精华0UID11240
237注册时间最后登录在线时间142 小时阅读权限90积分18225帖子主题精华0UID11240
本帖最后由 jack_cap 于
13:58 编辑
nginx 配置fastcgi缓存后 运行一段时间后 网站访问很慢
fastcgi配置
& && && && && &fastcgi_cache_path /usr/local/webserver/nginx/fastcgi_cache levels=1:2 keys_zone=TEST:10m& && && && && &inactive=5m;
& && && && && &fastcgi_cache&&TEST;
& && && && && &fastcgi_cache_valid&&200 302 10m;
& && && && && &fastcgi_cache_valid&&301 1h;
& && && && && &fastcgi_cache_valid&&any 1m;
& && && && && &fastcgi_cache_min_uses 1;
& && && && && &fastcgi_cache_use_stale error timeout invalid_header http_500;
& && && && && &fastcgi_cache_key& &http://$host$request_
top - 09:48:01 up 15 days,&&6:23,&&1 user,&&load average: 5.20, 3.57, 1.68
Tasks: 135 total,& &7 running, 128 sleeping,& &0 stopped,& &0 zombie
Cpu(s): 23.0%us, 77.0%sy,&&0.0%ni,&&0.0%id,&&0.0%wa,&&0.0%hi,&&0.0%si,&&0.0%st
Mem:& &4037424k total,&&4005688k used,& & 31736k free,& & 11748k buffers
Swap:&&8193140k total,& & 29740k used,&&8163400k free,&&3110980k cached
&&PID USER& && &PR&&NI&&VIRT&&RES&&SHR S %CPU %MEM& & TIME+&&COMMAND& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&
2344 www& && & 25& &0 87112&&26m&&944 R 52.9&&0.7& &3:00.25 nginx& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&
2345 www& && & 25& &0 87876&&27m&&944 R 46.6&&0.7& &2:02.18 nginx& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&
2346 www& && & 25& &0 87816&&27m&&952 R 33.3&&0.7& &2:04.64 nginx& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&
2347 www& && & 25& &0 &&556 R 33.3&&0.0& &1:55.31 nginx& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&
15408 www& && & 25& &0 87080&&26m&&824 R 32.6&&0.7& &2:54.90 nginx& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&
3207 www& && & 16& &0&&234m&&23m&&17m S&&0.3&&0.6& &0:03.50 php-cgi& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &
& & 1 root& && &15& &0 1&&544 S&&0.0&&0.0& &0:01.26 init& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &
& & 2 root& && &RT&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.03 migration/0& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&
& & 3 root& && &34&&19& &&&0& & 0& & 0 S&&0.0&&0.0& &0:24.96 ksoftirqd/0& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&
& & 4 root& && &RT&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.00 watchdog/0& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &
& & 5 root& && &RT&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.01 migration/1& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&
& & 6 root& && &34&&19& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.23 ksoftirqd/1& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&
& & 7 root& && &RT&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.00 watchdog/1& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &
& & 8 root& && &10&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.06 events/0& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&
& & 9 root& && &10&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.06 events/1& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&
& &10 root& && &10&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.01 khelper& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &
& &49 root& && &10&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.01 kthread& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &
& &54 root& && &10&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &0:02.86 kblockd/0& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &
& &55 root& && &10&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.07 kblockd/1& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &
& &56 root& && &14&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.00 kacpid& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &
&&167 root& && &14&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.00 cqueue/0& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&
&&168 root& && &14&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.00 cqueue/1& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&
&&171 root& && &10&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.00 khubd& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&
&&173 root& && &10&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.00 kseriod& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &
&&247 root& && &15& &0& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.00 khungtaskd& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &
&&250 root& && &10&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &2:09.73 kswapd0& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &
&&251 root& && &14&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.00 aio/0& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&
&&252 root& && &14&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.00 aio/1& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&
&&405 root& && &12&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.00 kpsmoused& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &
&&436 root& && &11&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.00 ata/0& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&
&&437 root& && &14&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.00 ata/1& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&
&&438 root& && &14&&-5& &&&0& & 0& & 0 S&&0.0&&0.0& &0:00.00 ata_aux& && && && && &
09:38:35 [alert] 2347#0: ignore long locked inactive cache entry b226444cefdeff92d196db, count:2
09:40:03 [error] 2345#0: *15167 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 124.126.178.250, server: , request: &GET /dede/index.php HTTP/1.1&, upstream: &fastcgi://unix:/dev/shm/php-cgi.sock:&, host: &&
09:42:08 [alert] 2342#0: worker process 2343 exited on signal 11
09:48:09 [alert] 2342#0: cache manager process 2347 exited on signal 9
09:48:09 [alert] 2342#0: worker process 15408 exited on signal 9
09:48:09 [alert] 2342#0: worker process 2346 exited on signal 9
09:48:09 [alert] 2342#0: worker process 2345 exited on signal 9
09:48:09 [alert] 2342#0: worker process 2344 exited on signal 9& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&
是什么原因造成的呢
还有反映一个问题本来想上传图片呢 可是试了N次失败告终
注册时间最后登录在线时间154 小时阅读权限70积分7563帖子主题精华0UID3391
金牌会员, 积分 7563, 距离下一级还需 2437 积分
注册时间最后登录在线时间154 小时阅读权限70积分7563帖子主题精华0UID3391
网站跑是什么应用,具体一点才能帮你分析问题
注册时间最后登录在线时间142 小时阅读权限90积分18225帖子主题精华0UID11240
注册时间最后登录在线时间142 小时阅读权限90积分18225帖子主题精华0UID11240
就跑网站后台
注册时间最后登录在线时间195 小时阅读权限90积分41435帖子主题精华0UID11974
注册时间最后登录在线时间195 小时阅读权限90积分41435帖子主题精华0UID11974
你清下nginx缓存试试
注册时间最后登录在线时间142 小时阅读权限90积分18225帖子主题精华0UID11240
注册时间最后登录在线时间142 小时阅读权限90积分18225帖子主题精华0UID11240
把 fastcgi_cache 配置去掉就好了 why!!!
注册时间最后登录在线时间15 小时阅读权限50积分1033帖子主题精华0UID730
高级会员, 积分 1033, 距离下一级还需 967 积分
注册时间最后登录在线时间15 小时阅读权限50积分1033帖子主题精华0UID730
我也遇到这个错误,但不是PHP,是perl程序,otrs
&&listen 8096;
&&server_name grandtec.net 10.167.26.6 myfreeke.gicp.
&&root /usr/local/otrs/var/httpd/
& && &&&access_log&&/usr/local/nginx/logs/otrs.nginx_access.
&&index index.
&&location /otrs-web {
& & alias /usr/local/otrs/var/httpd/
&&location ~ ^/otrs/(.*\.pl)(/.*)?$ {
& & #gzip makes scripts feel slower since they have to complete before getting gzipped
#& & fastcgi_pass&&unix:/.$1.
& & fastcgi_pass unix:/var/run/perl_cgi-dispatch.
#& & fastcgi_pass&&127.0.0.1:8999;
& & fastcgi_index index.
& & fastcgi_param SCRIPT_FILENAME& &/usr/local/otrs/bin/fcgi-bin/$1;
& & fastcgi_param QUERY_STRING& && &$query_
& & fastcgi_param REQUEST_METHOD& & $request_
& & fastcgi_param CONTENT_TYPE& && &$content_
& & fastcgi_param CONTENT_LENGTH& & $content_
& & fastcgi_param GATEWAY_INTERFACE CGI/1.1;
& & fastcgi_param SERVER_SOFTWARE& &
& & fastcgi_param SCRIPT_NAME& && & $fastcgi_script_
& & fastcgi_param REQUEST_URI& && & $request_
& & fastcgi_param DOCUMENT_URI& && &$document_
& & fastcgi_param DOCUMENT_ROOT& &&&$document_
& & fastcgi_param SERVER_PROTOCOL& &$server_
& & fastcgi_param REMOTE_ADDR& && & $remote_
& & fastcgi_param REMOTE_PORT& && & $remote_
& & fastcgi_param SERVER_ADDR& && & $server_
& & fastcgi_param SERVER_PORT& && & $server_
& & fastcgi_param SERVER_NAME& && & $server_
在IE中执行访问页面,就报504,
17:29:04 [error] 32153#0: *1 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 10.167.26.180, server: grandtec.net, request: &GET /otrs/installer.pl HTTP/1.1&, upstream: &fastcgi://unix:/var/run/perl_cgi-dispatch.sock:&, host: &10.167.26.6:8096&
注册时间最后登录在线时间267 小时阅读权限100积分46000帖子主题精华1UID9704
注册时间最后登录在线时间267 小时阅读权限100积分46000帖子主题精华1UID9704
之前我们也遇到类似的情况& &换了版本后重新编译安装php和nginx就好了
IT运维专家网感谢您的支持
合作联系: QQ:/MSN:/mail:netseek@linuxtone.org </s
Powered by微信公众号:centoscn
解决ksoftirqd进程耗尽单核100%si处理软中断导致性能瓶颈之法
Linux Virtual Server (LVS)之:ksoftirqd进程耗尽单核100%si处理软中断导致性能瓶颈
&&&& 最近测试LVS性能,发现当CPU其中一个核耗尽后系统达到性能顶峰。
&&&& 消耗CPU资源的是ksoftirqd进程,全部用于处理软中断(从进程名也能识别出了)。
&&& 搜了一下,很多人都遇到这类问题,似乎也没有解决。了解到并尝试过的解决方案有:
&&&&& 1、减少集群成员的数量;
&&&&& 2、修改集群模式(NAT、TURNL、DR);
&&&&& 3、修改集群调度算法;
&&&&& 4、升级操作系统内核到2.6.20以上;
&&&&& 5、调整网卡的最大传输单元(MTU);
&&&&& 6、修改设备中断方式;
&&&&& 7、使用多网卡负载均衡;
&&&&& 8、升级硬件(网卡);
&&&&& 9、更换操作系统。
&& 一一解说如下吧:
第1点:减少集群成员的数量。由于瓶颈不在真实服务器上,所以减少成员数量,lvs性能没有明显变化。
第2点:修改集群模式。理论上DR模式是最省资源的,大概了解理论的朋友应该都知道。由于NAT模式不满足需求,故仅对比了DR和TUN模式,两者没有明显区别。
第3点:修改集群调度算法。已有的十种算法中属rr最简单,而且目前瓶颈还未深入到这一层。实际上在处理网络包的时候导致的瓶颈。调度算法简单比较了rr和wrr,两者没有明显区别。
第4点:升级操作系统内核到2.6.20以上。我直接升级到当前已发布的最新版本2.6.34,结果瓶颈并没有得到改善。
第5点:调整网卡的最大传输单元。交换机支持最大的传输单元是9216,将网卡的最大传输单元分别修改为:1500(默认)、、9216。其中两者没有明显差别,会导致网络不稳定,性能也没有提高反而出现大量连接超时。
第6点:修改设备中断方式。通过修改设置中断/proc/irq/${网卡中断号}/smp_affinity:
测试服务器CPU为四核,理论上网卡的smp_affinity值为1、2、4、8分别对应cpu0、cpu1、cpu2、cpu3。
&&&&&&&&&&&&&&&& 1、网卡的smp_affinity默认值为8,测试过程中软中断全部由cpu3处理。正确
&&&&&&&&&&&&&&&& 2、设置smp_affinity = 1,测试过程中软中断全部由cpu0处理。正确
&&&&&&&&&&&&&&&& 3、设置smp_affinity = 2,测试过程中软中断全部由cpu1处理。正确
&&&&&&&&&&&&&&&& 4、设置smp_affinity = 4,测试过程中软中断全部由cpu2处理。正确
&&&&&&&&&&&&&&&& 5、设置smp_affinity = 5,测试过程中软中断全部由cpu0处理,预期应该分配给cpu0和cpu2处理。无效
&&&&&&&&&&&&&&&& 6、设置smp_affinity = f,测试过程中软中断全部由cpu0处理,预期应该分配给cpu0、cpu1、cpu2和cpu2处理。无效
&&&&&&& 即:修改smp_affinity的功能只针对单核有效。
第7点:使用多网卡负载均衡。此方案可行!使用两张网卡绑定一个IP地址,性能就提升了一倍,效果非常明显。原因就是两张网卡各用一个CPU核,相比用单核而言,性能自然提升一倍。
配置方式如下:
单网卡工作模式
# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
BROADCAST=192.168.223.255
HWADDR=00:1E:90:76:6F:E0
IPADDR=192.168.223.113
NETMASK=255.255.254.0
NETWORK=10.20.222.0
ONBOOT=yes
GATEWAY=192.168.222.1
TYPE=Ethernet
绑定双网卡操作步骤
echo &#39;alias bond0 bonding&#39; && /etc/modprobe.conf
# cat /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
BOOTPROTO=static
BROADCAST=192.168.223.255
MACDDR=00:1E:90:76:6F:E2
IPADDR=192.168.223.113
NETMASK=255.255.254.0
NETWORK=192.168.222.0
USERCTL=no
ONBOOT=yes
GATEWAY=10.20.222.1
TYPE=Ethernet
BONDING_OPTS=&mode=0 miimon=100&
# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
MASTER=bond0
BOOTPROTO=none
# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
USERCTL=no
ONBOOT=yes
MASTER=bond0
BOOTPROTO=none
# service network restart
第8点,升级硬件,使用支持RSS功能的网卡。
下面是intel对RSS的说明
Receive-side scaling (RSS) routes incoming packets to specific queues, efficiently balancing network loads across CPU cores and increasing performance on multi-processor systems. RSS, called Scalable I/O in Linux*, creates a hash table from IP, TCP, and Port Addresses and uses that table to decide which queue to route a packet to, and to which processor the packet should be associated.
可是从我们使用网卡的官网硬件指标上,都是支持RSS的。Windows的设置方式是`netsh int tcp set global rss=enabled`。
第9点,更换操作系统。此方案在生产环境下部署的可能性比较小,但是否关操作系统的事确实需要确认。
据说Windows的NLB、solaris、AIX支持网卡RSS,目前还有待确认
------分隔线----------------------------
CentOS对“OpenSSL Heartbleed高危安全漏洞”的修复方法,CentOS原生版,6.2/6.3; 默认...
(or type Control-Dto continue)...查看: 2314|回复: 7
nvr内存占用过大的问题
各位大神好!
我现在有个内存占用太大的问题。我的程序在设置视频缓冲池和一些公共参数后:
&&memset(&stVbConf, 0, sizeof(VB_CONF_S));
& & stVbConf.u32MaxPoolCnt& && && && & = 8;
& & stVbConf.astCommPool[0].u32BlkSize = ;& & //VGA
& & stVbConf.astCommPool[0].u32BlkCnt&&= 8;
& & memset(&stPubAttr, 0, sizeof(VO_PUB_ATTR_S));
& & stPubAttr.u32BgColor& &= 0x004BBCE6;
& & stPubAttr.enIntfType& &= VO_INTF_VGA /*| VO_INTF_HDMI*/;
& & stPubAttr.enIntfSync& &= VO_OUTPUT_;
& & stPubAttr.bDoubleFrame = HI_FALSE;
然后做些海思framebuffer的一些初始化操作,具体就是手册上的哪些,打开fb0、设置参数等。
程序运行后,我发现我的内存占用非常大
Mem: 51116K used, 14996K free, 0K shrd, 0K buff, 31932K cached
CPU:&&0.0% usr&&0.0% sys&&0.0% nic&&100% idle&&0.0% io&&0.0% irq&&0.0% sirq
Load average: 0.00 0.01 0.05 1/37 917
&&PID&&PPID USER& &&&STAT& &VSZ %MEM CPU %CPU COMMAND
&&917& &876 root& &&&R& &&&& &0&&0.0 top
&&916& &876 root& &&&S& & & &0&&0.0 ./nvr_project -qws&&876& &&&1 root& &&&S& &&&& &0&&0.0 -sh
& & 1& &&&0 root& &&&S& &&&& &0&&0.0 init
&&582& &&&1 root& &&&S && && &1&&0.0 udevd --daemon
& & 4& &&&2 root& &&&SW& && & 0&&0.0& &0&&0.0 [kworker/0:0]
&&306& &&&2 root& &&&SW& && & 0&&0.0& &1&&0.0 [kworker/1:1]
& & 9& &&&2 root& &&&SW& && & 0&&0.0& &1&&0.0 [ksoftirqd/1]
&&207& &&&2 root& &&&SW& && & 0&&0.0& &1&&0.0 [khubd]
& & 5& &&&2 root& &&&SW& && & 0&&0.0& &1&&0.0 [kworker/u:0]
&&886& &&&2 root& &&&SW& && & 0&&0.0& &1&&0.0 [flush-0:12]
&&176& &&&2 root& &&&SW& && & 0&&0.0& &0&&0.0 [sync_supers]
& & 2& &&&0 root& &&&SW& && & 0&&0.0& &1&&0.0 [kthreadd]
& & 3& &&&2 root& &&&SW& && & 0&&0.0& &0&&0.0 [ksoftirqd/0]
& & 6& &&&2 root& &&&SW& && & 0&&0.0& &0&&0.0 [migration/0]
& & 7& &&&2 root& &&&SW& && & 0&&0.0& &1&&0.0 [migration/1]
& & 8& &&&2 root& &&&SW& && & 0&&0.0& &1&&0.0 [kworker/1:0]
& &10& &&&2 root& &&&SW&& && &0&&0.0& &1&&0.0 [khelper]
& &11& &&&2 root& &&&SW& && & 0&&0.0& &1&&0.0 [kworker/u:1]
&&178& &&&2 root& &&&SW& && & 0&&0.0& &0&&0.0 [bdi-default]
可以看到内存占了96.7%,请问这是什么原因呐?
我一共256M的sdram,其中os给了72M,mmz给了184M。
256M? 你们自己做的板子么?不都是512M的么?视频缓冲池分配大了,还有frambuffer.
256M? 你们自己做的板子么?不都是512M的么?视频缓冲池分配大了,还有frambuffer.
我们买的板子,其实是512M的内存,但是说给用的只有256M,另外一半用不了,请问视频缓冲区和frambuffer应该按照什么比例分配,比如说就是256M的内存,应该分配多大呢?
Mem: 51116K used, 14996K free, 0K shrd, 0K buff, 31932K cached
这些内存是OS的内存,不是海思视频业务相关的内存
31932K cached 这块内存会随着你使用变化,cached内存和硬盘存储相关
系统真正使用的内存是51116K used
如果查看海思使用的内存,使用 cat&&/proc/umap/mediamem
我们买的板子,其实是512M的内存,但是说给用的只有256M,另外一半用不了,请问视频缓冲区和frambuffer应 ...
应用少的话,OS分配64M就可以了
应用少的话,OS分配64M就可以了
请问如果有内存泄露,是不是free的内存会越来越小,还是cached的内存会越来越小呢?
请问如果有内存泄露,是不是free的内存会越来越小,还是cached的内存会越来越小呢?
是这种现象
请问如果有内存泄露,是不是free的内存会越来越小,还是cached的内存会越来越小呢?
请问两个都小还是某个小?
Powered by博客访问: 902578
博文数量: 126
博客积分: 0
博客等级: 民兵
技术积分: 4587
注册时间:
将晦涩难懂的技术讲的通俗易懂
IT168企业级官微
微信号:IT168qiye
系统架构师大会
微信号:SACC2013
分类: LINUX
Linux系统中的知名内核线程(1)——ksoftirqd和events
——lvyilong316
我们知道linux系统中有很多系统创建的内核线程(kthread),这些内核线程是系统正常工作的保证。这里我们看下其中比较知名的两个:ksoftirqd和events。
1.&ksoftirqd
提到ksoftirqd就不得不说下“软中断(softirq)”,因为这个线程正是用来执行软中断的(准确的说应该是执行过多的软中断)。我们知道按照优先级来说,中断>软中断>用户进行,也就是说中断可以打断软中断,而软中断又可以打断用户进程。
而对于软中断,内核会在几个特殊的时机执行(注意执行和调度的区别,调度软中断只是对软中断打上待执行的标记,并没有真正执行),而在中断处理程序返回时处理是最常见的。软中断的触发频率有时可能会很高(例如进行大流量网络通信期间)。更不利的是,软中断的执行函数有时还会调度自身,所以如果软中断本身出现的频率较高,再加上他们又有将自己重新设置为可执行状态的能力,那么就会导致用户空间的进程无法获得足够的处理时间,因而处于饥饿状态。为了避免用户进程的饥饿。内核开发者做了一些折中,最终在内核的实现方案中是不会立即处理由软中断自身重新触发的软中断(不允许软中断嵌套)。而作为改进,内核会唤醒一组内核线程来处理这些过多的软中断,这些内核线程在最低优先级上运行(nice值是19),这能避免它们跟其他重要的任务抢夺资源,但它们最终肯定会被执行,所以这个方案能够保证软中断负载很重的时候,用户进程不会因为得不到处理时间而处于饥饿状态,相应的,也能保证过量的软中断终究会得到处理。&
每个处理器都有一个这样的线程。所有的线程的名字都叫做ksoftirq/n,区别在于n,他对应的是处理器的编号。
下面我们详细的看下软中断是如何被ksoftirqd执行的。首先看下软中断的处理调度过程。一个软中断在执行之前必须被调度(激活),术语称为"raise&the&softirq"。被激活的softirq通常并不会立即执行,一般会在之后的某个时刻检查当前系统中是否有被pending的softirq,如果有就去执行,linux执行软中断的函数是do_softirq(),而这个函数会再两个地方被调用,一个是中断返回时,另一个就是我们讨论的ksoftirqd内核线程。我们先来看中断返回的情况。
&1.1&irq_exit
//&do_IRQ&函数执行完硬件&ISR&后退出时调用此函数。&&&
void irq_exit(void)
&&&&&&&&&account_system_vtime(current);
&&&&&&&&&trace_hardirq_exit();
&&&&&&&&&sub_preempt_count(IRQ_EXIT_OFFSET); //这个位置修改preempt_count
&&&&&&&&// 判断当前是否有硬件中断嵌套,并且是否有软中断在 pending 状态,注意:这里只有两个条件同时满足时,才有可能调用 do_softirq() 进入软中断。也就是说确认当前所有硬件中断处理完成,且有硬件中断安装了软中断处理时理时才会进入。关于in_interrupt()后面会详细分析。
&&&&&&&&if (!in_interrupt() && local_softirq_pending())
&&&&&&&&&&&&&&&&// 其实这里就是调用 do_softirq() 执行
&&&&&&&&&&&&&&&&invoke_softirq();
&&&&&&&&preempt_enable_no_resched();
1.2&in_interrupt
&&&&这里需要重点分析一下in_interrupt()函数的含义。在linux内核中,为了方便判断当前执行路径在哪个上下文环境中,定义了几个接口:
#define hardirq_count() (preempt_count() & HARDIRQ_MASK)
#define softirq_count() (preempt_count() & SOFTIRQ_MASK)
#define irq_count() (preempt_count() & (HARDIRQ_MASK | SOFTIRQ_MASK | NMI_MASK))
&* Are we doing bottom half or hardware interrupt processing?
&* Are we in a softirq context? Interrupt context?
#define in_irq() (hardirq_count())
#define in_softirq() (softirq_count())
#define in_interrupt() (irq_count())
&* Are we in NMI context?
#define in_nmi() (preempt_count() & NMI_MASK)
& & & &&从注释可以看出包括:硬件中断上下文,软件中断上下文,不可屏蔽上下文等。在这些宏中,都涉及到了preempt_count()这个宏,这个宏是一个比较重要的宏,在Linux源码中对其做了详细的注释:
&* We put the hardirq and softirq counter into the preemption
&* counter. The bitmask has the following meaning:
&* - bits 0-7 are the preemption count (max preemption depth: 256)
&* - bits 8-15 are the softirq count (max # of softirqs: 256)
&* The hardirq count can in theory reach the same as NR_IRQS.
&* In reality, the number of nested IRQS is limited to the stack
&* size as well. For archs with over 1000 IRQS it is not practical
&* to expect that they will all nest. We give a max of 10 bits for
&* hardirq nesting. An arch may choose to give less than 10 bits.
&* m68k expects it to be 8.
&* - bits 16-25 are the hardirq count (max # of nested hardirqs: 1024)
&* - bit 26 is the NMI_MASK
&* - bit 28 is the PREEMPT_ACTIVE flag
&* PREEMPT_MASK: 0x000000ff
&* SOFTIRQ_MASK: 0x0000ff00
&* HARDIRQ_MASK: 0x03ff0000
&* NMI_MASK: 0x
&从注释可以看出,preempt_count各个bit位的含义:
(1)bit0~7位表示抢占计数,即支持最大的抢占深度为256
(2)bit8~15位表示软中断计数,即支持最大的软中断的个数为256,需要注意的是,由于软中断还受制于pending状态,一个32位的变量,因此实际最大只能支持32个软中断。
(3)bit16~25位表示硬件中断嵌套层数,即最大可支持的嵌套层次为1024,实际情况下这是不可能的,因为中断的嵌套层数还受制于中断处理的栈空间的大小。
&&&&&&介绍了这么多,现在了重点分析下上面提到的in_interrupt到底表示什么意思?
#define in_interrupt() (irq_count())
#define irq_count() (preempt_count() & (HARDIRQ_MASK | SOFTIRQ_MASK \
| NMI_MASK))
从其宏定义可以看出,in_interrupt宏的值是硬件中断嵌套层数,软中断计数以及可屏蔽中断三者之和。所以如果in_interrupt()的值大于0,就不会处理软中断,意思是(a)当有硬件中断嵌套,(b)或软中断被禁止&(c)不可屏蔽中断的情况下,不会去处理软中断。有人会问软中断不是从中断处理后irq_exit中进入的吗?那软中断执行时preempt_count的硬中断位不是还没有修改掉吗?其实已经做了修改,就在irq_exit函数中的sub_preempt_count中进行。其实执行过sub_preempt_count就算退出中断处理程序了。
l&注:软中断被禁止会增加软中断的计数;
__local_bh_disable((unsigned long)__builtin_return_address(0));
static inline void __local_bh_disable(unsigned long ip)
&&&&add_preempt_count(SOFTIRQ_OFFSET);
&&&&barrier();
# define add_preempt_count(val) do { preempt_count() += (val); } while (0)
1.3&do_softirq
&&&&下面重点分析以下do_softirq(),了解Linux内核到底是怎么来处理softirq的。
asmlinkage void do_softirq(void)
&&&&__u32 pending;
& &unsigned long flags;
&&&// 这个函数判断,如果当前有硬件中断嵌套,或者软中断被禁止时,则马上返回。在这个入口判断主要是为了与 ksoftirqd 互斥。
&&&if (in_interrupt())
& & & &return;
&&&// 关中断执行以下代码
& &local_irq_save(flags);
&&&// 判断是否有 pending 的软中断需要处理。
& &pending = local_softirq_pending();
&&&// 如果有则调用 __do_softirq() 进行实际处理
&&&if (pending)
& & & &__do_softirq();
&&&// 开中断继续执行
& &local_irq_restore(flags);
注意调用local_softirq_pending()获取pending和将pending请0这两个操作一定要位于关中断情况,否则两个操作间可能发生中断,中断再次调度软中段的置位标记会丢失。
真正的软中断处理再__do_softirq中。
1.4&__do_softirq
// 最大软中断调用次数为 10 次。
#define MAX_SOFTIRQ_RESTART 10
asmlinkage void __do_softirq(void)
&&&&// 软件中断处理结构,此结构中包括软中断回调函数。
& & struct softirq_action *h;
& & __u32 pending;
&&&&int max_restart = MAX_SOFTIRQ_RESTART;
&&&&int cpu;
&&&&// 得到当前所有 pending 的软中断。
& & pending = local_softirq_pending();
& & account_system_vtime(current);
&&&&// 执行到这里要禁止其他软中断,这里也就证明了每个 CPU 上同时运行的软中断只能有一个。
& & __local_bh_disable((unsigned long)__builtin_return_address(0));
& & trace_softirq_enter();
&&&&// 针对 SMP 得到当前正在处理的 CPU
& & cpu = smp_processor_id();
&&&&// 每次循环在允许硬件 中断强占前,首先重置软中断的标志位。
&&&&/* Reset the pending bitmask before enabling irqs */
& & set_softirq_pending(0); //要在关中断情况下才能调用
&& &// 到这里才开中断运行,注意:以前运行状态一直是关中断运行,这时当前处理软中断才可能被硬件中断抢占。也就是说在进入软中断时不是一开始就会被硬件中断抢占。只有在这里以后的代码才可能被硬件中断抢占。
& & local_irq_enable();
& &&// 这里要注意,以下代码运行时可以被硬件中断抢占,但这个硬件中断执行完成后,它的所注册的软中断无法马上运行,别忘了,现在虽是开硬件中断执行,但前面的 __local_bh_disable()函数屏蔽了软中断。所以这种环境下只能被硬件中断抢占,但这个硬中断注册的软中断回调函数无法运行。要问为什么,那是因为__local_bh_disable() 函数设置了一个标志当作互斥量,而这个标志正是上面的 irq_exit() 和 do_softirq() 函数中的in_interrupt() 函数判断的条件之一,也就是说 in_interrupt() 函数不仅检测硬中断而且还判断了软中断。所以在这个环境下触发硬中断时注册的软中断,根本无法重新进入到这个函数中来,只能是做一个标志,等待下面的重复循环(最大 MAX_SOFTIRQ_RESTART)才可能处理到这个时候触发的硬件中断所注册的软中断。得到软中断向量表。
& & h = softirq_vec;
& &&// 循环处理所有 softirq 软中断注册函数。
&&&&&&&&// 如果对应的软中断设置 pending 标志则表明需要进一步处理它所注册的函数。
&&&&&&&&if (pending & 1) {
&&&&&&&&&&&&// 在这里执行了这个软中断所注册的回调函数。
& & & & & & h->action(h);
& & & & & & rcu_bh_qsctr_inc(cpu);
&&&&&&&// 继续找,直到把软中断向量表中所有 pending 的软中断处理完成。
& & & & && &h++;
& & & & & &&// 从代码里可以看出按位操作,表明一次循环只处理 32 个软中断的回调函数。
& & & & & & pending >>= 1;
&&&&} while (pending);
&&&&// 关中断执行以下代码。注意:这里又关中断了,下面的代码执行过程中硬件中断无法抢占。
& & local_irq_disable();
&&&&// 前面提到过,在刚才开硬件中断执行环境时只能被硬件中断抢占 ,在这个时候是无法处理软中断的,因为刚才开中断执行过程中可能多次被硬件中断抢占,每抢占一次就有可能注册一个软中断,所以要再重新取一次所有的软中断。以便下面的代码进行处理后跳回到 restart 处重复执行。
& & pending = local_softirq_pending();
&&&&// 如果在上面的开中断执行环境中触发了硬件中断,且注册了一个软中断的话,这个软中断会设置 pending 位,但在当前一直屏蔽软中断的环境下无法得到执行,前面提到过,因为 irq_exit() 和 do_softirq() 根本无法进入到这个处理过程中来。这个在上面周详的记录过了。那么在这里又有了一个执行的机会。注意:虽然当前环境一直是处于屏蔽软中断执行的环境中,但在这里又给出了一个执行刚才在开中断环境过程中触发硬件中断时所注册的软中断的机会,其实只要理解了软中断机制就会知道,无非是在一些特定环境下调用 ISR 注册到软中断向量表里的函数而已。如果刚才触发的硬件中断注册了软中断,并且重复执行次数没有到 10 次的话,那么则跳转到 restart 标志处重复以上所介绍的所有步骤:设置软中断标志位,重新开中断执行...
// 注意:这里是要两个条件都满足的情况下才可能重复以上步骤。
&&&&if (pending && --max_restart)
& & & & goto restart;
// 如果以上步骤重复了 10 次后还有 pending 的软中断的话,那么系统在一定时间内可能达到了一个峰值,为了平衡这点。系统专门建立了一个 ksoftirqd 线程来处理,这样避免在一 定时间内负荷太大。这个 ksoftirqd 线程本身是个大循环,在某些条件下为了不负载过重,他是能被其他进程抢占的,但注意,他是显示的调用了 preempt_xxx() 和 schedule()才会被抢占和转换的。这么做的原因是因为在他一旦调用 local_softirq_pending() 函数检测到有 pending 的软中断需要处理的时候,则会显示的调用 do_softirq() 来处理软中 断。也就是说,下面代码唤醒的 ksoftirqd 线程有可能会回到这个函数当中来,尤其是在系统需要响应非常多软中断的情况下,他的调用入口是 do_softirq(),这也就是为什么在 do_softirq() 的入口处也会用 in_interrupt() 函数来判断是否有软中断正在处理的原因了,目的还是为了防止重入。ksoftirqd 实现看下面对 ksoftirqd() 函数的分析。
&&&&if (pending)
&&&&&&&&// 此函数实际是调用 wake_up_process() 来唤醒 ksoftirqd
& & & &&wakeup_softirqd();
trace_softirq_exit();
account_system_vtime(current);
// 到最后才开软中断执行环境,允许软中断执行。注意:这里使用的不是 local_bh_enable(),不会再次触发 do_softirq()的调用。
_local_bh_enable();
1.5&ksoftirqd
&&&&这个函数就是ksoftirqd内核线程对应的执行函数。只要有待处理的软中断(由softirq_pending()函数负责发现),ksoftirq就会调用do_softirq()去处理它们。通过重复执行这样的操作,重新触发的软中断也会被执行。如果有必要的话,每次迭代后都会调用schedule()以便让更重要的进程得到处理机会。当所有需要执行的操作都完成以后,该内核线程将自己设置为TASK_INTERTUPTIBLE状态,唤起调度程序选择其他可执行的进程投入运行。
static int ksoftirqd(void * __bind_cpu)
&&&&// 显示调用此函数设置当前进程的静态优先级。当然,这个优先级会随调度器策略而变化。
&&&&set_user_nice(current, 19);
&&&&// 设置当前进程不允许被挂启
&&&&current->flags |= PF_NOFREEZE;
&&&&//设置当前进程状态为可中断的状态,这种睡眠状态可响应信号处理等。
&&&&set_current_state(TASK_INTERRUPTIBLE);
&&&&// 下面是个大循环,循环判断当前进程是否会停止,不会则继续判断当前是否有 pending 的软中断需要处理。
&&&&while (!kthread_should_stop()) {
& & & &&// 如果能进行处理,那么在此处理期间内禁止当前进程被抢占。
& & & &&preempt_disable();
& & & &&// 首先判断系统当前没有需要处理的 pending 状态的软中断
& & & &&if (!local_softirq_pending()) {
&&&&&&&&&&&&// 没有的话在主动放弃 CPU 前先要允许抢占,因为一直是在不允许抢占状态下执行的代码。
&&&&&&&&&&&&preempt_enable_no_resched();
&&&&&&&&&&&&// 显示调用此函数主动放弃 CPU 将当前进程放入睡眠队列,并转换新的进程执行(调度器相关不记录在此)
&&&&&&&&&&&&schedule();
&&&&&&&&&&&// 注意:如果当前显示调用 schedule() 函数主动转换的进程再次被调度执行的话,那么将从调用这个函数的下一条语句开始执行。也就是说,在这里当前进程再次被执行的话,将会执行下面的 preempt_disable() 函数。当进程再度被调度时,在以下处理期间内禁止当前进程被抢占。
&&&&&&&&&&&&preempt_disable();
&&&&&&&&/*设置当前进程为运行状态。注意:已设置了当前进程不可抢占在进入循环后,以上两个分支不论走哪个都会执行到这里。一是进入循环时就有 pending 的软中断需要执行时。二是进入循环时没有 pending 的软中断,当前进程再次被调度获得 CPU 时继续执行时。*/
&&&&&&&&__set_current_state(TASK_RUNNING);
&&&&&&&&/* 循环判断是否有 pending 的软中断,如果有则调用 do_softirq()来做具体处理。注意:这里又是个 do_softirq() 的入口点,那么在 __do_softirq() 当中循环处理 10 次软中断的回调函数后,如果更有 pending 的话,会又调用到这里。那么在这里则又会有可能去调用 __do_softirq() 来处理软中断回调函数。在前面介绍 __do_softirq() 时已提到过,处理 10 次还处理不完的话说明系统正处于繁忙状态。根据以上分析,我们能试想如果在系统非常繁忙时,这个进程将会和 do_softirq() 相互交替执行,这时此进程占用 CPU 应该会非常高,虽然下面的 cond_resched()函数做了一些处理,他在处理完一轮软中断后当前处理进程可能会因被调度而减少 CPU 负荷,不过在非常繁忙时这个进程仍然有可能大量占用 CPU。*/
&&&&&&&&while (local_softirq_pending()) {
&&&&&&&&&&&&/* Preempt disable stops cpu going offline. If already offline, we’ll be on wrong CPU: don’t process */
&&&&&&&&&&&&if (cpu_is_offline((long)__bind_cpu))
&&&&&&&&&&&&&&&&/*如果当前被关联的 CPU 无法继续处理则跳转到 wait_to_die 标记出,等待结束并退出。*/
&&&&&&&&&&&&&&&&goto wait_to_die;
&&&&&&&&&&&&&&&&/*执行 do_softirq() 来处理具体的软中断回调函数。注意:如果此时有一个正在处理的软中断的话,则会马上返回,还记得前面介绍的 in_interrupt() 函数么。*/
&&&&&&&&&&&&&&&&do_softirq();
&&&&&&&&&&&&&&&&/*允许当前进程被抢占。*/
&&&&&&&&&&&&&&&&preempt_enable_no_resched();
&&&&&&&&&&&&&&&&/*这个函数有可能间接的调用 schedule() 来转换当前进程,而且上面已允许当前进程可被抢占。也就是说在处理完一轮软中断回调函数时,有可能会转换到其他进程。我认为这样做的目的一是为了在某些负载超标的情况下不至于让这个进程长时间大量的占用 CPU,二是让在有非常多软中断需要处理时不至于让其他进程得不到响应。*/
& & & & & & & & cond_resched();
& & & & & & & &&/* 禁止当前进程被抢占。*/
&&&&&&&&&&&&&&&&&preempt_disable();
&&&&&&&&&&&&&&&&/* 处理完所有软中断了吗?没有的话继续循环以上步骤*/
& & & & & &}
&&&&&&&&&&&&/*待一切都处理完成后,允许当前进程被抢占,并设置当前进程状态为可中断状态,继续循环以上所有过程。*/
& & & & & preempt_enable();
& & & & & set_current_state(TASK_INTERRUPTIBLE);
&&&&/*如果将会停止则设置当前进程为运行状态后直接返回。调度器会根据优先级来使当前进程运行。*/
&&&&__set_current_state(TASK_RUNNING);
&&&&return 0;
&&&&/*一直等待到当前进程被停止*/
wait_to_die:
&&&&/*允许当前进程被抢占。*/
&&&&preempt_enable();
&&&&/* Wait for kthread_stop */
&&&&/*设置当前进程状态为可中断的状态,这种睡眠状态可响应信号处理等。*/
&&&&set_current_state(TASK_INTERRUPTIBLE);
&&&&/*判断当前进程是否会被停止,如果不是的话则设置进程状态为可中断状态并放弃当前 CPU主动转换。也就是说这里将一直等待当前进程将被停止时候才结束。*/
&&&&while (!kthread_should_stop()) {
&&&&&&&&schedule();
&&&&&&&&set_current_state(TASK_INTERRUPTIBLE);
&&&&/*如果将会停止则设置当前进程为运行状态后直接返回。调度器会根据优先级来使当前进程运行。*/
&&&&__set_current_state(TASK_RUNNING);
&&&&return 0;
&&&&最后说明一下,因为tasklet也是通过软中断实现的,所以tasklet过多也会导致ksoftirqd线程的调度,进而再进程上下文中执行tasklet。(ksoftirqd执行软中断处理程序,tasklet对应的软中断处理程序执行所有调度的tasklet)
下面看events线程,提到这个线程就不得不说道“工作队列(workqueue)”了,这个线程是就是工作队了用来执行队列中的工作的。
2.1&什么是workqueue?
&&&&Workqueue也是linux下半部(包括软中断、tasklet、工作队列)实现的一种方式。Linux中的Workqueue机制就是为了简化内核线程的创建。通过调用workqueue的接口就能创建内核线程。并且可以根据当前系统CPU的个数创建线程的数量,使得线程处理的事务能够并行化。
&&&&是内核中实现简单而有效的机制,他显然简化了内核的创建,方便了用户的编程。
2.2&Workqueue机制的实现
&&&&Workqueue机制中定义了两个重要的数据结构,分析如下:
1.cpu_workqueue_struct结构。该结构将CPU和内核线程进行了绑定。在创建workqueue的过程中,Linux根据当前系统CPU的个数创建cpu_workqueue_struct。在该结构主要维护了一个任务(work_struct)队列,以及内核线程需要睡眠的等待队列,另外还维护了一个任务上下文,即task_struct。
2.&work_struct结构是对任务的抽象。在该结构中需要维护具体的任务方法,需要处理的数据,以及任务处理的时间。该结构定义如下:
struct work_struct {
& &&unsigned long pending;
& & struct list_head entry; /* 将任务挂载到queue的挂载点 */
& & void (*func)(void *); /* 任务方法 */
& & void *data; /* 任务处理的数据*/
& & void *wq_data; /* work的属主 */
& & strut timer_list timer; /* 任务延时处理定时器 */
&&&&&&&当用户调用workqueue的初始化接口create_workqueue或者create_singlethread_workqueue对workqueue队列进行初始化时,内核就开始为用户分配一个workqueue对象,并且将其链到一个全局的workqueue队列中。然后Linux根据当前CPU的情况,为workqueue对象分配与CPU个数相同的cpu_workqueue_struct对象,每个cpu_workqueue_struct对象都会存在一条任务队列。紧接着,Linux为每个cpu_workqueue_struct对象分配一个内核thread,即内核daemon去处理每个队列中的任务。至此,用户调用初始化接口将workqueue初始化完毕,返回workqueue的指针。
&&&&&&&在初始化workqueue过程中,内核需要初始化内核线程,注册的内核线程工作比较简单,就是不断的扫描对应cpu_workqueue_struct中的任务队列,从中获取一个有效任务,然后执行该任务。所以如果任务队列为空,那么内核daemon就在cpu_workqueue_struct中的等待队列上睡眠,直到有人唤醒daemon去处理任务队列。
&&&&&&&Workqueue初始化完毕之后,将任务运行的上下文环境构建起来了,但是具体还没有可执行的任务,所以,需要定义具体的work_struct对象。然后将work_struct加入到任务队列中,Linux会唤醒daemon去处理任务。
&&&&&&&上述描述的workqueue内核实现原理可以描述如下:
&&&&&&在机制中,提供了一个系统默认的队列——,这个队列是系统在初始化的时候就创建的。用户可以直接初始化一个对象,然后在该队列中进行调度,使用更加方便。
我们看到的events/0,events/1这些内核线程就是这个默认工作队列再每个cpu上创建的执行任务(work)的kthread。
&&&&有人会问,那我们如果自己创建工作队列呢?如果通过create_singlethread_workqueue来创建,那么只会产生一个kthread,如果使用create_workqueue创建,则和默认工作队列一样,在每个cpu上创建一个kthread,kthread的名字有参数传入。
l&Workqueue编程接口
用于创建一个队列,为系统中的每个都创建一个内核线程。输入参数:
用于创建,只创建一个内核线程。输入参数:
释放队列。输入参数:
:需要释放的队列指针
调度执行一个具体的任务,执行的任务将会被挂入系统提供的——输入参数:
:具体任务对象指针
延迟一定时间去执行一个具体的任务,功能与类似,多了一个延迟时间,输入参数:
:具体任务对象指针
:延迟时间
调度执行一个指定中的任务。输入参数:
:指定的指针
:具体任务对象指针
延迟调度执行一个指定中的任务,功能与类似,输入参数多了一个。
阅读(4380) | 评论(0) | 转发(2) |
相关热门文章
给主人留下些什么吧!~~
请登录后评论。

我要回帖

更多关于 磁盘占用率高如何解决 的文章

 

随机推荐