PHPor 的Blog – 第18页

nginx if 语句

不能多重判断，错误写法如：

if ($uri = "/abc" && $arg_var = "xyz") { return 200 "good"; }

1
2
3

if ($uri = "/abc" && $arg_var = "xyz") {
return 200 "good";
}
不能嵌套，错误写法如：

if ($uri = "/abc") { if ($arg_var = "xyz" ) { return 200 "good"; } }

1
2
3
4
5

if ($uri = "/abc") {
if ($arg_var = "xyz" ) {
return 200 "good";
}
}
条件前件不能为字符串，只能为变量，错误写法如：

if ("$uri&&$arg_var" = "/abc&&xyz") { return 200 "good"; }

1
2
3

if ("$uri&&$arg_var" = "/abc&&xyz") {
return 200 "good";
}

相对简单可行的办法：

set $condition&nbsp;"$uri&&$arg_var";
if ($condition = "/abc&&xyz") {
    return 200 "good";
}

set $condition "$uri&&$arg_var";

if ($condition = "/abc&&xyz") {

return 200 "good";

}

还有不太严谨的做法：

if ($request_uri = "/abc?var=xyz") {
    return 200 "good";
}

if ($request_uri = "/abc?var=xyz") {

return 200 "good";

}

因为对于多数程序来讲， /abc?var=xyz 与 /abc?var=xyz&_=123456 是一样的，但是后者就不能被不严谨的nginx写法匹配到

实际用例：

            set $changePassWordUrl "$uri&&$arg__fromURL";
            if ($changePassWordUrl = "/hrm/HrmTab.jsp&&HrmResourcePassword") {
                return 302 "https://staff.beebank.com/password/forget";
            }

set $changePassWordUrl "$uri&&$arg__fromURL";

if ($changePassWordUrl = "/hrm/HrmTab.jsp&&HrmResourcePassword") {

return 302 "https://staff.beebank.com/password/forget";

}

现象

php 进程： THREAD_PHP_RD_\Service\Process\Deploy 不干活了，进程堆栈如下：

# pstack 157380
#0 0x00007f4396a440d8 in poll () from /lib64/libc.so.6
#1 0x0000000000745639 in php_sockop_read ()
#2 0x00007f438c90c601 in php_openssl_sockop_io () from /data1/php/lib/php/extensions/no-debug-non-zts-20121212/openssl.so
#3 0x000000000073aed4 in _php_stream_fill_read_buffer ()
#4 0x000000000073b073 in _php_stream_get_line ()
#5 0x00007f438c4d938f in redis_sock_read () from /data1/php/lib/php/extensions/no-debug-non-zts-20121212/redis.so
#6 0x00007f438c4db9dc in ps_write_redis () from /data1/php/lib/php/extensions/no-debug-non-zts-20121212/redis.so
#7 0x0000000000613090 in php_session_save_current_state ()
#8 0x00000000006143d6 in zm_deactivate_session ()
#9 0x0000000000787914 in zend_deactivate_modules ()
#10 0x0000000000722f45 in php_request_shutdown ()
#11 0x000000000083200f in do_cli ()
#12 0x0000000000833478 in main ()

# pstack 157380

#0 0x00007f4396a440d8 in poll () from /lib64/libc.so.6

#1 0x0000000000745639 in php_sockop_read ()

#2 0x00007f438c90c601 in php_openssl_sockop_io () from /data1/php/lib/php/extensions/no-debug-non-zts-20121212/openssl.so

#3 0x000000000073aed4 in _php_stream_fill_read_buffer ()

#4 0x000000000073b073 in _php_stream_get_line ()

#5 0x00007f438c4d938f in redis_sock_read () from /data1/php/lib/php/extensions/no-debug-non-zts-20121212/redis.so

#6 0x00007f438c4db9dc in ps_write_redis () from /data1/php/lib/php/extensions/no-debug-non-zts-20121212/redis.so

#7 0x0000000000613090 in php_session_save_current_state ()

#8 0x00000000006143d6 in zm_deactivate_session ()

#9 0x0000000000787914 in zend_deactivate_modules ()

#10 0x0000000000722f45 in php_request_shutdown ()

#11 0x000000000083200f in do_cli ()

#12 0x0000000000833478 in main ()

4个cli进程都阻塞在了这里；

大概意思为，PHP要回写session，先要一些其它交互，期望能读一行，但是，怎么也读不够一行，于是就死等

