H3C 之 nat

首先进入接口上下文：

interface g0/1

对于nat出去的话，使用nat outbound 如：

nat outbound   #所有的地址都可以通过默认的ip地址出去

或

nat outbound [ $acl-number ]  [ address-group $address-group-number ]   #指定的acl 通过指定的地址组中的ip地址出去

 

 

对于nat进来的话，使用nat server 如：

nat server protocol tcp global $ip $port inside $in_ip $in_port

其中 ：

$ip  可以是该接口上的任意某个IP

$port 可以是任意希望暴露的端口

$in_ip  转发到内部的IP

$in_port 转发到的内部的端口

H3C 路由器之Qos

 

http://www.h3c.com/cn/d_201308/794662_30005_0.htm#_Toc364928020

 

 

acl 是符合一定规则的集合

流分类是符合一系列acl的集合

流行为是允许或不允许

Qos 是一组规则，说的是什么样的流分类执行什么样的流行为

最后可以在接口的上下文中应用预先定义好的Qos

Java webserver 内存爆炸Debug

现象：

只要访问指定的某个url，webserver就会很快死掉，直接原因是，内存消耗太多被oom

分析：

其实，这种问题多半是从数据库中一次查询太多数据所致，更直白说就是sql select查询时没有添加limit限制，基本没必要继续查，开发人员闭眼思考3秒就应该知道是哪条sql导致的了，多余的debug都是浪费时间。

但是，有些开发人员就觉得自己遇到了什么高深的bug似的，不见棺材不掉泪，不到黄河不死心，毕竟就算刻意让他写一个消耗内存的程序，都不见得能写出来，所以，下面就简述一下How to debug。

 

办法1：

通过sql-sniffer工具（或者mysqldump）抓包，看看请求都触发了哪些sql语句，一般也能看出来了。

 

办法2：

不断地jstack 该java进程，然后触发url请求，分析最后一次堆栈，通过进程死前的堆栈也能分析出来进程是死在哪里的

eg：

 

办法3：

通过ulimit -c 设置，让进程死时留下一个core文件，然后分析core文件

 

 

nginx if 语句

  • 不能多重判断，错误写法如：
  • 不能嵌套，错误写法如：
  • 条件前件不能为字符串，只能为变量，错误写法如：

相对简单可行的办法：

还有不太严谨的做法：

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

实际用例：

PHP redis session 阻塞问题

现象

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

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

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

问题1：

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

问题2：

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

难怪一直阻塞住不干活。

 

解决办法：

添加超时时间的配置：

 

问题：

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

翻代码看到的：

 

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

 

Redis 版本号

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

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

 

首先，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）：

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

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

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

 

办法2：

 

 

相关参考：

 

UPX – 可执行文件压缩工具

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

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

 

用途：

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

源码：

参考：

阿里云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地址都是一样的； 如此看来，阿里的网络设备甚至操作系统都是定制的了？