ssh 之远程端口转发与本地端口转发

如图：

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

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

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

-f 选项： 后台执行

-N 选项： 不执行任何命令，仅仅是用于端口转发

 

同样是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看到相关信息

 

如果想要以daemon的形式只做端口转发，不想交互式的登录的远程机器，可以使用-f -N选项，如下：

如果想30分钟后失效，则可以：

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：

 

 

相关参考：