9月 032018
 

如图:

Local B想访问Remote B的80端口,但是由于网络限制,访问不到,但是,Local A可以访问Remote A的22端口,于是:

这样就可以在Local A上listen一个80端口,将接收到的数据包转发给Remote B的80端口

由于listen的端口在本地,所以叫做本地端口转发。

 

同样是Local A可以主动访问Remote A,但是Remote A不能ssh访问Local A,我们想让Remote B能访问Local B的80端口,如何做呢?(注意: 这里并不是上述逻辑的一个翻版)

命令:

这样就可以在Remote A上listen一个80端口,将接收到的数据转发到Local B的80端口;

由于listen的80在远端,所以叫远程端口转发

 

相关原理:

当通过端口转发创建虚线中的连接时,local A和remote A 之间并不会创建一个新的tcp连接,而是在原有tcp连接上创建了新的channel,这个可以在ssh 时 -vvvv看到相关信息

 Posted by at 下午 4:56
8月 242018
 

首先进入接口上下文:

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 转发到的内部的端口

 Posted by at 下午 2:58
8月 162018
 

现象:

只要访问指定的某个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文件

 

 

 Posted by at 下午 2:49
8月 152018
 

现象

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

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

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

问题1:

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

问题2:

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

难怪一直阻塞住不干活。

 

解决办法:

添加超时时间的配置:

 

问题:

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

翻代码看到的:

 

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

 

Redis 版本号

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

 Posted by at 上午 11:43
8月 062018
 

 

首先,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

 

 

参考:

 Posted by at 上午 11:40