问题1：

如果没有什么意外的话，不应该让死等

问题2：

debug发现，这个stream的数据结构中，设置的超时时间为86400秒:

难怪一直阻塞住不干活。

解决办法：

添加超时时间的配置：

session.save_path = "tcp://127.0.0.1:6379?weight=1&timeout=3

1	session.save_path = "tcp://127.0.0.1:6379?weight=1&timeout=3

问题：

你问我gdb的时候是如何知道stream中如何获取超时时间的？如何知道stream->abstract 的真实数据类型的？

翻代码看到的：

注：还以为此事为偶发，进程刚刚工作几个小时就全部进入到了这个场景了,还好我解决了；其实，这并没有找到问题的根源，不找到原因的话，后续会有更加莫名其妙的的事情发生的

Redis 版本号

（然而现在该扩展已经开发到了4.x.y 了

Linux平台CPU利用率计算方法

http://www.blogjava.net/fjzag/articles/317773.html

进程因何而挂？挂在哪里了？

首先，nsenter想进入进程的名字空间看看都是失败的：

详细的关键信息如下：

看看进程在干啥：

wchan 显示不全，这样来看：

或者更直接的如下：

其实不知道为啥走到了这个系统调用，更好的办法：

直接看进程的内核栈：

大概是内存资源不太够吧，其实现在已经把进程从cgroup中迁移出来了，还是不行，给对应的cgroup添加更多的内存也是不行

试图将915的cpuset cgroup迁移到其它地方时，阻塞了，（难道某个事情没有完成时是不能切换cpu的？）,此时，连查看 /proc/915/cgroup 也要阻塞了：

此时也无法修改该cgroup的cpuset集合：

对应的该容器的xfs进程处于D状态：

/usr/lib/virtualbox/VirtualBox–commentzhiyong.man_172.16.162.7–startvm138fd168-b0ce-441e-9514-cf1145b6566e–no-startvm-errormsgbox
/usr/lib/virtualbox/VirtualBox–commentzhiyong.man_172.16.162.8–startvmbd1542ca-323b-4cde-99ee-17bc8ae48f63–no-startvm-errormsgbox
/usr/lib/virtualbox/VirtualBox–commentzhiyong.man_172.16.162.9–startvmef0063fc-e42d-4feb-beb4-6d86ab666ac1–no-startvm-errormsgbox
/usr/lib/virtualbox/VirtualBox–commentzhiyong.man_172.16.162.10–startvmbcdf6b3d-6909-4040-bd68-0753f5c1d89c–no-startvm-errormsgbox
/usr/lib/virtualbox/VirtualBox–commentwin7–startvm37305191-6f8b-498d-ac29-4155a838fca0–no-startvm-errormsgbox
/usr/lib/virtualbox/VirtualBox–commentzhiyong.man_172.16.162.6–startvm0a9902dd-fbc1-4228-8b7f-281a0c4158e9–no-startvm-errormsgbox

参考：

如何计算进程运行了多长时间了

办法1：使用ps命令

进程已经活了多长时间了（Age）：

# ps -o '%c %t %p' -p 31930
COMMAND ELAPSED PID
cobblerd 4-07:31:23 31930

# ps -o '%c %t %p' -p 31930

COMMAND ELAPSED PID

cobblerd 4-07:31:23 31930

这里的 %c %t 不太好记，直接man就好了，或者也可以：

# ps -o 'comm,etime,pid' -p 31930
COMMAND ELAPSED PID
cobblerd 4-07:32:47 31930

# ps -o 'comm,etime,pid' -p 31930

COMMAND ELAPSED PID

cobblerd 4-07:32:47 31930

关于ELAPSED 的格式： [[dd-]hh:]mm:ss

看来，这个格式是不能自定义的（比如：折合成秒），肉眼看起来还是非常友好的，但是，程序处理起来就不大方便（比如：比较大小，做减法等），当然，也可以写个脚本自己转换

办法2：

pid=31930
echo $(( ($(awk '{print $22}' /proc/self/stat) - $(awk '{print $22}' /proc/$pid/stat)) / $(getconf CLK_TCK)))

1 2	pid=31930 echo $(( ($(awk '{print $22}' /proc/self/stat) - $(awk '{print $22}' /proc/$pid/stat)) / $(getconf CLK_TCK)))

UPX – 可执行文件压缩工具

