转“Tokyo Tyrant问题二三解”

转发：
http://live.shopex.cn/archives/306
[code="java"]#
# strace -T -c -p 3464
Process 3464 attached - interrupt to quit
Process 3464 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00 0.001997 33 61 epoll_wait
0.00 0.000000 0 1 write
0.00 0.000000 0 1 stat
------ ----------- ----------- --------- --------- ----------------
100.00 0.001997 63 total
#[/code]

CPU占用高

现象：

前段在应用中，发现读写的时候，load会猛然慢慢偏高，且不会降低的状况。慢慢的会使用cpu，800%，然后直至不提供服务。

现场：

ttsever双主服务，分配部署到8g，8核机器的两台服务器上。

网络为千M。

解决：

使用strace命令

strace -T -c -p pid#ttserver pid
ctrl+c #终端请求
发现futex锁狂多，最后分析得出是因为thnum开的太少，而导致写入或读取锁在读写队列里堆积。
因此调整了thnum的启动参数，暂观察期间，调整为1000。

——————————–华丽的分割线—————————————


ulog狂大和io读写高的问题


现象：

忽然发现两台ttserver硬盘报警，发现ulog狂多。
且使用iotop查看读写频度。发现写入为6m/s。

现场：
同上。

解决：
ttserver的ulog同步机制使用的是rts后缀文件做的最后同步时间搓。
发现量变的时间错文件时间不对，但tch文件(数据存储文件)为相同大小。
因此大致判断文件已经同步结束。

那么造成继续ulog狂写的原理就是两服务器的date时间不一致。

查看果然如此。

解决方案如下：

ntpdate调整crontab频度，加大为每分钟同步。
查看rts文件，写入两台机器最大时间到rts机器。
关闭服务。
删除ulog文件
重启服务。

备注，请开打ulim参数到1024.要不你会发现都是小的124文件，删除就要用复杂的命令了，以为参数过长。

ls -al ulog | awk '{print ulog/$8}' | xargs rm -f
附录

#!/bin/bash

# Deletes all but the newest 5 files to keep Tokyo Tyrant ulogs from
killing the disk.
logdir='/path/to/ttserver/ulog/'
mydir=`ls -t $logdir` it=1

for file in $mydir
do
    if [ $it -gt 5 ]
    then
        echo file $it will be deleted: $logdir$file
        #rm -rf $file
    fi
    it=$((it+1))
done