检查主键ID或索引的ID,如果类型是primary,就会这样.改为index
mysql.5.0.45
Submitted by admin on 2008, October 31, 4:30 PM
检查主键ID或索引的ID,如果类型是primary,就会这样.改为index
mysql.5.0.45
Submitted by admin on 2008, October 13, 11:56 AM
今天检查了一下基本一台服务器,发现TIME_WAIT高到3k多.TIME_WAIT本身并不会占用很大资源的,除非受到攻击.但太多服务器还是有可能挂掉.
TIME_WAIT 3699
CLOSE_WAIT 52
FIN_WAIT1 32
SYN_SENT 1
FIN_WAIT2 2
ESTABLISHED 17
SYN_RECV 45
CLOSING 6
根据《TCP/IP详解》中的TCP的建立和终止中有关"TCP的终止"的讲解
TCP的终止通过双方的四次握手实现。发起终止的一方执行主动关闭,响应的另一方执行被动关闭。
1. 发起方更改状态为FIN_WAIT_1,关闭应用程序进程,发出一个TCP的FIN段;
2. 接收方收到FIN段,返回一个带确认序号的ACK,同时向自己对应的进程发送一个文件结束符EOF,同时更改状态为CLOSE_WAIT,发起方接到ACK后状态更改为FIN_WAIT_2;
3. 接收方关闭应用程序进程,更改状态为LAST_ACK,并向对方发出一个TCP的FIN段;
4. 发起方接到FIN后状态更改为TIME_WAIT,并发出这个FIN的ACK确认。ACK发送成功后(2MSL内)双方TCP状态变为CLOSED。
我们不难看出上面的显示的结果的意思。根据TCP协议,主动发起关闭的一方,会进入TIME_WAIT状态(TCP实现必须可靠地终止连接的两个方向(全双工关闭)),持续2*MSL(Max Segment Lifetime),缺省为240秒.
为什么 TIME_WAIT 状态需要保持 2MSL 这么长的时间?
TIME_WAIT的等待时间为2MSL,即最大段生存时间.如果 TIME_WAIT 状态保持时间不足够长(比如小于2MSL),第一个连接就正常终止了。第二个拥有相同相关五元组的连接出现(因为连接终止前发起的一方可能需要重发 ACK,所以停留在该状态的时间必须为MSL的2倍。),而第一个连接的重复报文到达,干扰了第二个连接。TCP实现必须防止某个连接的重复报文在连接终 止后出现,所以让TIME_WAIT态保持时间足够长(2MSL),连接相应方向上的TCP报文要么完全响应完毕,要么被丢弃。建立第二个连接的时候,不 会混淆。
注:MSL(最大分段生存期)指明TCP报文在Internet上最长生存时间,每个具体的TCP实现都必须选择一个确定的MSL值。RFC 1122建议是2分钟,但BSD传统实现采用了30秒。TIME_WAIT 状态最大保持时间是2 * MSL,也就是1-4分钟。
对apache的操作
HTTP协议1.1版规定default行为是Keep-Alive,也就是会重用TCP连接传输多个request/response.所以我打开 http中的keepalive On,发现TIME_WAIT就立刻少了下来.只有300的样子.总结一下.我认为有二个原因.
1.keepalive没有开,导致每次请求都要建立新的tcp连接,请求完成以后关闭,增加了很多time_wait的状态,没有重 用,KeepAlive我认为它指的是保持连接活跃,类似于Mysql的永久连接。如果将KeepAlive设置为On,那么来自同一客户端的请求就不需 要再一次连接,避免每次请求都要新建一个连接而加重服务器的负担。
2.然后keepalive在系统中本身的值很高.默认空闲连接 7200 秒(2 小时)内没有活动.才会断开.
我们开启KeepAlive:
KeepAlive On
MaxKeepAliveRequests 120
KeepAliveTimeout 15
这样每个连接可以发送100次请求,超时时间为15秒(如果第二次请求和第一次请求之间超过KeepAliveTimeOut的时间的话,第一次连接就会中断,再新建第二个连接)。
有关内核级别的keepalive和time_wait的优化调整
vi /etc/sysctl
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_fin_timeout = 30
net.core.netdev_max_backlog =8096
修改完记的使用sysctl -p 让它生效
以上参数的注解
/proc/sys/net/ipv4/tcp_tw_reuse
该文件表示是否允许重新应用处于TIME-WAIT状态的socket用于新的TCP连接。
/proc/sys/net/ipv4/tcp_tw_recycle
recyse是加速TIME-WAIT sockets回收
对tcp_tw_reuse和tcp_tw_recycle的修改,可能会出现.warning, got duplicate tcp line warning, got BOGUS tcp line.上面这二个参数指的是存在这两个完全一样的TCP连接,这会发生在一个连接被迅速的断开并且重新连接的情况,而且使用的端口和地址相同。但基本 上这样的事情不会发生,无论如何,使能上述设置会增加重现机会。这个提示不会有人和危害,而且也不会降低系统性能,目前正在进行工作
/proc/sys/net/ipv4/tcp_keepalive_time
表示当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时
/proc/sys/net/ipv4/tcp_fin_timeout 最佳值和BSD一样为30
fin_wait1状态是在发起端主动要求关闭tcp连接,并且主动发送fin以后,等待接收端回复ack时候的状态。对于本端断开的socket连接,TCP保持在FIN-WAIT-2状态的时间。对方可能会断开连接或一直不结束连接或不可预料的进程死亡。
/proc/sys/net/core/netdev_max_backlog
该文件指定了,在接口接收数据包的速率比内核处理这些包的速率快时,允许送到队列的数据包的最大数目。
Submitted by admin on 2008, October 13, 11:52 AM
#netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’
LAST_ACK 14
SYN_RECV 348
ESTABLISHED 70
FIN_WAIT1 229
FIN_WAIT2 30
CLOSING 33
TIME_WAIT 18122
状态:描述
CLOSED:无连接是活动的或正在进行
LISTEN:服务器在等待进入呼叫
SYN_RECV:一个连接请求已经到达,等待确认
SYN_SENT:应用已经开始,打开一个连接
ESTABLISHED:正常数据传输状态
FIN_WAIT1:应用说它已经完成
FIN_WAIT2:另一边已同意释放
ITMED_WAIT:等待所有分组死掉
CLOSING:两边同时尝试关闭
TIME_WAIT:另一边已初始化一个释放
LAST_ACK:等待所有分组死掉
也就是说,这条命令可以把当前系统的网络连接状态分类汇总。
下面解释一下为啥要这样写:
一个简单的管道符连接了netstat和awk命令。
——————————————————————
先来看看netstat:
netstat -n
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 123.123.123.123:80 234.234.234.234:12345 TIME_WAIT
你实际执行这条命令的时候,可能会得到成千上万条类似上面的记录,不过我们就拿其中的一条就足够了。
——————————————————————
再来看看awk:
/^tcp/
滤出tcp开头的记录,屏蔽udp, socket等无关记录。
state[]
相当于定义了一个名叫state的数组
NF
表示记录的字段数,如上所示的记录,NF等于6
$NF
表示某个字段的值,如上所示的记录,$NF也就是$6,表示第6个字段的值,也就是TIME_WAIT
state[$NF]
表示数组元素的值,如上所示的记录,就是state[TIME_WAIT]状态的连接数
++state[$NF]
表示把某个数加一,如上所示的记录,就是把state[TIME_WAIT]状态的连接数加一
END
表示在最后阶段要执行的命令
for(key in state)
遍历数组
print key,”\t”,state[key]
打印数组的键和值,中间用\t制表符分割,美化一下。
如发现系统存在大量TIME_WAIT状态的连接,通过调整内核参数解决,
vim /etc/sysctl.conf
编辑文件,加入以下内容:
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
然后执行 /sbin/sysctl -p 让参数生效。
net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭;
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。
net.ipv4.tcp_fin_timeout 修改系統默认的 TIMEOUT 时间
下面附上TIME_WAIT状态的意义:
客户端与服务器端建立TCP/IP连接后关闭SOCKET后,服务器端连接的端口
状态为TIME_WAIT
是不是所有执行主动关闭的socket都会进入TIME_WAIT状态呢?
有没有什么情况使主动关闭的socket直接进入CLOSED状态呢?
主动关闭的一方在发送最后一个 ack 后
就会进入 TIME_WAIT 状态 停留2MSL(max segment lifetime)时间
这个是TCP/IP必不可少的,也就是“解决”不了的。
也就是TCP/IP设计者本来是这么设计的
主要有两个原因
1。防止上一次连接中的包,迷路后重新出现,影响新连接
(经过2MSL,上一次连接中所有的重复包都会消失)
2。可靠的关闭TCP连接
在主动关闭方发送的最后一个 ack(fin) ,有可能丢失,这时被动方会重新发
fin, 如果这时主动方处于 CLOSED 状态 ,就会响应 rst 而不是 ack。所以
主动方要处于 TIME_WAIT 状态,而不能是 CLOSED 。
TIME_WAIT 并不会占用很大资源的,除非受到攻击。
还有,如果一方 send 或 recv 超时,就会直接进入 CLOSED 状态
Submitted by admin on 2008, October 10, 3:08 PM
kernel :CPU1: Running in modulated clock mode
kernel :CPU1: Temperature above threshold
服务器CPU工作温度过高.
查询资料后得知是 2.6 内核的相应阀值过低造成了这种状况。
vi /etc/syslog.conf
注释掉 *.emerg 这一行
/etc/init.d/syslog restart
就不会出现 CPU 温度过高的警告了,不知道会 不会出现其他错误...
Submitted by admin on 2008, October 10, 1:56 PM
提示
Oct 10 13:47:20 localhost kernel: printk: 30 messages suppressed.
Oct 10 13:47:20 localhost kernel: TCP: time wait bucket table overflow
Oct 10 13:47:20 localhost last message repeated 9 times
Oct 10 13:47:27 localhost kernel: printk: 107 messages suppressed.
Oct 10 13:47:27 localhost kernel: TCP: time wait bucket table overflow
Oct 10 13:49:05 localhost kernel: printk: 239 messages suppressed.
Oct 10 13:49:05 localhost kernel: TCP: time wait bucket table overflow
加大 /proc/sys/net/ipv4/tcp_max_tw_buckets 值,默认为38000
可以直接 echo 50000 > /proc/sys/net/ipv4//proc/sys/net/ipv4/tcp_max_tw_buckets
或设置sysctl