UPX 是一个可执行文件压缩工具不同于其他的压缩软件，它：

只压缩可执行文件
压缩后的可执行文件依然是可以直接执行的文件，功能和没压缩的一样
不需要额外的解压缩工具，因为压缩可执行文件相当于给可执行文件套了个壳儿，解压缩的功能已经在压缩后的文件里面了

用途：

给病毒文件加壳
压缩二进制文件，方便下载
压缩docker镜像中的可执行文件，提高镜像分发效率

源码：

https://github.com/upx/upx

参考：

https://mp.weixin.qq.com/s?__biz=MzAxMTA4Njc0OQ==&mid=2651435476&idx=1&sn=31b16966252d24d3a7e186279be08755&chksm=80bb6f26b7cce630a7b01fee5620a4f53f6e227d98c48f9b6d1ae5f8c5cc4ef5c6c598255871&scene=0&key=16d27a8f84411178ae99eb6f76f83e1e4c7d3ad39f281f817278f4e39e6bace31bedba7032b5f45027adaca0436271b8361db9d0f8654cebed5893efd57d0854b093565e3297734c6b7ab0e409b928a8&ascene=0&uin=MTI2MDg5MzEwMA%3D%3D&devicetype=iMac+MacBookPro12%2C1+OSX+OSX+10.12+build(16A323)&version=12020010&nettype=WIFI&lang=zh_CN&fontScale=100&pass_ticket=B4M1h2v40wmsZYTGlWbePmbUU0cAWkjCGezGw9XRAS5Z7KhPNVft2xSGraYk0CQE

阿里云SLB之内网调用问题

阿里云内网SLB使用：

ECS（A） —–> SLB(TCP) —–> ECS(B)

我们来看看数据包路径：

ECS（A）【 IP(A) –> IP(SLB) 】 ======> SLB (目的地址转换，源地址不转换） ========> ECS（B）【 IP(A) —-> IP(B) 】

那么， ECS（B）该如何回包呢？

因为ECS（B）认为数据包是从ECS（A）过来的，自然回包给ECS（A），而事实上ECS（B）是可以直接访问到ECS（A）的，于是乎，不经过SLB就直接回包了；那么，数据包到了ECS（A）能被认可吗？

~~当然不会，因为ECS（A）只知道给SLB发送过请求，不知道给ECS（B）发送过请求。~~

~~所以，对于这种情况，SLB的TCP模式是行不通的。同理，UDP模式也是不行的。~~

只要回包离开了ECS(B)，就会被SLB看到，就会被地址转换后在发送给ECS(A)，所以，这种场景是没问题的。

下面场景是有问题的：(如果SLB后面有多台机器，SLB就可以把来自A的请求转发到非A的机器上，自然也就没问题了)

ECS（A） —–> SLB(TCP) —–> ECS(A)

问题：

对于第一种场景，如果ECS（A）和ECS（B）不在同一个网段（似乎不行）也就算了，当ECS（A）通过SLB（tcp）访问ECS（B）时，会不会影响到ECS（B）上记录的ECS（A）的mac地址？

实际情况却是：

node-1(172.16.31.99) 和 node-2（172.16.31.100）以及gateway的mac地址都是一样的；如此看来，阿里的网络设备甚至操作系统都是定制的了？

bash 之变量声明周期

有些时候，我们通过如下方式执行命令：

var=1 cmd.sh

1	var=1 cmd.sh

这样，cmd.sh 中就能看到变量var ；但是千万别写成：

var=1 cmd.sh $var

1	var=1 cmd.sh $var

这里的 $var 绝对不是1；因为$var 是在var=1被解释之前解释的

如下：

如何从容器内部获取容器ID

办法1：

cat /proc/self/mountinfo

1	cat /proc/self/mountinfo

或

cat /proc/self/mounts

1	cat /proc/self/mounts

或

cat /proc/self/cgroup

1	cat /proc/self/cgroup

谁在占用带宽（h3c路由器）

通过路由器的 ip flow-ordering （IP 流量排名）来监视：

在接口上添加：

ip flow-ordering internal 或

ip flow-ordering external

再设置统计周期：

ip flow-ordering stat-interval 10 #10s

通过 display ip flow-ordering statistic external 或

display ip flow-ordering statistic internal 来查看

如：

参考：

https://wenku.baidu.com/view/18777fe85022aaea998f0ffe.html