前几天我的小小的WordPress服务器被攻击了，被五六台机器从不同的IP发起xmlrpc攻击，大约每秒80次请求的样子，虽然不算猛烈，但我的虚拟机本身太小了，单CPU仅1GB内存，于是频频出现内存紧张的情况，oom-killer会自动选择合适的进程牺牲掉，但它怎么就那么不开眼，每次都选中了最重要的mysqld进程。解决的思路很简单，就是减小mysqld进程的oom_score_adj值，因为oom-killer通过比较每个进程的oom_score来挑选要出局的进程，数值越大就越容易被选中，而手工调整oom_score是通过oom_score_adj来实现的，命令如下：

但是每次reboot或者mysql重启都需要重新设置一遍实在麻烦，怎样才能实现自动化呢？我的做法如下，虽然道理很简单，但实现过程中有好几个坑，包含了几个有用的知识点，所以有点共享价值。

要点一：如何修改systemd的服务脚本

首先，我想在启动mysql服务的时候就自动把 oom_score_adj 调整好，理论上应该通过修改启动脚本完成，问题是我用了CentOS 7，systemd的启动脚本与以前有很大的不同。还是让我们先找到它吧：

显然/usr/lib/systemd/system/mariadb.service就是我们感兴趣的，可以直接修改，但不建议这么做，因为将来升级mariadb有可能会覆盖掉你的改动。更好的方式是这样的：创建一个新目录 “/etc/systemd/system/mariadb.service.d/”，把需要改动的内容放在该目录下的”.conf”文件里，文件名可以随便，但必须以”.conf”结尾。这个文件起的作用是对systemd的service文件做出补充，systemd的service文件包括三个主要部分：[Unit], [Service]和[Install]，其中[Service]段定义了服务启停的方法，[Service]段中以下三个字段是最常用的：
ExecStart 用于定义启动服务的命令，
ExecStartPre 是启动服务之前执行的命令，
ExecStartPost 是启动服务之后执行的命令。
我们修改oom_score_adj的任务应该放在ExecStartPost部分，需要注意的是：命令必须使用全路径，因为systemd不提供设置好的PATH环境变量。（注：更多关于systemd的细节可参考Red Hat的系统管理指南）

我们只增加了一行有实质内容，即让mariadb.service在启动之后调用自定义的脚本oom_mysql.sh，我们在这个脚本中调整mysqld进程的oom_score_adj值，脚本如下 (因为mariadb会把mysqld的PID记录在/var/run/mariadb/mariadb.pid之中，所以在脚本中我们寻找mysqld进程号便简单了)：

要点二：如何设置不用输入密码而且没有tty的sudo

为什么我要通过sudo来执行以上脚本呢？
ExecStartPost=/bin/sudo   /usr/local/bin/oom_mysql.sh
为什么不象下面这样直接执行呢？
ExecStartPost=/usr/local/bin/oom_mysql.sh

这是因为mariadb.service是以mysql用户的身份启动的，mysql用户不具备写入/proc的权限，而在oom_mysql.sh脚本中我们需要写入 /proc/<pid>oom_score_adj

为了使mysql用户能够写入/proc/<pid>/oom_score_adj，我们利用了sudo。修改sudo配置的命令是visudo，如果不加 -f 参数，它默认修改配置文件/etc/sudoers，但直接改动/etc/sudoers不太稳妥，万一改坏了什么地方就有麻烦，所以推荐的方法是：把你要增加的sudoers配置放在/etc/sudoers.d/ 目录下的文件中，文件名可以随意。

我们把要增加的配置放进了4mysql文件里，内容只有两行，需要解释一下：因为mysql用户很特别，它是不能登录的，因为它的shell是/sbin/nologin，而且在自动启动mariadb.service的时候显然也不能依赖人工输入口令去执行sudo，所以它的sudoers配置需要一种特殊的权限–即无需输入口令就可以执行sudo命令，这就是上述第二行 “mysql ALL=(ALL) NOPASSWD:” 的意思；第一行表示mysql用户执行sudo可以无需tty(终端)，因为RHEL和CentOS默认情况下sudo需要tty才能执行，否则会发生下列错误：

