Chinaunix首页 | 论坛 | 博客
  • 博客访问: 224943
  • 博文数量: 27
  • 博客积分: 1151
  • 博客等级: 少尉
  • 技术积分: 426
  • 用 户 组: 普通用户
  • 注册时间: 2010-06-15 19:25
文章分类
文章存档

2012年(5)

2011年(6)

2010年(16)

我的朋友

分类: LINUX

2011-03-01 22:28:22

By fireworks2@foxmail.com

前一段有个代码出了点bug,花了好几天才找到问题,这里总结一下,以后也好有个参考。网络程序本来就不便重现错误,况且有些还是多线程的,调试难度就更大了。


发包逻辑
|
|
客户端 ---网络1--> 服务器
                    |
                   处理
                    |
客户端 <--网络2--- 服务器
|
|
收包逻辑


0. 观察各个LOG是否呈现出异常,可以最快找到问题所在,如若不行才看下面的几步

1. 先确定问题所属的模块
   参考上面的简化示意图,确定问题是出在那个模块
   ——客户端,比对各个客户端的响应情况即可得出结论
   ——网络,使用tcpdump、netcat等工具进行分析
   ——服务器,从收到的数据包的波动、类别构成分析,看是否近期出现异动

2. 进一步定位具体位置
   问题可能出在:代码、代码的运行环境
   ——可以通过这些数据分析:CPU占用情况、文件IO、内存使用、DB访问/连接情况(用到的工具有sar、iostat、top等)
   ——结合看到的数据情况,简单浏览代码(看主要的部分,BIG O)
   ——给代码的关键位置添加LOG,观测所产生的日志

3. 修复故障


另外的几个小体会
a 调试问题,日志是最高效的
b usleep会引起调度,对代码性能的具体影响还没仔细测试
  测试多线程的服务器要使用异步发包、或者多个客户端线程/进程同时发包

c 读写锁在读多写少的时候比普通锁更有效
d 要想提高多线程的并发度,就要压缩加锁的时间长度、或采取无锁数据结构
e 多线程的最优线程数视可并发的程度、CPU个数而定
f 尽量不使用多线程,一旦出错,调试太过复杂;多线程在性能上的那点好处,完全可以用多进程、轻重分离等办法获得
 
g. 资源充足的前提下,代码性能不符合要求的原因可能是等待过多(看进程状态)

阅读(2196) | 评论(0) | 转发(3) |
给主人留下些什么吧!~~