linux下sleep太频繁会不会有问题

我现在开发一款视频播发服务程序，按照视频码率进行播发视频。通过每20ms计算发包的数量来控制播发视频的码率，中间用的是nanosleep来做。操作系统是RHEL 6.1（32位系统），由于我播发了几十个视频，每个视频的播发都要用到nanosleep来控制码率，当连续播发几个小时候，我的播发程序cpu占用率突然变得不稳定，正常时是20%左右，但是一出现问题，就会从4%到30%之间频繁波动，波动幅度很大。用sar -n DEV 1查看网卡的发包情况，正常情况下会在15MB/s,当时一旦出现问题时，就会出现最小0MB/s,最大80MB/s的情况，而且每次都持续5分钟左右。已经做过以下测试：
1. 更换OS为RHEL 6.2， 问题依旧
2. 全部换成内存播发同一个问题，去除I/O因素， 问题依旧。
3. 减少几个视频，问题出现的间隔从几个小时变为几天，但是还是会出现
4. 更换一个好的CPU，连续测试了几天，没有问题

难道真的和CPU有关系？我觉得可能和sleep太频繁有一定的关系，但是没有理论根据。请问有人遇到过这样的问题吗？或者从这样的现象可以判断出问题可能出在哪里。我总觉得和程序没有太大关系，换了两台机器，只是CPU好了一点，都没有问题。

14 个解决方案

#1

不太清楚，要不用select模拟sleep试试？

#2

引用 1 楼  的回复:

不太清楚，要不用select模拟sleep试试？

我也想到这点了，正在测试~~希望可以解决问题，但是始终不知道问题的根源在哪里。
谢啦~

#3

与sleep太频繁有关系
写个死循环while(1){sleep(1)}cpu负载为1
一般cpu（单核）负载为3.5以上会不稳定。
cpu(24核)启动了1000个类似的程序，结果起来了400个，桌面鼠标全部卡了（不是不响应，是cpu忙不过来）

所以sleep()很费资源，慎重使用，查看你的负载是否过高。

#4

楼上的说法，有确定的依据吗？sleep和nanosleep的开销都大吗？我的程序里用的都是nanosleep啊！

#5

引用 1 楼  的回复:

不太清楚，要不用select模拟sleep试试？

nanosleep的机制与select阻塞的机制有什么区别啊？

#6

linux里的nanosleep不是真正精确到纳秒级的，大概是微秒吧，具体你可以搜索下。进程频繁切换会导致这样的问题

#7

引用 5 楼  的回复:

引用 1 楼  的回复:
不太清楚，要不用select模拟sleep试试？

nanosleep的机制与select阻塞的机制有什么区别啊？

同样求解~我测试了一下，好像select也是有问题的

#8

引用 3 楼  的回复:

与sleep太频繁有关系
写个死循环while(1){sleep(1)}cpu负载为1
一般cpu（单核）负载为3.5以上会不稳定。
cpu(24核)启动了1000个类似的程序，结果起来了400个，桌面鼠标全部卡了（不是不响应，是cpu忙不过来）

所以sleep()很费资源，慎重使用，查看你的负载是否过高。

我的nanosleep确实很频繁，但是CPU的负载只有20%左右，我的CPU是4核CPU，换到6核CPU上就没有这个问题，这个有理论根据吗？

#9

引用 6 楼  的回复:

linux里的nanosleep不是真正精确到纳秒级的，大概是微秒吧，具体你可以搜索下。进程频繁切换会导致这样的问题

我用线程做的，也有进程测试过，现象是一样的。这个问题不是很快就出现的，每次出现大概都要等上一天左右。。。

#10

我测试了一下，select做的sleep时间相当不准啊！sleep 5ms，经常到10ms左右，我用的是linux 2.6.18

#11

我测试的select还可以，内核是2.6.32，但是我把同样的程序换到2.6.18（RHEL 5.4）上运行，跑了接近3天没有发现问题，纳闷儿中~~~
不知道是不是RHEL 6.x的问题。。。难道越升级bug越多

#12

通过打印nanosleep的日志发现，当连续运行10个小时左右，nanosleep有时候会非常不准确，我一般设置的是20ms，但是出问题时已经sleep了1400多ms。RHEL 5.4上尚未发现这个问题，CPU好点这个问题出现的几率就小点。半个月跟踪得出的结论，悲剧啊~使用nanosleep的兄弟们注意下这个问题

#13

啊！会有这样的问题？幸亏我的2.6.18没有出过。。。。以后要注意下了，谢谢楼主

#14

2.6.18内核 时钟并不能精确到纳秒，nanosleep函数实际上是1us唤醒一次
2.6.32内核修复了这个问题，nanosleep可以真正每ns唤醒
所以同一个程序在2.6.18内核上没问题，在2.6.18内核上会因为唤醒过于频繁，导致cpu过高