至此，我们的工作就完成了，最后重启mariadb.service即可：

再检查mysqld，发现它的oom_score_adj已经设置为-100了，正是我们所期望的：

 

Linux从2.6开始支持内核抢占，意味着即使进程运行在内核态也可以被抢占。为了支持内核抢占，代码中为每个进程的 thread_info 引入了 preempt_count 计数器，数值为0的时候表示可以内核抢占，每当进程持有内核锁的时候把 preempt_count 计数器加1，表示禁止内核抢占。此外还有一些其它禁止内核抢占的场景，也通过 preempt_counter 字段反应出来：preempt_counter 字段是32位的，除了抢占计数器之外还包括其他标志位，只要 preempt_counter 整体不为0，就不能进行内核抢占，这个设计一下子简化了对众多不能抢占的情况的检测：

• Bit  0- 7: 就是上文中所讲的抢占计数器，表示显式禁用内核抢占的次数；
• Bit  8-15: 软中断计数器，记录可延迟函数被禁用的次数；
• Bit 16-27: 硬中断计数器，表示中断处理程序的嵌套数，irq_enter()递增它，irq_exit()递减它；
• Bit    28: PREEMPT_ACTIVE 标志。

这篇笔记要讲的是 PREEMPT_ACTIVE 标志。PREEMPT_ACTIVE标志的本意是表明正在进行内核抢占，设置了之后preempt_counter就不再为0，从而达到禁止内核抢占的效果，使得执行抢占工作的代码不会被再抢占。它的一个重要用途是防止非Running状态的进程被抢占过程错误地从Run Queue中移除。这句话令人十分费解，已经不处于Running状态的进程本来就不应该留在Run Queue中，为什么要防止它被移除？我用了很长时间才琢磨出来，要回答这个问题，首先要理解为什么非Running状态的进程会被抢占？所谓抢占，就是从一个正在运行的进程手上把CPU抢过来，可是既然进程已经不是Running状态了，怎么会还在CPU上，还被抢占？
这是因为进程从Running变成非Running要经过几个步骤：在把自己放进Wait Queue、状态置成非Running之后，最后调用schedule()把自己从Run Queue中移除、并把CPU交给其他进程。设想一下，一个进程恰好在调用schedule()之前就被抢占了，此时它仍然还在CPU上运行。这就是为什么非Running状态的进程也会被抢占的原因。对这样的进程，抢占流程不能擅自将之从Run Queue中移除，因为它的切换过程没有完成，应该让它有机会自己回头接着做完。比如以下的代码，是一个典型的休眠过程：

如果在第2行被抢占，刚把进程状态设置为TASK_UNINTERRUPTIBLE，本来马上就要测试条件是否满足了，这时被抢占，而抢占过程必定包含调用schedule()的步骤，导致该进程被移出运行队列，失去了运行机会，随后的条件判断语句就无法执行了，假如此时condition条件是满足的，它本来会跳出for循环、而不会去调用schedule()进入休眠，然而却被抢占过程错误地调用schedule()导致它休眠了，也因此错过了那个条件判断语句，也许就永远没有被唤醒的机会了。正确的做法是：进程被抢占后还留在Run Queue中，下次还有机会继续运行，恢复运行后继续判断condition，如果条件不满足，在随后主动调用的schedule()中会被移出运行队列，这是不能由抢占代劳的。

下面我们详细看看PREEMPT_ACTIVE是如何帮助实现上述的正确做法的。在内核里，进程从运行态进入休眠态的最后一步是呼叫调度器schedule()——把自己从Run Queue中移除，把CPU交给其他进程，这在不支持内核抢占的时代没有问题，因为整个过程不会被打断，然而内核抢占的出现使情况变复杂了，现在从运行态进入休眠态的过程可能会被抢占所打断，而抢占过程中会调用schedule()，导致schedule()的调用提前发生，有可能形成race condition。为了避免这种情况，内核抢占过程中不能直接呼叫schedule()调度器，而是呼叫preempt_schedule()，再通过它来调用schedule()，preempt_schedule()会在调用schedule()之前设置PREEMPT_ACTIVE标志，调用之后再清除这个标志。而schedule()会检查这个标志，如果设置了PREEMPT_ACTIVE标志，意味着这是从抢占过程中进入schedule()，对于不是TASK_RUNNING(state != 0)的进程，就不会调用deactivate_task()把进程从Run Queue移除。源码如下：

