同事报告一起奇怪的现象，一个最简单的测试PHP代码，在测试环境很正常，但是在正式环境下，无论用何种方式(tcp/ip、unix
socket)都无法连接mysql。
我协助查看了下，确实如此，无论是指定IP、端口的tcp/ip方式连接，或者是用unix socket方式连接，报错信息都类似：
Could not connect: Can't connect to MySQL server on 'MYSQL.SERVER' (13)
无论如何修改MySQL的授权，或者调整php.ini中关于MySQL的设置，或者修改MySQL的监听网口，都无法解决。
而如果用命令行人工连接MySQL，则一切正常。
问题看起来像是php(with apache)不被允许连接MySQL，但是防火墙也没有限制。想来想去，唯有SELinux的因素会导致这个问题。
getsebool -a|grep -i httpd
可以看到这里设置了httpd进程的许可模式，再仔细看一下，有一个选项：
getsebool …[获取更多]
pig是个啥东东？
官网：http://zlib.net/pigz
一句话简介：
A parallel implementation of gzip for modernmulti-processor, multi-core machines。
简单的说，就是支持并行的gzip。废话不多说，开始测试。
pig默认用当前逻辑cpu个数来并发压缩，无法检测个数的话，则并发8个线程。
一、测试压缩包文件1 压缩前 -rw-r--r-- 1 root root 2474772480 Dec 3 19:54 dbs.tar 1、gzip测试 压缩耗时，CPU最高：101.6% real 2m18.042s user 2m10.204s sys 0m6.876s 解压缩耗时，CPU最高：101.6% real 0m26.756s user 0m20.175s sys 0m6.580s 压缩后 -rw-r--r-- 1 root root 2349563863 Dec 3 19:54 dbs.tar.gz 2、pigz测试 并发8线程(默认)： 压缩耗时，CPU最高：832% real 0m21.710s user 2m31.229s sys 0m9.101s 解压缩耗时，CPU最高：199% real 0m13.239s user …[获取更多]
在各种测试组合方案中，组合10(组合10：SSD * 2, RAID 0,
XFS,WB,nobarrier,noop)的综合性能最高，因此以它为基准，其他方案与其对比，下表是各组合和组合10的对比：
相应的对比线形图：
测试环境：
结语
1. 在xfs文件系统模式下，SSD设备的性能是SAS设备性能的6 ~
13倍，平均：9倍，在并发16线程时最高(和MySQL的内部机制有关)；
2.
SSD设备使用noop模式的IO调度器效率最高(关于Linux内核IO调度器详见：http://www.redhat.com/magazine/008jun05/features/schedulers/)；
3.
xfs设置为nobarrier相比启用barrier效率高(关于barrier介绍详见：http://xfs.org/index.php/XFS_FAQ#Write_barrier_support)；
4. 建议仍旧启用阵列卡的WB策略以提高整体阵列随机IO性能；
5. …
测试结果曲线图：
小结：
1. 如果应用以随机IO为主的话，应使用raid 1+0，在相同硬盘数量情况下，其性能约是raid 5的1.4(+)倍
2. 随机IO越大，raid 5的性能下降越厉害，在本次测试中，有好几次较大IO时，测试进程无响应
附：
Sysbench测试io方法：
sysbench --file-num=10 --num-threads=16 --test=fileio --file-total-size=30G --max-requests=10000000 --file-test-mode=rndrw run
sysbench详细文档：http://sysbench.sourceforge.net/docs/
有一次在做MySQL数据库更新时，发现DML更新效率特别低，总能发现超过1秒的慢日志，一般很少会出现这种情况，初步判定为可能网络故障或者就是DB服务器自身的性能出现问题导致。
经过检查服务器状况，发现确实发生了硬件故障，主要是raid 10中的一块硬盘发生预警，信息如下：
Physical Disk: 1 Enclosure Device ID: 32 Slot Number: 3 Device Id: 3 Sequence Number: 2 Media Error Count: 650 Other Error Count: 73 Predictive Failure Count: 71 Last Predictive Failure Event Seq Number: 6716 Raw Size: 140014MB [0x11177328 Sectors] Non Coerced Size: 139502MB [0x11077328 Sectors] Coerced Size: 139392MB [0x11040000 Sectors] Firmware state: Online SAS Address(0): 0x500000e11079e682 SAS Address(1): 0x0 Connected Port Number: 3(path0) Inquiry Data: FUJITSU MBA3147RC D306BLB5P9500H4M
大家注意下上面的信息，硬盘的状态还是 …
[获取更多]近期碰到个问题，服务器上线后，crontab都发生异常没有自动执行，查看了下日志，发现问题：
Apr 16 11:26:01 imysql.cn crond[28354]: (*system*) BAD FILE MODE (/etc/cron.d/flushhost) Apr 16 11:26:01 imysql.cn crond[28354]: (root) BAD FILE MODE (cron/root)
检查了下 /etc/cron.d/ 目录下的其他文件，发现 flushhost 的属性是 755，其他的则是 644，于是将这个脚本属性也改成644，问题解决。
另外，还同时修改了mysql安装包的install.sh脚本，新服安装完毕后，修改flushhost脚本的属性为644。
这个问题貌似只在个别版本的RHEL下碰到过，并不是所有的版本都有。
主要信息来自：http://code.google.com/p/tcpcopy/
tcpcopy是一个基于底层的应用请求复制（所有基于tcp的packets）开源项目，可用于替代ab做在线模拟压力测试，可转发各种在线请求到测试服务器上，进行较为详尽的近乎实际的测试，从而避免了新业务、系统上线带来的潜在问题。
tcpcopy的四大功能：
1）分布式压力测试，将多个前段请求集中到某个后端进行压力测试
2）上线前测试，检验新系统可靠性，提前发现潜在问题
3）对比测试，同样请求，针对不同或不同版本程序，可以做性能对比等试验
4）应用热备份，对于后端的短连接，请求丢失率非常低(1/10万)
tcpcopy具有以下几个特点：
1）实时转发
2）近乎真实效果
…
有些时候，我们并不需要一些特殊的模块，或者个别模块对我们的硬件支持不是那么好，这就需要在内核将它们关闭，编辑下述文件即可：
[root@imysql.cn ]# cat /etc/hotplug/blacklist # # Listing a module here prevents the hotplug scripts from loading it. # Usually that'd be so that some other driver will bind it instead, # no matter which driver happens to get probed first. Sometimes user # mode tools can also control driver binding. # # Syntax: driver name alone (without any spaces) on a line. Other # lines are ignored. # #diasble usb_storage usb_storage #disable edac i5000_edac edac_mc
只需要往 /etc/hotplug/blacklist中添加一行，然后重启系统即可生效。
上面的方法适用于AS4的系统，但如果是AS5的系统，方法就不一样了，编辑/etc/modprobe.conf，内容类似：
[root@imysql.cn ]# cat /etc/modprobe.conf alias eth0 bnx2 #disable lists …[获取更多]