在繁忙的web服务器上,很常见的问题是大量tcp 半连接的存在占用系统的大量资源。有效的减少半连接对优化服务器响应有着重要的作用。
实践步骤：

1。执行 /bin/netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’
2。vi /etc/sysctl.conf 添加如下两行:

1)net.ipv4.tcp_tw_reuse = 1 //允许将TIME-WAIT sockets重新用于新的TCP连接
2)net.ipv4.tcp_tw_recycle = 1 //开启TCP连接中TIME-WAIT sockets的快速回收


3。运行sysctl -p

4。执行 /bin/netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’

如果对于TIME_WAIT较高的服务器来说应该很快就会看到效果

释放前
[root@selboo ~]# free  -m
             total       used       free     shared    buffers     cached
Mem:          3042       2939        103          0        157       1571
-/+ buffers/cache:       1209       1832
Swap:         2047          0       2047

[root@selboo ~]# sync
[root@selboo ~]# echo 3 > /proc/sys/vm/drop_caches

释放后
[root@selboo ~]# free  -m
             total       used       free     shared    buffers     cached
Mem:          3042       1142       1900          0          0         22
-/+ buffers/cache:       1119       1922
Swap:         2047          0       2047
[root@selboo ~]# echo 0 > /proc/sys/vm/drop_caches  

vmstat

Procs
-r:
运行的和等待(CPU时间片)运行的进程数，这个值也可以判断是否需要增加CPU(长期大于1)
-b:
处于不可中断状态的进程数，常见的情况是由IO引起的


Memory
-swpd: 切换到交换内存上的内存(默认以KB为单位)
如果 swpd 的值不为0，或者还比较大，比如超过100M了，但是 si, so 的值长期为 0，这种情况我们可以不用担心，不会影响系统性能。
-free: 空闲的物理内存
-buff: 作为buffer cache的内存，对块设备的读写进行缓冲
-cache: 作为page cache的内存, 文件系统的cache
如果 cache 的值大的时候，说明cache住的文件数多，如果频繁访问到的文件都能被cache住，那么磁盘的读IO bi 会非常小。


Swap
-si: 交换内存使用，由磁盘调入内存
-so: 交换内存使用，由内存调入磁盘
内存够用的时候，这2个值都是0，如果这2个值长期大于0时，系统性能会受到影响。磁盘IO和CPU资源都会被消耗。
我发现有些朋友看到空闲内存(free)很少或接近于0时，就认为内存不够用了，实际上不能光看这一点的，还要结合si,so，如果free很少，但是si,so也很少(大多时候是0)，那么不用担心，系统性能这时不会受到影响的。


Io
-bi: 从块设备读入的数据总量(读磁盘) (KB/s)，
-bo: 写入到块设备的数据总理(写磁盘) (KB/s)
随机磁盘读写的时候，这2个 值越大（如超出1M），能看到CPU在IO等待的值也会越大


System
-in: 每秒产生的中断次数
-cs: 每秒产生的上下文切换次数
上面这2个值越大，会看到由内核消耗的CPU时间会越多


Cpu
-us: 用户进程消耗的CPU时间百分比
us 的值比较高时，说明用户进程消耗的CPU时间多，但是如果长期超过50% 的使用，那么我们就该考虑优化程序算法或者进行加速了(比如 PHP/Perl)
-sy: 内核进程消耗的CPU时间百分比
sy 的值高时，说明系统内核消耗的CPU资源多，这并不是良性的表现，我们应该检查原因。
-wa: IO等待消耗的CPU时间百分比
wa 的值高时，说明IO等待比较严重，这可能是由于磁盘大量作随机访问造成，也有可能是磁盘的带宽出现瓶颈(块操作)。
-id: CPU处在空闲状态时间百分比


情景分析
这个vmstat的输出那些信息值得关注？
-Procs r: 运行的进程比较多，系统很繁忙
-Io bo: 磁盘写的数据量稍大，如果是大文件的写，10M以内基本不用担心，如果是小文件写2M以内基本正常
Cpu us: 持续大于50，服务高峰期可以接受
Cpu wa: 稍微有些高
Cpu id:持续小于50，服务高峰期可以接受

Stressful Application Test（stressapptest）是一款谷歌专用的测试软件，它的大小只有不到200KB。现在，它采用了Apache license 2.0许可证，已经可以为外人所用。

为了模拟一个高负载的环境，stressappteest通过处理器和输入输出通道创造最大数量的输入压力。据谷歌的介绍，这个软件会生产线程来拷贝和直接对磁盘进行读取和写入。目标则是尽可能地载入系统内存，以便更加有效地进行测试。

该软件更多的时候测试的是内存控制器和总线接口，而不是存储单元的功能（如在Memtest86的情况下）。谷歌称，与其他内存诊断程序的比较，五分之一的内存模块相关的系统误差只能通过stressapptest发现。

你可以在谷歌的项目页面下载到该软件已经压缩好的tar包。



Google Streeapptest Team的成员，从左到右分别为：Matthew Blecker, John Huang, Rapahel Menderico, Nick Sanders, John Hawley, James Vera。

      在MySQL中，数据库对应数据目录中的目录。数据库中的每个表至少对应数据库目录中的一个文件(也可能是多个，取决于存储引擎)。因此，所使用操作系统的大小写敏感性决定了数据库名和表名的大小写敏感性。这说明在大多数Unix中数据库名和表名对大小写敏感，而在Windows中对大小写不敏感。一个显著的例外情况是Mac OS X，它基于Unix但使用默认文件系统类型(HFS+)，对大小写不敏感。

在windows下表名不区分大小写，所以在导入数据后，有可能所有表名均为小写；

而从win导入linux后，在调用时会出现大小写的问题，则有些表，例如：

第一点：程序调用表名为：fov_Web；

第二点：导入win后变为fov_web；

第三点：再导入linux后也是fov_web，此时linux会区分表名的大小写，则导致该表无法读取。

解决方法：======================================

在linux下mysql表名大小写问题解决方法：

修改my.cnf，一般位于:/etc/my.cnf

[mysqld]
lower_case_table_names=1
#表名全部为小写，避免出现大小写敏感