这段代码的逻辑含义是这样的：
如果设置了PREEMPT_ACTIVE，说明该进程是由于内核抢占而被调离CPU的，这时不把它从Run Queue里移除；如果PREEMPT_ACTIVE没被设置（进程不是由于内核抢占而被调离），还要看一下它有没有未处理的信号，如果有的话，也不把它从Run Queue移除。
总之，只要不是主动呼叫schedule()，而是因被抢占而调离CPU的，进程就还在运行队列中，还有机会运行。

 

 

如果CPU的使用率突然暴涨，如何迅速定位是哪个进程、哪段代码引起的呢？我们需要一个profiling工具，对CPU上执行的代码进行采样、统计，告诉我们CPU到底在忙些什么。

perf 就是这样的工具。我们举个例子看看 perf 是怎样工作的。

首先我们用以下命令模拟出CPU利用率暴涨的现象：

然后我们看到 CPU 1 的 %system 飙升到95%：

现在我们用 perf 工具采样：

注：”-a”表示对所有CPU采样，如果只需针对特定的CPU，可以使用”-C”选项。

把采样的数据生成报告：

我们很清楚地看到，CPU利用率有75%来自 cat 进程 的 sys_read 系统调用，perf 甚至精确地告诉了我们是消耗在 read_zero 这个 kernel routine 上。

在分析Linux kernel dump的时候经常会看到一个叫做dmar的东西，查看中断信息的时候也时常见到一个名称为dmar0的设备，到底什么是dmar呢？

大家知道，I/O设备可以直接存取内存，称为DMA(Direct Memory Access)；DMA要存取的内存地址称为DMA地址（也可称为BUS address）。在DMA技术刚出现的时候，DMA地址都是物理内存地址，简单直接，但缺点是不灵活，比如要求物理内存必须是连续的一整块而且不能是高位地址等等，也不能充分满足虚拟机的需要。后来dmar就出现了。 dmar意为DMA remapping，是Intel为支持虚拟机而设计的I/O虚拟化技术，I/O设备访问的DMA地址不再是物理内存地址，而要通过DMA remapping硬件进行转译，DMA remapping硬件会把DMA地址翻译成物理内存地址，并检查访问权限等等。负责DMA remapping操作的硬件称为IOMMU。做个类比：大家都知道MMU是支持内存地址虚拟化的硬件，MMU是为CPU服务的；而IOMMU是为I/O设备服务的，是将DMA地址进行虚拟化的硬件。   IOMMA不仅将DMA地址虚拟化，还起到隔离、保护等作用，如下图所示意，详细请参阅Intel Virtualization Technology for Directed I/O 现在我们知道了dmar的概念，那么Linux中断信息中出现的dmar0又是什么呢？ 还是用MMU作类比吧，便于理解：当CPU访问一个在地址翻译表中不存在的地址时，就会触发一个fault，Linux kernel的fault处理例程会判断这是合法地址还是非法地址，如果是合法地址，就分配相应的物理内存页面并建立从物理地址到虚拟地址的翻译表项，如果是非法地址，就给进程发个signal，产生core dump。IOMMU也类似，当I/O设备进行DMA访问也可能触发fault，有些fault是recoverable的，有些是non-recoverable的，这些fault都需要Linux kernel进行处理，所以IOMMU就利用中断(interrupt)的方式呼唤内核，这就是我们在/proc/interrupts中看到的dmar0那一行的意思。 我们看到的中断号48，据此还可以进一步发掘更多的信息：

上面最有意思的信息是ACTION的handler，表示IOMMU发生fault之后的中断处理例程，我们看到的例程名是dmar_fault，源代码如下：

请注意行号1343，dmar_fault_do_one()会报告fault的具体信息，包括对应设备的物理位置。由于一个dmar对应着很多个I/O设备，这条信息可以帮助定位到具体哪一个设备。源代码如下：

 

dmar的初始化是kernel根据ACPI中的dmar table进行的，每一个表项对应一个dmar设备，名称从dmar0开始依次递增，涉及取名的代码如下：

