meisw's blog

关于ulimit命令的一些用法，其中有
ulimit -n 4096
也就是限制用户的最大文件打开数为4096个

在网上查了关于怎么查看文件打开数的文章大致有两种说法

/proc/sys/fs/file-nr
该文件与 file-max 相关，它有三个值：

已分配文件句柄的数目
已使用文件句柄的数目
文件句柄的最大数目
该文件是只读的，仅用于显示信息。

查看所有进程的文件打开数
lsof |wc -l

查看某个进程打开的文件数
lsof -p pid |wc -l

因为LINUX的内核机制，一般情况下不需要特意去释放已经使用的cache。这些cache起来的内容可以增加文件以及的读写速度。
先说下free命令怎么看内存

[root@yuyii proc]# free
total used free shared buffers cached
Mem: 515588 295452 220136 0 2060 64040
-/+ buffers/cache: 229352 286236
Swap: 682720 112 682608


其中第一行用全局角度描述系统使用的内存状况：
total——总物理内存
used——已使用内存，一般情况这个值会比较大，因为这个值包括了cache+应用程序使用的内存
free——完全未被使用的内存
shared——应用程序共享内存
buffers——缓存，主要用于目录方面,inode值等（ls大目录可看到这个值增加）
cached——缓存，用于已打开的文件
note:
total=used+free
used=buffers+cached (maybe add shared also)

第二行描述应用程序的内存使用：
前个值表示-buffers/cache——应用程序使用的内存大小，used减去缓存值
后个值表示+buffers/cache——所有可供应用程序使用的内存大小，free加上缓存值
note:
-buffers/cache=used-buffers-cached
+buffers/cache=free+buffers+cached

第三行表示swap的使用：
used——已使用
free——未使用

cache释放：
To free pagecache:
echo 1 > /proc/sys/vm/drop_caches
To free dentries and inodes:
echo 2 > /proc/sys/vm/drop_caches
To free pagecache, dentries and inodes:
echo 3 > /proc/sys/vm/drop_caches

说明，释放前最好sync一下，防止丢数据。

有关/proc/sys/vm/drop_caches的用法在下面进行了说明

/proc/sys/vm/drop_caches (since Linux 2.6.16)
Writing to this file causes the kernel to drop clean caches,
dentries and inodes from memory, causing that memory to become
free.
To free pagecache, use echo 1 > /proc/sys/vm/drop_caches; to
free dentries and inodes, use echo 2 > /proc/sys/vm/drop_caches;
to free pagecache, dentries and inodes, use echo 3 >
/proc/sys/vm/drop_caches.
Because this is a non-destructive operation and dirty objects
are not freeable, the user should run sync(8) first.

---------

在执行上面的操作前，应先执行一下sync 以保证数据的完整性

手动执行sync命令(描述:sync 命令运行 sync 子例程。假如必须停止系统，则运行 sync 命令以确保文档系统的完整性。sync 命令将任何未写的系统缓冲区写到磁盘中，包含已修改的 i-node、已延迟的块 I/O 和读写映射文档)

sync
echo 1 > /proc/sys/vm/drop_caches
echo 2 > /proc/sys/vm/drop_caches
echo 3 > /proc/sys/vm/drop_caches

http://www.edgedesign.us/about/lm_sensors
http://www.lm-sensors.org/wiki/Download

sensors-detect
/etc/rc.d/init.d/lm_sensors start ()
/etc/rc.d/init.d/lm_sensors status
sensors

eeprom-i2c-0-56
Adapter: SMBus I801 adapter at 1440
Unknown EEPROM type (8)

eeprom-i2c-0-55
Adapter: SMBus I801 adapter at 1440
Unknown EEPROM type (8)

eeprom-i2c-0-52
Adapter: SMBus I801 adapter at 1440
Unknown EEPROM type (8)

eeprom-i2c-0-51
Adapter: SMBus I801 adapter at 1440
Unknown EEPROM type (8)

