论坛使用阿里云的 ECS + RDS + OSS 搭建，最近经常隔三差五出现 RDS 的 CPU 和连接数突然满负荷的情况，导致数据库无法连接。这种情况一般会认为是受到了攻击，因为如果是访问量大或者是哪里有慢查询，应该是资源消耗逐步上升直至崩溃的，沿着这个思路去查 Web 日志封 IP，但效果不大，关闭功能、卸载插件也没用。
开启阿里云后台的 SQL 审计，能看到 SQL 查询日志，但是很难找有问题的 SQL。
最终在重启 RDS 后执行以下语句列出所有正在执行或阻塞的语句：
show full processlist在结果列中，Command 为 Query 是正在执行查询操作的语句，发现几乎所有的 SQL 都是：
SELECT * FROM pre_forum_thread WHERE tid>0 AND fid IN('42','95','247','41','567','62','149','229','37','230','93','190','284','75','38','568') AND `fid`<>'546' AND replies > 0 AND displayorder>=0 ORDER BY lastpost DESC LIMIT 10再加上之前出现的情况是，论坛帖子列表和详情页面能正常打开时，论坛首页也不一定能打开，所以基本定位到是“首页四格”的数据库查询导致的。
进入论坛后台首页四格设置，对比了版块 id 后确认了这个 bug。
单独执行该语句大约耗时 5s（主题帖 200 万），设置的缓存时间 10 分钟。
processlist 中看到这些语句的 state 都是 Creating sort index，尝试去掉 ORDER BY 后执行果然只需要 16ms。
5s 内的访客都是从数据库读取的，能处理完就正常，否则累积就导致 RDS 崩溃，每 10 分钟都会重现一次风险。
当然这个问题可以通过添加索引来解决。
随着拥有多个硬线程CPU（超线程、双核）的普及，多线程和异步操作等并发程序设计方法也受到了更多的关注和讨论。本文主要是想与园中各位高手一同探讨一下如何使用并发来最大化程序的性能。
多线程和异步操作的异同
多线程和异步操作两者都可以达到避免调用线程阻塞的目的，从而提高软件的可响应性。甚至有些时候我们就认为多线程和异步操作是等同的概念。但是，多线程和异步操作还是有一些区别的。而这些区别造成了使用多线程和异步操作的时机的区别。
异步操作的本质
所有的程序最终都会由计算机硬件来执行，所以为了更好的理解异步操作的本质，我们有必要了解一下它的硬件基础。 熟悉电脑硬件的朋友肯定对DMA这个词不陌生，硬盘、光驱的技术规格中都有明确DMA的模式指标，其实网卡、声卡、显卡也是有DMA功能的。DMA就是直接内存访问的意思，也就是说，拥有DMA功能的硬件在和内存进行数据交换的时候可以不消耗CPU资源。只要CPU在发起数据传输时发送一个指令，硬件就开始自己和内存交换数据，在传输完成之后硬件会触发一个中断来通知操作完成。这些无须消耗CPU时间的I/O操作正是异步操作的硬件基础。所以即使在DOS这样的单进程（而且无线程概念）系统中也同样可以发起异步的DMA操作。
线程的本质
线程不是一个计算机硬件的功能，而是操作系统提供的一种逻辑功能，线程本质上是进程中一段并发运行的代码，所以线程需要操作系统投入CPU资源来运行和调度。
异步操作的优缺点
因为异步操作无须额外的线程负担，并且使用回调的方式进行处理，在设计良好的情况下，处理函数可以不必使用共享变量（即使无法完全不用，最起码可以减少共享变量的数量），减少了死锁的可能。当然异步操作也并非完美无暇。编写异步操作的复杂程度较高，程序主要使用回调方式进行处理，与普通人的思维方式有些初入，而且难以调试。
多线程的优缺点
多线程的优点很明显，线程中的处理程序依然是顺序执行，符合普通人的思维习惯，所以编程简单。但是多线程的缺点也同样明显，线程的使用（滥用）会给系统带来上下文切换的额外负担。并且线程间的共享变量可能造成死锁的出现。
适用范围
在了解了线程与异步操作各自的优缺点之后，我们可以来探讨一下线程和异步的合理用途。我认为：当需要执行I/O操作时，使用异步操作比使用线程+同步I/O操作更合适。I/O操作不仅包括了直接的文件、网络的读写，还包括数据库操作、Web Service、HttpRequest以及.Net Remoting等跨进程的调用。
而线程的适用范围则是那种需要长时间CPU运算的场合，例如耗时较长的图形处理和算法执行。但是往往由于使用线程编程的简单和符合习惯，所以很多朋友往往会使用线程来执行耗时较长的I/O操作。这样在只有少数几个并发操作的时候还无伤大雅，如果需要处理大量的并发操作时就不合适了。
“/”应用程序中的服务器错误。
未能加载文件或程序集“XXXXXX”或它的某一个依赖项。试图加载格式不正确的程序。
说明: 执行当前 Web 请求期间，出现未经处理的异常。请检查堆栈跟踪信息，以了解有关该错误以及代码中导致错误的出处的详细信息。
异常详细信息: System.BadImageFormatException: 未能加载文件或程序集“XXXXXX”或它的某一个依赖项。试图加载格式不正确的程序。
源错误:
执行当前 Web 请求期间生成了未经处理的异常。可以使用下面的异常堆栈跟踪信息确定有关异常原因和发生位置的信息。
程序集加载跟踪: 下列信息有助于确定程序集“XXXXXX”未能加载的原因。
警告: 程序集绑定日志记录被关闭。 要启用程序集绑定失败日志记录，请将注册表值 [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD)设置为 1。 注意: 会有一些与程序集绑定失败日志记录关联的性能损失。 要关闭此功能，请移除注册表值 [HKLM\Software\Microsoft\Fusion!EnableLog]。
当使用 Visual Studio 发布网站时，可能会遇到上述黄屏报错，原因之一是引用的 dll 路径不正确，可以用 Release 模式生成一次看看；原因之二是应用程序的位数与服务器的不匹配。
一般来说用“Any CPU”的方式没有问题，但遇到上述报错的百度网友都很轻松地通过修改 IIS 应用程序池的“启用 32 位应用程序”来解决这个问题，原因是他们的服务器是 64 位操作系统。当我这次在 32 位操作系统的服务器上遇到这个问题的时候真的是手足无措了，然后一阵乱配置，偶尔还能成功跑起来，于是仔细对比了发布到服务器上的文件，发现只有 bin 目录下的 dll 文件有区别，而导致这些区别的原因是我在发布时把“Release - Any CPU”换成了“Debug - Any CPU”，所以一时找不到更好的解决办法的朋友不妨也试试这个方法，只是会有一点点担心性能问题。有更好的解决方案的朋友也不要忘了联系我。
本教程使用的软件版本：
VMware Workstation 12 Pro for Windows
Mac OS X Unlocker for VMware V2.0.6
一个能让虚拟机 VMware 安装 OS X 系统的解锁补丁
OS X 10.10.5 Yosemite (14F27) 懒人版 CDR 镜像
CRC32: C7E1E915
MD5: A76FF6E43058A40182435D274D9EB976
SHA-1: 7DDC194E779B003AFDCF2B7C11BEB6D4443F8D72
安装步骤：
1、安装 VMware Workstation
2、新建虚拟机：选择 典型 - 稍后安装操作系统，当然现在还看不到 Apple Mac OS X，先退出 VMware
3、安装 Unlocker
4、重复第 2 步，选择 Apple Mac OS X，并选择对应的 OS X 版本，后续跟据情况自行配置
5、编辑虚拟机设置 - CD/DVD(SATA) - 使用 ISO 镜像文件 - 浏览 - 所有文件(*.*)，定位到 .cdr 镜像文件
6、开启此虚拟机
7、如果报错：VMware Workstation 不可恢复错误: (vcpu-0)，打开新建虚拟机时指定的位置（默认在 C:\Users\用户名\Documents\Virtual Machines\虚拟机名\），用记事本打开 .vmx 文件，添加一条配置：smc.version = "0"，保存关闭后重新开启虚拟机
8、如果屏幕中央出现一个禁止的图标，那么表示当前版本的 VMware 不支持安装当前版本的 OS X
9、如果在“选择要安装到的磁盘”界面仅列出了镜像文件而无法继续安装，请在窗口顶部的菜单栏中选择 实用工具 - 磁盘工具，选中新建虚拟机时创建的磁盘，切换到“分区”选项卡进行分区操作，简单地可以选择“1 个分区”，点击“应用”、“分区”，退出磁盘工具。现在可以把 OS X 安装在刚刚创建的分区上了
10、继续愉快地安装和使用 OS X 吧！
使用此方法将 OS X 安装到物理磁盘并支持开机直接运行，请参考此文：超详细 （60P）利用虚拟机安装10.9.4（懒人版）到真机教程
最近有服务器不时出现的CPU使用率超高，内存几乎被吃光，系统甚至自动kill掉一些进程，如sshd，vsftpd等。用top查看，PHP-CGI进程高挂不下，如下是解决方案：
一、进程跟踪
# top //找出CPU使用率高的进程PID
# strace -p PID //跟踪进程
# ll /proc/PID/fd //查看该进程在处理哪些文件
将有可疑的PHP代码修改之，如：file_get_contents没有设置超时时间。
二、内存分配
如果进程跟踪无法找到问题所在，再从系统方面找原因，会不会有可能内存不够用？据说一个较为干净的PHP-CGI打开大概20M-30M左右的内存，决定于PHP模块开启多少。
通过pmap指令查看PHP-CGI进程的内存使用情况
# pmap $(pgrep php-cgi |head -1)
按输出的结果，结合系统的内存大小，配置PHP-CGI的进程数（max_children）。
三、监控
最后，还可以通过监控与自动恢复的脚本保证服务的正常运转。下面是我用到的一些脚本：
只要一个php-cgi进程占用的内存超过 %1 就把它kill掉
#!/bin/sh
PIDS=`ps aux|grep php-cgi|grep -v grep|awk’{if($4>=1)print $2}’`
for PID in $PIDS
do
echo `date +%F….%T`>>/data/logs/phpkill.log
echo $PID >> /data/logs/phpkill.log
kill -9 $PID
done
检测php-fpm进程
#!/bin/bash
netstat -tnlp | grep “php-cgi” >> /dev/null #2&> /data/logs/php_fasle.log
if [ "$?" -eq "1" ];then #&& [ `netstat -tnlp | grep 9000 | awk '{ print $4}' | awk -F ":" '{print $2}'` -eq "1" ];then
/usr/local/webserver/php/sbin/php-fpm start
echo `date +%F….%T` “System memory OOM.Kill php-cgi. php-fpm service start. ” >> /data/logs/php_monitor.log
fi
通过http检测php执行
#!/bin/bash
status=`curl -s –head “http://127.0.0.1:8080/chk.php” | awk ‘/HTTP/ {print $2}’`
if [ $status != "200" -a $status != "304" ]; then
/usr/local/webserver/php/sbin/php-fpm restart
echo `date +%F….%T` “php-fpm service restart” >> /data/logs/php_monitor.log
fi