上面也揭示了boot过程留在dmesg中信息的来历：

附注： 过去的AMD64芯片也提供一个功能有限的地址转译模块——GART (Graphics Address Remapping Table)，有时候它也可以充当IOMMU，这导致了人们对GART和新的IOMMU的混淆。最初设计GART是为了方便图形芯片直接读取内存：使用地址转译功能将收集到内存中的数据映射到一个图形芯片可以“看”到的地址。后来GART被Linux kernel用来帮助传统的32位PCI设备访问可寻址范围之外的内存区域。这件事新的IOMMU当然也可以做到，而且没有GART的局限性（它仅限于显存的范围之内），IOMMU可以将I/O设备的任何DMA地址转换为物理内存地址。

---

参考资料：
Linux Kernel的Intel-IOMMU.txt
Intel’s Virtualization for Directed I/O (a.k.a IOMMU)
Wikipedia IOMMU
理解IOMMU、北桥、MMIO和ioremap
Intel Virtualization Technology for Directed I/O

ssh是个多用途的工具，不仅可以远程登录，还可以搭建socks代理、进行内网穿透，这是利用它的端口转发功能来实现的。

所谓ssh端口转发，就是在ssh连接的基础上，指定 ssh client 或 ssh server 的某个端口作为源地址，所有发至该端口的数据包都会透过ssh连接被转发出去；至于转发的目标地址，既可以指定，也可以不指定，如果指定了目标地址，称为定向转发，如果不指定目标地址则称为动态转发：

• 定向转发
  定向转发把数据包转发到指定的目标地址。目标地址不限定是ssh client 或 ssh server，既可以是二者之一，也可以是二者以外的其他机器
• 动态转发
  动态转发不指定目标地址，数据包转发的目的地是动态决定的

因为ssh端口转发是基于ssh连接的，所以如果ssh连接断开，那么设置好的端口转发也会随之停止。

在设置端口转发之前，必须确认ssh的端口转发功能是打开的。

怎样打开ssh的端口转发功能？

ssh端口转发功能默认是打开的。控制它的开关叫做 AllowTcpForwarding，位于ssh server的配置文件 /etc/ssh/sshd_config 里：
    AllowTcpForwarding yes
如果修改的话需要重启sshd服务才会生效。

怎样设置端口转发？

设置端口转发之前要注意 iptables 设置，确保相应的端口未被屏蔽，如果嫌麻烦的话也可以临时禁用 iptables：
# service iptables stop

定向转发和动态转发的设置方法是不一样的，以下分别介绍。

设置定向转发

定向转发可以把一个 IP:Port 定向映射到另一个 IP:Port，源和目的都必须指定。源地址既可以是 ssh client 的某个端口，也可以是 ssh server 的某个端口：

• 如果源地址是 ssh client 的某个端口，称为本地转发（Local Port Forwarding），发往 ssh client 指定端口的数据包会经过 ssh server 进行转发；
• 如果源地址是 ssh server 的某个端口，则称为远程转发（Remote Port Forwarding），发往 ssh server 指定端口的数据包会经过 ssh client 进行转发.

设置本地转发：

先看一下基本命令：

在ssh client上执行：
{ssh client}# ssh -g -N -f -o ServerAliveInterval=60 \
-L <local port>:<remote host>:<remote port> username@<ssh server>
参数的含义在后面有解释。

我们以下面的示意图为例：你想telnet连接{remote host}，但是无法直达，你只能直接连接ssh client，于是试图通过{ssh client}到{ssh server}这条通道中转：

{you} — {ssh client} — {ssh server} — {remote host}

我们要做的是在{ssh client}上执行以下命令：

{ssh client} # ssh -g -L 2323:<remote-host>:23 username@<ssh-server>

输入口令之后，就跟普通的ssh登录一样，我们进入了shell，在shell中可以正常操作，不同之处是，它同时还把 {ssh client} 的2323端口映射到了{remote host} 的23端口——亦即telnet端口，此后执行”telnet <ssh client> 2323″就相当于”telnet <remote-host>”，只要shell不退出，这个定向转发就一直有效。

