Bash 的知识点向来比较凌乱，有时候写点小脚本，你忘记了条件判断怎么写了，就打开网页搜索一半天；忘记怎么分割字符串，又搜索一半天；忘了怎么解压缩某后缀名，又打开网页搜一半天。
关键大部分搜出来的东西都十分琐碎，东一处，西一处，质量又参差不齐，而且看到一处有些细节有疑问，你还得接着搜索。
连记点笔记也是这一篇那一篇的，用起来找来找去的十分不爽，所以我一怒之下春节期间整理了一份 bash 的 cheatsheet，以图以后有关于 bash 的事情就查看这个文件就够了：
https://github.com/skywind3000/awesome-cheatsheets/blob/master/languages/bash.sh
对于一些工具性的东西，有时候一份速查表比你翻书查网页都高效数倍。
—
相关阅读：
无数次被问道：你在终端下怎么调试更高效？或者怎么在 Vim 里调试？好吧，今天统一回答下，我从来不在 vim 里调试，因为它还不成熟。那除了命令行 GDB 裸奔以外，终端下还有没有更高效的方法？能够让我事半功倍？
当然有，选择恰当的工具和方法，让 GDB 调试效率成倍的提升并没有任何问题。当然，前提条件是你至少会在使用最原始的 GDB。
穿上各种衣服前，至少得先学会裸奔，找份简单的 GDB cheat sheet 对照一下：
生产环境中出现崩溃时，因线上服务器一般没有开发环境，也无配套源代码，所以程序崩溃后，如果你懒得把 core 文件拖回到开发机检查，可以先在线上服务器先简单gdb看一下。
GDB命令密密麻麻，常用的也就表格上那几条，比如进去以后第一步先用 bt 查看一下调用栈，info local查看一下本地变量，再配合 up/down 在整个调用栈的不同层次之间上下移动一下，检查各处局部变量的值，print 一下某个表达式，即便没代码，看下符号和反汇编，一般也能调试个七七八八。
碰到复杂点的 BUG，必须配合源代码了，那你得把 core 文件拉到开发环境中，再用 gdb 对照源代码调试，配合 list [行号] 指令查看当前运行的源代码，再配合其他方法进行调试。
那么这时候，如果调试复杂度继续上升，你需要不断的断点，每次 next / step 单步完后你都需要 list 一下前后源代码，或者用 disassemble [函数名/地址] 查看一下指令的话，不少人会感觉到抓狂，这时我们需要给裸奔的 GDB 穿条内裤了。
这是 gdb 自带的文本界面，使用 gdb -tui 命令启动，比如：
gdb -tui hello
即可打开我们的文本界面：
上方是源代码窗口，下面是 gdb 终端，窗口管理快捷键模仿 emacs，使用 c-x o 进行窗口切换，如果你还想查看指令窗口，可以输入：layout split
然后你单步的时候上面的源代码窗口会跟着滚动，比之前不停的 list 方便不少吧，要看前后源代码可以继续 c-x o 切换窗口后上下滚动。
有时候你 up/down 切换了栈帧后，上面的代码也许来不及更新，那么你用 update 指令，让上面的代码窗口定位到你最新的执行位置，有时也需要 CTRL-L 重绘下整个界面。
在 gdb 自带的 tui 模式中，你不但可以随时查看代码/指令，还可以查看寄存器。好吧，其实 gdb再简陋，本身还是配套了一条内裤的，只是很多人忘记拿出来穿了。
如果上述文本 TUI的信息不够丰富的话，也许你会对 .gdbinit 感兴趣，~/.gdbinit 是一个 gdb配置脚本，可以设定一些由 python 编写的插件，比如 peda：
在 ~/.gdbinit 上面配置了 peda 后，可以看到命令提示符就从 (gdb) 变成了 gdb-peda$ 。每敲一个单步命令，peda 都会显示出无比丰富的信息，你还可以配置添加更多，配合高亮，你可以得到一个加强版的命令行。
不过这个我用的并不多，因为它会影响 TUI 模式的界面，我不喜欢在我的 gdb 里搞太多乱七八糟的东西。同时，当我们的调试需求继续变得更加复杂，你要不停的断点，频繁的单步，这些传统命令行里不停的输入各种指令显然已经让我们疲惫不堪了，能否直接在界面上查看源代码并且直接在代码上快捷键断点，快捷键单步呢？
可以啊，试试 cgdb。
CGDB 类似 gdb tui 分为终端窗口和代码窗口：
早年开发工作主要在 FreeBSD进行，2006年后来切换到 Linux下，期间穿插使用了一下 Solaris，所以我的网络库一直都是只支持这三个系统。为了让网络库支持更多平台，网上购置了一台 IBM AIX 小型机，因为其他大部分非 Linux系统，今天基本都可以在虚拟机里面安装了，而 AIX系统，你真的没法虚拟。
弄了几天以后，发现真他妈的麻烦，强大是强大，但是真的太琐碎了，相比之下，Linux/FreeBSD之流基本是傻瓜了。不看说明直接操作 AIX的话，可能连开机都麻烦，或者关机没关对，下次直接启动不了。
文字终端就没什么好拍的了，先上一张图形桌面的靓照吧：
是的你没看错，这就是 AIX 7，2012年的操作系统，就是那么的霸道，四处透着古典 Unix的味道。这样的机器今天还跑在各大银行的机房里，AIX系统管理员也拿着比 Linux系统管理员多几倍的工资，虽然工作岗位比较稀少。
下面来感受一下你想正常开关机，安装软件的话要怎么弄：
在公司机房的物理机上架设 KVM虚拟化的时候，经常需要配置网桥，先要安装网桥工具：
apt-get install bridge-utils apt-get install uml-utilities
编辑 /etc/network/interfaces，参考下面配置加入网桥配置信息：
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
auto br0
iface br0 inet static
address 192.168.10.6
netmask 255.255.255.0
network 192.168.10.0
broadcast 192.168.10.255
dns-search dell1
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxwait 0
auto eth1
iface eth1 inet manual
auto br1
iface br1 inet static
address 14.152.50.6
netmask 255.255.255.192
network 14.152.50.0
broadcast 14.152.50.63
gateway 14.152.50.1
bridge_ports eth1
bridge_stp off
bridge_fd 0
bridge_maxwait 0
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 114.114.114.114
dns-search dell1
auto eth2
iface eth2 inet manual
auto br2
iface br2 inet static
address 112.93.114.2
netmask 255.255.255.224
network 112.93.114.0
broadcast 112.93.114.255
gateway 112.93.114.1
bridge_ports eth2
bridge_stp off
bridge_maxwait 0
dns-nameservers 114.114.114.114
dns-search dell1
上面配置针对双线接入多 IP的情况，这样 br0-br2就可以给虚拟机 guest使用了，br0是内网，br1-br2是电信或者联通出口。
前段时间折腾家中 Nas的虚拟化服务，有时候虚拟机系统时间总是快8个小时。Guest这边设好了，到了 物理机就会慢8个小时。网上说只要修改/etc/default/rcS中的 UTC=no就行了，但还是没反映，没办法，一步步找问题。发现在/etc/rcS.d/S05hwclock.sh有这样一段话：
# 2012-02-16 Roger Leigh rleigh@debian.org # - Use the UTC/LOCAL setting in /etc/adjtime rather than # the UTC setting in /etc/default/rcS. Additionally # source /etc/default/hwclock to permit configuration.
也就是说时间是按照/etc/adjtime设置的，而不是/etc/default/rcS，晕倒。查了下adjtime文件，原来这个才是现在调整时间的设置文件，那个rcS已经被忽略了，也就是网上的那些方法只适合以前的系统，看来走了不少弯路啊。
将 /etc/adjtime 第三行由 UTC 改为 LOCAL 即可。
大公司呆久了，都会对 SA的依赖十分强烈，很多事情 SA都帮我们搞定了。如今控制成本，没有招聘 SA，又没有购买 VPS，从买物理机开始到 IDC部署，服务器调优，虚拟机管理，全部都是自己来，才发现，安装一台 Linux机器自己玩很简单，但是要达到线上服务器的标准，还有若干调优工作需要做，有 SA的日志是多幸福的事情啊。
物理机设备驱动
Dell服务器默认安装系统后会报找不到驱动:
W: Possible missing firmware /lib/firmware/tigon/tg3_tso5.bin
因为 Debian/Ubuntu 的包都是开源的，默认开源驱动性能不行，于是需要添加 non-free源：
deb http://ftp.de.debian.org/debian main contrib non-free deb-src http://ftp.de.debian.org/debian main contrib non-free
然后：
apt-get update apt-get install firmware-linux-free firmware-linux-nonfree
解决 Dell驱动报错问题。
配置限制
查看 /etc/security/limits.conf 没有就新建，加入 core 和 nofile 的相关配置，比如：
* soft nofile 65536 * hard nofile 65536 * soft core unlimited * hard core unlimited # End of file
之类的，不用到 ~/.bashrc 里面调用 ulimit。
网卡多队列
打开内核网卡多队列支持，避免网卡中断都集中在 cpu0 上处理，多队列打开后，可以让网卡中断均摊到各个 cpu上，对提高并发十分有用：
wget http://skywind3000.github.io/install/set_irq_affinity.sh
放到 /etc/config 目录下面（没有就新建），然后在 /etc/rc.local 里面加一行，每次重启就跑 set_irq_affinity.sh 且必须用 bash跑，参数传入需要开启多队列的网卡，以下是 /etc/rc.local 的内容：
/bin/bash /etc/set_irq_affinity.sh eth0 eth1 eth2 exit 0
下面是 setirqaffinity.sh 的代码：
经常需要对服务端的端口进行转发映射，让链接A服务器（202.181.55.93：8080）端口的所有tcp数据，forward到B服务器（106.185.43.22:80）端口，比如国内联通出国访问比较快，而电信比较坑爹，如果你家是电信网络，你却想畅快的访问境外的 vps，那么可以在你联通网络的境内服务器上进行这样一个端口映射，你链接境内服务器（201.181.55.93:8080）端口相当于链接境外服务器的（106.185.43.22:80）端口。
Linux内核的 Iptables很强大，它维护一组内核变量，使用 /sbin/iptables命令进行直接规则设置，且通过配置新规则，可以直接支持端口转发，简单在 A服务器上使用下面这个 shell脚本即可：
#! /bin/sh
# create forward rule by source interface
# http://serverfault.com/questions/532569/how-to-do-port-forwarding-redirecting-on-debian
PortForward1() {
local IN_IF=$1
local IN_PORT=$2
local OUT_IP=$3
local OUT_PORT=$4
local IPTBL="/sbin/iptables"
echo "1" > /proc/sys/net/ipv4/ip_forward
$IPTBL -A PREROUTING -t nat -i $IN_IF -p tcp --dport $IN_PORT -j DNAT --to-destination ${OUT_IP}:${OUT_PORT}
$IPTBL -A FORWARD -p tcp -d $OUT_IP --dport $OUT_PORT -j ACCEPT
$IPTBL -A POSTROUTING -t nat -j MASQUERADE
}
# create forward rule by source ip
# http://blog.csdn.net/zzhongcy/article/details/42738285
ForwardPort2() {
local IN_IP=$1
local IN_PORT=$2
local OUT_IP=$3
local OUT_PORT=$4
local IPTBL="/sbin/iptables"
echo "1" > /proc/sys/net/ipv4/ip_forward
$IPTBL -t nat -A PREROUTING --dst $IN_IP -p tcp --dport $IN_PORT -j DNAT --to-destination ${OUT_IP}:${OUT_PORT}
$IPTBL -t nat -A POSTROUTING --dst $OUT_IP -p tcp --dport $OUT_PORT -j SNAT --to-source $IN_IP
}
PortForward1 eth3 8080 106.185.43.22 80
# put this file on /etc/network/if-up.d
上面两个函数，一个是针对网卡，一个是针对本地IP设置转发，记得把这个脚本放到 /etc/network/if-up.d 下面并设置可执行权限（Debian/Ubuntu），每次开机重启时保证可以运行，即可。
现在很多人一提高性能后端开发，就总会想起 EPoll 来。其实一个成熟的高性能服务器，epoll相关的代码，不到万分之一。
而往往入门服务端的人，都天真的人为：高性能服务端开发 == EPOLL，真好笑，之所以会出现 epoll这种被捧上天的垃圾，明明就是 posix 或者最早版本的 unix/bsd/systemv 的设计考虑不完善。
按今天的眼光反思 posix 和 unix/bsd/systemv 当年的设计，epoll 这种补丁就不应该实现。
异步 reactor 框架应该就只有一个简单而统一的 selector 就足够了，所有系统都相同，提供：
别以为这些 poll / epoll / kevent / pollset / devpoll / select / rtsig
是些什么 “高性能服务器” 的 “关键技术”，它们只是一个 API，而且是对原有系统 API设计不完善打的补丁，各个内核实现了一套自己的补丁方式，它们的存在，见证了服务端技术碎片化的遗憾结果。
之所以会有这些乱七八糟的东西，就是早期的 posix / unix/ bsd /systemv 设计不周全，或者不作为留下的恶果。并非什么 “关键技术”。
不用提 windows 的 iocp了，proactor 会来强奸你代码结构，遭到大家唾弃是有原因的。不像 reactor那样优雅，所以 java nio 选择 reactor 是正确的。即便在 reactor 中，epoll 也是一个失败的例子，调用最频繁的 epoll_ctl 的系统占用估计大家都感受过吧，这方面 epoll 真该象 kevent / pollset 学习一下。
Recent Comments