adt7463-i2c-0-2e
Adapter: SMBus I801 adapter at 1440
ERROR: Can't get alarm mask data!
V1.5:      +3.216 V  (min =  +1.42 V, max =  +1.58 V)   ALARM
VCore:     +1.313 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
V3.3:      +3.334 V  (min =  +3.13 V, max =  +3.47 V)
V5:       +5.130 V  (min =  +4.74 V, max =  +5.26 V)
V12:      +0.063 V  (min = +11.38 V, max = +12.62 V)   ALARM
CPU_Fan:      0 RPM  (min = 4000 RPM)                     ALARM
CPU:      +87.00癈  (low  =   +10癈, high =   +50癈)     ALARM
Board:    +38.00癈  (low  =   +10癈, high =   +35癈)     ALARM
Remote:   +41.00癈  (low  =   +10癈, high =   +35癈)     ALARM
CPU_PWM:   255
Fan2_PWM:  255
Fan3_PWM:  255

adt7463-i2c-0-2c
Adapter: SMBus I801 adapter at 1440
ERROR: Can't get alarm mask data!
V1.5:      +3.216 V  (min =  +1.42 V, max =  +1.58 V)   ALARM
VCore:     +1.301 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
V3.3:      +3.317 V  (min =  +3.13 V, max =  +3.47 V)
V5:       +5.026 V  (min =  +4.74 V, max =  +5.26 V)
V12:      +0.063 V  (min = +11.38 V, max = +12.62 V)   ALARM
CPU_Fan:      0 RPM  (min = 4000 RPM)                     ALARM
CPU:      +56.00癈  (low  =   +10癈, high =   +50癈)     ALARM
Board:    +35.00癈  (low  =   +10癈, high =   +35癈)     ALARM
Remote:   +49.00癈  (low  =   +10癈, high =   +35癈)     ALARM
CPU_PWM:   128
Fan2_PWM:  255
Fan3_PWM:  128

#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 状态

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 = 30 表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间。
　　net.ipv4.tcp_keepalive_time = 1200 表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为20分钟。
　　net.ipv4.ip_local_port_range = 1024 65000 表示用于向外连接的端口范围。缺省情况下很小：32768到61000，改为1024到65000。
　　net.ipv4.tcp_max_syn_backlog = 8192 表示SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数。
　　net.ipv4.tcp_max_tw_buckets = 5000 表示系统同时保持TIME_WAIT套接字的最大数量，如果超过这个数字，TIME_WAIT套接字将立刻被清除并打印警告信息。
默  认为180000，改为5000。对于Apache、Nginx等服务器，上几行的参数可以很好地减少TIME_WAIT套接字数量，但是对于Squid，效果却不大。此项参数可以控制TIME_WAIT套接字的最大数量，避免Squid服务器被大量的TIME_WAIT套接字拖死。

注:
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1

设置这两个参数： reuse是表示是否允许重新应用处于TIME-WAIT状态的socket用于新的TCP连接； recyse是加速TIME-WAIT sockets回收

rsync warning: some files vanished before they could be transferred (code 24) at main.c(702)

rsync  version 2.6.3  protocol version 28

update
http://rsync.samba.org/
http://rsync.samba.org/ftp/rsync/

Linux下如何查看某一进程的CPU占用率

http://linux.ccidnet.com/art/9513/20070423/1068127_1.html

http://www.ibm.com/developerworks/cn/linux/l-selinux.html

一直是用apache,也早早就听说过nginx的性能是如何如何的优越,却也一直没有亲自测试过.
最近有一台机的负载好大,CPU的资源,基本上是用完.

后用了nginx来试,而且,也把原来的PHP程序换成了CGI(因为这台机的功能,代码都很简单),这个nginx的编译,也是优化了CGI的编译的.速度确实快了好多.
主要原因,一是用nginx,且用了专门优化了CGI的,代码也换了,而且,对访问方式也作了一些调整

记录一些数据:
 所有连接 开始连接 正在连接 结束连接
apache 15万   2-4K   (2-5K) (120K)
nginx 10万   1K   60K    70K

有些值相差是比较大,我想这和我的设置时间有关
apache的连接时间都很短,而nginx的是apache的10倍差不多

不过从测试的结果来看,nginx的响应上,确实比apache快得多.
不过,流量或连接大到一定大的时候.nginx会直接丢掉,而apache等待的时间会长一点
所以,用nginx时,会丢掉一连接,从一些数据统计中,可以看到

硬件配置,双至强3.0,4G内存