• 注1：如果以上命令不加”-g”选项，那么SSH Client上的监听端口2323会绑定在127.0.0.1上，意味着只有SSH Client自己才能连上。加上”-g”选项之后，SSH Client才允许网络上其他机器连接2323端口。
• 注2：以上命令会生成一个shell，有时候并不符合我们的需要，因为多数时候我们只想要一个端口转发功能，挂一个shell是个累赘，而且shell一退出，端口转发也停了。这就是为什么我们需要”-N -f”选项的原因：
  -N 告诉ssh client，这个连接不需要执行任何命令，仅做端口转发
  -f 告诉ssh client在后台运行
• 注3：为了避免长时间空闲导致ssh连接被断开，我们可以加上”-o ServerAliveInterval=60″选项，每60秒向ssh server发送心跳信号。还有一个TCPKeepAlive选项的作用是类似的，但是不如ServerAliveInterval 好，因为TCPKeepAlive在TCP层工作，发送空的TCP ACK packet，有可能会被防火墙丢弃；而ServerAliveInterval 在SSH层工作，发送真正的数据包，更可靠些。
• 如果不是以root身份设置端口转发的话，转发端口只能使用大于1024的端口号。

设置远程转发：

先看一下基本命令，分为两部分：

在ssh server上：
编辑 /etc/ssh/sshd_config，设置以下内容然后重启sshd服务
    GatewayPorts yes
在ssh client上执行：
{ssh client}# ssh -f -N -o ServerAliveInterval=60 \
-R <ssh server port>:<remote host>:<remote port> username@<ssh server>

这次的实例如下所示，你想用telnet连接{remote host}，但是无法直达，于是试图通过{ssh server}到{ssh client}这条通道中转，注意与前面介绍的本地转发的不同之处是，本地转发的案例中你只能直接连接到 ssh client，而这里你只能直接连到 ssh server：

{you} — {ssh server} — {ssh client} — {remote host}

我们要做的是在{ssh client}上执行以下命令：

{ssh client} # ssh -f -N -R 2323:<remote-host>:23 username@<ssh-server>

输入口令之后，{ssh server}的2323端口映射到了{remote host}的23端口——亦即telnet端口，此后执行”telnet <ssh server> 2323″就相当于”telnet <remote-host>”。

本地转发与远程转发的区别与适用场景

定向转发（包括本地转发和远程转发）通常用于内网穿透，本地转发和远程转发的区别就在于监听端口是开在ssh client上还是ssh server上。常见的使用场景是：

• 如果ssh client在内网里面，ssh server在Internet上，你想让Internet上的机器穿进内网之中，那就使用远程转发；
• 如果ssh server在内网里面，ssh client在外面，你想穿进内网就应该使用本地转发。

设置动态转发

定向转发（包括本地转发和远程转发）的局限性是必须指定某个目标地址，如果我们需要借助一台中间服务器访问很多目标地址，一个一个地定向转发显然不是好办法，这时我们要用的是ssh动态端口转发，它相当于建立一个SOCKS服务器。

先看一下基本命令：

在ssh client上执行：
{ssh client}# ssh -f -N -o ServerAliveInterval=60 \
-D <ssh client port> username@<ssh server>

实际使用时有两种常见场景：

• 你把自己的机器(127.0.0.1)当作 sock5 代理服务器：
  {you / ssh client} — {ssh server} — {other hosts}

命令如下：

{ssh client} # ssh -f -N -D 1080 username@<ssh-server>

这种情况下，我们得到的socks5代理服务器是：127.0.0.1:1080，仅供ssh client自己使用。
然后你就可以在浏览器中或其他支持socks5代理的软件中进行设置。

• ssh client 和 ssh server 是同一台机器，并充当socks5代理：
  {you} — {ssh client / ssh server} — {other hosts}

命令如下：

{ssh client} # ssh -f -N -g -D 1080 username@127.0.0.1

这种情况下，我们得到的socks5代理服务器是：
{ssh client IP}:1080，可供网络上其他机器使用，只要能连接ssh client即可。

通过SSH建立的SOCKS服务器使用的是SOCKS5协议，在为应用程序设置SOCKS代理的时候要注意。