11月 152018
 

从下图来看,windows的powershell的死循环程序并没有占用100%的cpu,为什么?

原因: 这里的 12.39*8 ~= 100 ; 因为这个电脑是4核心8线程的,满负荷是800%,将800%折合成100%的话,100%就折合成12.38%左右,所以说,这里的12.38%就是一个核心的意思;

当启动到9个powershell死循环的时候,就不能再保证每个进程占用12%的cpu了:

 Posted by at 上午 10:58
10月 302018
 

以前的软件开发非常注重方法,注重质量,软件开发周期长。

现在的软件开发更注重快速迭代。

一个很重要的原因是:

以前的软件多是开发完卖出去的;

现在的软件大多是自己提供线上服务的;

所以:

对于前者,你不可能让客户每天部署一个新版本;

对于后者,发现问题可以及时修正,成本很小。

以前开发软件,更关心能用,可用。至于可维护性并不重要,毕竟复杂的维护还能收更多的维护费用呢。

 Posted by at 下午 6:40
9月 192018
 

缘起:

docker stop 时往往会比较慢,起原因多半是docker 容器的init进程没有正确处理信号所致;docker stop的行为为: 先发送一个SIGTERM(15) 信号给init进程,如果一段时间(默认10s)后,依然没有退出,就直接发送 -9 信号,常常我们会登上10s,最终,进程的退出依然是仓促的;所以,实现一个好的init进程非常重要。

想用bash写一个docker 的init进程,当收到SIGTERM信号时,通知容器中的其他进程退出,其他进程退出后自己再退出,这样的话,其他进程可以有时间优雅退出,而且stop操作还可能很快完成。

版本1:

实际并不凑效; 原因: bash 在执行外部命令的时候,是不处理信号的

 

改进:

不足:当有信号到时,依然要等sleep 睡足才能处理信号,如果每次sleep 时间足够短,则总是启动sleep进程也非常不优雅,本身总是看到一个sleep进程已经够闹心的了

 

改进:

优点:

  1. 看不到sleep函数了
  2. read line 并不消耗多少资源
  3. 虽然 read 函数是阻塞的,但是却不影响bash实时处理信号

缺点:

  1. 创建容器时需要 -it 选项,因为bash标准输入需要是正常的,才能是的read不会失败而正常阻塞,否则,read会一直失败,导致死循环占用100% CPU ; 安全一些的做法是,发现read失败直接退出

 

测试脚本:

执行该脚本,然后发送信号15给bash进程,发现:

  • 当执行到sleep 10 的时候,不能实时处理信号
  • 当阻塞在read时,可以实时处理信号
 Posted by at 下午 5:08