转“Tokyo Tyrant问题二三解”
转发：
http://live.shopex.cn/archives/306
[root@localhost search]# [root@localhost search]# strace -T -c -p 3464Process 3464 attached - interrupt to quitProcess 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[root@localhost search]#
CPU占用高现象：前段在应用中，发现读写的时候，load会猛然慢慢偏高，且不会降低的状况。慢慢的会使用cpu，800%，然后直至不提供服务。现场：ttsever双主服务，分配部署到8g，8核机器的两台服务器上。网络为千M。解决：使用strace命令strace -T -c -p pid#ttserver pidctrl+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 fromkilling the disk.logdir='/path/to/ttserver/ulog/'mydir=`ls -t $logdir` it=1 for file in $mydirdo if [ $it -gt 5 ] then echo file $it will be deleted: $logdir$file #rm -rf $file fi it=$((it+1))done