9月 172019
 

php中参考的conf.d 目录是在编译时指定的,不能在运行时修改,如果非要修改,也不是不行,可以直接用sed来修改php这个二进制文件:

如果是签名或者有摘要校验的二进制文件如phar文件,则不能直接使用sed修改

由于学习swoole的时候,需要使用swoole扩展,但是偶尔又想单步调试一些逻辑,不得不使用xdebug扩展,但是swoole扩展和xdebug扩展势不两立,有不能通过参数来切换是否使用xdebug,于是通过此法搞了两个php二进制文件,二者使用不同的conf.d 目录,就可以单独配置扩展了。

但是phpstorm中单个项目不能同时使用两个php解释器,只好在使用时临时切换php解释器了

 Posted by at 下午 5:13
9月 102019
 

A进程总是连接B进程listen的1158端口,而且连接到断开的持续时间很短,由于知道1158端口,所以,B进程很容易被找到,现在不知道A进程是哪个,只知道是本机的某进程来连接1158端口的。

如何找到A进程呢?

对于持续时间不太短的连接,我们通常可以使用ss -anp来查看,但是对于持续时间足够短的连接,ss是不太容易抓到的。毕竟,当机器上进程数多的时候,每个连接都扫一遍所有的进程下的fd,会明显感觉很慢的。

所以,一种办法是:

不使用ss的-p选项,只使用ss -an,从结果中拿到感兴趣的端口后,再去/proc/*/fd/* 中找对应的fd,但是,进程的fd中对应的socket的id并不出现在ss的结果中,无法对应起来。

另一种办法:

直接去 /proc/net/tcp 中查找感兴趣的连接,基本逻辑如下:

其中的 :0486 是我们感兴趣的端口号的16进制表示, 23774779 是我们不感兴趣的连接

 

其实,这样也未必能抓到感兴趣的连接,毕竟连接消失的太快。

比较靠谱的办法是:

让B进程休眠,这样,A进程进入的连接不能被及时处理,就不会立即断开,然后使用ss -anp就可以了,除非A进程设置了非常短的超时,那么,可能我们就需要研究一下systemtap了

 

 Posted by at 下午 1:52
8月 142019
 

https://docs.zephir-lang.com/0.12/en/motivation

zephir是为开发PHP扩展而发明的一门语言,而且只能用来开发PHP扩展,通常,PHP的扩展都是编译运行的,但是zephir却是把自己编译成字节码给zend解释执行的,但是他也能进一步编译成机器语言
Zephir was not created to replace PHP or C. Instead, we think it is a complement to them, allowing PHP developers to venture into code compilation and static typing. Zephir is an attempt to join good things from the C and PHP worlds, looking for opportunities to make applications faster.

只能写带名字空间的class
Code in Zephir must be placed in classes. The language is intended to create object-oriented libraries/frameworks, so code outside of a class is not allowed. Additionally, a namespace is required:

他可以直接调用PHP语言定义的函数

必须写注释:

In most languages, comments are simply text ignored by the compiler/interpreter. In Zephir, multi-line comments are also used as docblocks, and they’re exported to the generated code, so they’re part of the language!

If a docblock is not located where it is expected, the compiler will throw an exception.

zephir相当于是跑在zend上的另一门语言

 Posted by at 下午 8:22
7月 262019
 
  1. 实时查看系统正在派生哪些进程:
  2. 实时查看系统正在打开哪些文件:
  3. 实时查看哪些进程在访问IO以及IO延迟:
  4. 更加方便地分析IO延迟:
  5. 查看IO请求的块儿大小分布情况:
  6. cache大小及命中率分析:
  7. 系统调用次数分析:
  8. 查看tcp连接异常:
  9. 查看慢的内核函数调用:
 Posted by at 下午 5:40
7月 262019
 

实用的脚本:

脚本基本逻辑是:

  1. 连接数据库
  2. 获取所有表的表名
  3. 然后做想做的事(如:导出表数据)

脚本很简单,但是,还是写出问题来了

其实,短短的代码里面藏着很多知识呢

上述的错误的写法之所以错,是因为db2进程的PPid不是当前的bash,但是和正确的写法差别不大呀,为什么PPid就不一样了呢? 可以参考: https://phpor.net/blog/post/12836

为什么db2 那么关心PPid ?可以参考:https://phpor.net/blog/post/12806

 Posted by at 下午 4:27
7月 262019
 

场景:

想执行一个命令,如果命令成功,则不输出任何信息,如果命令失败,输出错误信息;

 

通常来讲,特别简单:

就行; 但是,如果 $cmd 会通过标准错误输出一些debug信息呢?这样的话,即使命令成功也会看到一些不必要的信息,那么如何改进呢?

基本思路就是,把标准输出扔掉(可选),标准错误重定向到标准输出,然后赋值给一个变量:

这个没有问题;

但是,当我们试图把这个逻辑写到函数中时,似乎就不太对了,因为函数中的变量尽量local声明,而且,声明和赋值写在一起显得紧凑、美观、有修养;如下:

这是,和我们预期不一样了 ; $? 已经不是no_such_cmd 的返回值了,为什么?

参看下面截图:

显然,第一个函数中 $? 其实是local语句的返回值了(local的返回值和变量被赋了什么值没有关系,参看: help local),所以,正确的姿势是,先声明变量,再使用

 Posted by at 下午 2:16
7月 252019
 

问题:

db2 connect to XXX   究竟做了什么,使得 后续的db2 进程就知道自己当前上下文的数据库是XXX ?而且,不同的bash进程下都有自己单独的上下文,不相互影响。

 

  1. 如果不考虑多个bash之前的相互影响,则,进程间共享信息的办法有很多,比如: 文件;
  2. 但是db2在不同的bash中分别db2 connect to 是不相互影响的,如果不是文件又是什么呢?

分析:

  1. 在db2 connect to 之后,执行:
    strace -fF -o /tmp/strace.txt db2 list tables

    1. 很不幸:进程hang住,不退出了
    2. 很庆幸,我正好可以看看当前db2 在干啥
      1. 通过ps找不到db2 list tables进程
      2. 分析strace.txt:

        26900 进程就是db2 list tables ; 不过该进程早就离开了,从下图可以知道,该进程是生了26901后离开的

        然而,当我们回过神儿来的时候,26901也不见了,因为 26901 干的活也不多:

        26901 基本也就是生了个26902 就完事儿了,26902 是我们目前还能够看到的一个进程,就是:

        strace.txt 中是这样子的:

        26902 进程当前是在执行msgrcv:

        也就是说,每一个db2总是会化身成db2bp来工作的,而这个999718998 又是个啥?

        ipc就是linux上进程间通信的机制,有三种方式: 共享内存、消息队列、信号量,都可以通过ipcs 查看,这里看到的999718998就是消息队列


        可以进一步查看该消息队列的详细信息:

        通过ipcs 我们可以发现db2大量使用了共享内存、消息队列、信号量,都用到了,其实,这扯的有点远了
        回来我们发现db2bp是一个重要的进程,真正要连数据库的应该就是这个进程,该进程如何知道要连接那个数据库呢?
        我们发现db2bp进程有3个参数,其中第一个参数的前一个部分 26895 正好是strace进程的进程ID:

        这难道是巧合,其实不然,我们从一个新的bash中执行db2 connect to 就会产生一个db2bp进程:

        而且该进程的参数中就包含当前bash进程的进程ID的,所以,该进程一定是db2 connect to 催生的,但是确实没有随着db2 进程的退出而死亡,所以,db2bp 是一个声明期很长的进程,这也是上面的strace没有能立即退出的原因所在;因为,strace跟踪的db2进程是在一个新环境中执行的,没有找到对应的db2bp进程,所以就启动一个db2bp进程,这里也可以顺便得出两个推论:
        1.  db2bp 进程不是只有db2 connect to 才会创建的,哪怕简单敲一个db2后回车都会催生对应的db2bp进程的,而且不会随着quit的执行而退出
        2. db2bp 进程并不是一定就已经在connect着某个数据库的,主要是服务于db2 进程的
        3. 尽管没有执行过db2 connect to ,如果我们执行过db2 的其它命令,也有必要db2 terminate ,这样才能使得db2bp 进程退出(事实上,db2bp足够聪明,可以在bash退出的时候退出的)
        4. db2 connection reset 和 db2 terminate 的区别也是毕竟明显的,前者断开连接,后者退出db2bp进程
        下图证明db2 terminate 可以结束db2bp进程:

        关于db2 terminate 的更多细节可以参考: https://www.ibm.com/support/knowledgecenter/en/SSEPGG_10.5.0/com.ibm.db2.luw.admin.cmd.doc/doc/r0001973.html
      3. 通过上述的分析,我们是不是可以推测,db2的上下文环境是通过父进程(当前shell)的PID来标识的呢?我们分析一下:
        1. 我们知道bash中可以通过圆括号让进程在新的子shell中执行的,如下:
        2. 然而,我们在db2 connect to 之后,不管是否把db2放在圆括号中都是可以的:

          所以说,是不是可以得出结论:db2 的环境不仅仅是根据ppid来定义的。错,db2的环境确实是根据其ppid来定义的,参考: https://www-01.ibm.com/support/docview.wss?uid=swg21983930  ; 那么,上面圆括号的问题又如何解释呢? 参考: https://phpor.net/blog/post/12836
        3. 虽然基本已经水落石出了,但是难道就真的没法strace跟踪了吗?(因为strace总是给db2 执行一个新的环境)
        4. 其实,我们可以strace跟踪db2所在的bash进程
          1. 通过strace分析发现,主要通过msgsnd msgrcv msgget 来通过消息队列来实现和db2bp之间的进程通信的,而且消息队列的ID和进程的PPID有直接关系:

            至于如何根据PPID算出msgget需要的key的,这个就需要看源码了,据说是hash出来的,那么,如果是terminate之后再执行db2 list tables 会是什么样的strace结果呢,看下图:

            我们发现ppid是一样的,uid是一样的,msgget的key也是和上次一样的,只是这次get不到了,然后下面的逻辑就变了,就会去催生一个db2bp出来,这次的命令执行就会慢一些了
 Posted by at 下午 3:48