ShopEx生产队的故事

纯文本，很简单。非常爷们！


ZBXDm{
"request":"sender data",
"data":[{
"host":"ZABBIX Server",
"key":"option key",
"value":"options value"
}]}


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

本文通过三个实际案例演示如何使用truss、strace和ltrace这三个常用的调试工具来快速诊断软件的”疑难杂症”。

简介

进程无法启动，软件运行速度突然变慢，程序的”Segment Fault”等等都是让每个Unix系统用户头痛的问题，本文通过三个实际案例演示如何使用truss、strace和ltrace这三个常用的调试工具来快速诊断软件的”疑难杂症”。

truss和strace用来 跟踪一个进程的系统调用或信号产生的情况，而 ltrace用来 跟踪进程调用库函数的情况。 truss是早期为System V R4开发的调试程序，包括Aix、FreeBSD在内的大部分Unix系统都自带了这个工具；而strace最初是为SunOS系统编写的，ltrace 最早出现在GNU/Debian Linux中。这两个工具现在也已被移植到了大部分Unix系统中，大多数Linux发行版都自带了strace和ltrace，而FreeBSD也可通 过Ports安装它们。

你不仅可以从命令行调试一个新开始的程序，也可以把truss、strace或ltrace绑定到一个已有的PID上来调试一个正在运行的程序。三个调试工具的基本使用方法大体相同，下面仅介绍三者共有，而且是最常用的三个命令行参数：

-f ：除了跟踪当前进程外，还跟踪其子进程。
-o file ：将输出信息写到文件file中，而不是显示到标准错误输出（stderr）。
-p pid ：绑定到一个由pid对应的正在运行的进程。此参数常用来调试后台进程。

使用上述三个参数基本上就可以完成大多数调试任务了，下面举几个命令行例子：

truss -o ls.truss ls -al： 跟踪ls -al的运行，将输出信息写到文件/tmp/ls.truss中。
strace -f -o vim.strace vim： 跟踪vim及其子进程的运行，将输出信息写到文件vim.strace。
ltrace -p 234： 跟踪一个pid为234的已经在运行的进程。

三个调试工具的输出结果格式也很相似，以strace为例：

brk(0)                                  = 0x8062aa8
brk(0x8063000)                          = 0x8063000
mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE, 3, 0x92f) = 0x40016000

每一行都是一条系统调用，等号左边是系统调用的函数名及其参数，右边是该调用的返回值。 truss、strace和ltrace的工作原理大同小异，都是使用ptrace系统调用跟踪调试运行中的进程，详细原理不在本文讨论范围内，有兴趣可以参考它们的源代码。

下面举两个实例演示如何利用这三个调试工具诊断软件的”疑难杂症”：

案例一：运行clint出现Segment Fault错误

操作系统：FreeBSD-5.2.1-release

clint是一个C++静态源代码分析工具，通过Ports安装好之后，运行：

# clint foo.cpp
Segmentation fault (core dumped)

在Unix系统中遇见”Segmentation Fault”就像在MS Windows中弹出”非法操作”对话框一样令人讨厌。OK，我们用truss给clint”把把脉”：

# truss -f -o clint.truss clint
Segmentation fault (core dumped)
# tail clint.truss
  739: read(0x6,0x806f000,0x1000)               = 4096 (0x1000)
  739: fstat(6,0xbfbfe4d0)                       = 0 (0x0)
  739: fcntl(0x6,0x3,0x0)                        = 4 (0x4)
  739: fcntl(0x6,0x4,0x0)                        = 0 (0x0)
  739: close(6)                                    = 0 (0x0)
  739: stat("/root/.clint/plugins",0xbfbfe680)   ERR#2 'No such file or directory'
SIGNAL 11
SIGNAL 11
Process stopped because of:  16
process exit, rval = 139

我们用truss跟踪clint的系统调用执行情况，并把结果输出到文件clint.truss，然后用tail查看最后几行。注意看clint执行的最后一条系统调用（倒数第五行）： stat("/root/.clint/plugins",0xbfbfe680) ERR#2 'No such file or directory'，问题就出在这里：clint找不到目录”/root/.clint/plugins”，从而引发了段错误。怎样解决？很简单： mkdir -p /root/.clint/plugins，不过这次运行clint还是会”Segmentation Fault”9。继续用truss跟踪，发现clint还需要这个目录”/root/.clint/plugins/python”，建好这个目录后clint终于能够正常运行了。

案例二：vim启动速度明显变慢

操作系统：FreeBSD-5.2.1-release

vim 版本为6.2.154，从命令行运行vim后，要等待近半分钟才能进入编辑界面，而且没有任何错误输出。仔细检查了.vimrc和所有的vim脚本都没有 错误配置，在网上也找不到类似问题的解决办法，难不成要hacking source code？没有必要，用truss就能找到问题所在：

# truss -f -D -o vim.truss vim

这里-D参数的作用是：在每行输出前加上相对时间戳，即每执行一条系统调用所耗费的时间。我们只要关注哪些系统调用耗费的时间比较长就可以了，用less仔细查看输出文件vim.truss，很快就找到了疑点：

735: 0.000021511 socket(0x2,0x1,0x0)       = 4 (0x4)
735: 0.000014248 setsockopt(0x4,0x6,0x1,0xbfbfe3c8,0x4) = 0 (0x0)
735: 0.000013688 setsockopt(0x4,0xffff,0x8,0xbfbfe2ec,0x4) = 0 (0x0)
735: 0.000203657 connect(0x4,{ AF_INET 10.57.18.27:6000 },16) ERR#61 'Connection refused'
735: 0.000017042 close(4)          = 0 (0x0)
735: 1.009366553 nanosleep(0xbfbfe468,0xbfbfe460) = 0 (0x0)
735: 0.000019556 socket(0x2,0x1,0x0)       = 4 (0x4)
735: 0.000013409 setsockopt(0x4,0x6,0x1,0xbfbfe3c8,0x4) = 0 (0x0)
735: 0.000013130 setsockopt(0x4,0xffff,0x8,0xbfbfe2ec,0x4) = 0 (0x0)
735: 0.000272102 connect(0x4,{ AF_INET 10.57.18.27:6000 },16) ERR#61 'Connection refused'
735: 0.000015924 close(4)          = 0 (0x0)
735: 1.009338338 nanosleep(0xbfbfe468,0xbfbfe460) = 0 (0x0)

vim试图连接10.57.18.27这台主机的 6000端口（第四行的connect（）），连接失败后，睡眠一秒钟继续重试（第6行的nanosleep（））。以上片断循环出现了十几次，每次都要 耗费一秒多钟的时间，这就是vim明显变慢的原因。可是，你肯定会纳闷：”vim怎么会无缘无故连接其它计算机的6000端口呢？”。问得好，那么请你回 想一下6000是什么服务的端口？没错，就是X Server。看来vim是要把输出定向到一个远程X Server，那么Shell中肯定定义了DISPLAY变量，查看.cshrc，果然有这么一行： setenv DISPLAY ${REMOTEHOST}:0，把它注释掉，再重新登录，问题就解决了。

案例三：用调试工具掌握软件的工作原理

操作系统：Red Hat Linux 9.0

用 调试工具实时跟踪软件的运行情况不仅是诊断软件”疑难杂症”的有效的手段，也可帮助我们理清软件的”脉络”，即快速掌握软件的运行流程和工作原理，不失为 一种学习源代码的辅助方法。下面这个案例展现了如何使用strace通过跟踪别的软件来”触发灵感”，从而解决软件开发中的难题的。

大 家都知道，在进程内打开一个文件，都有唯一一个文件描述符（fd：file descriptor）与这个文件对应。而本人在开发一个软件过程中遇到这样一个问题：已知一个fd ，如何获取这个fd所对应文件的完整路径？不管是Linux、FreeBSD或是其它Unix系统都没有提供这样的API，怎么办呢？我们换个角度思 考：Unix下有没有什么软件可以获取进程打开了哪些文件？如果你经验足够丰富，很容易想到lsof，使用它既可以知道进程打开了哪些文件，也可以了解一 个文件被哪个进程打开。

好，我们用一个小程序来试验一下lsof，看它是如何获取进程打开了哪些文件。

/* testlsof.c */
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
int main(void)
{
        open("/tmp/foo", O_CREAT|O_RDONLY);    /* 打开文件/tmp/foo */
        sleep(1200);                                /* 睡眠1200秒，以便进行后续操作 */
        return 0;
}

将testlsof放入后台运行，其pid为3125。命令lsof -p 3125查看进程3125打开了哪些文件，我们用strace跟踪lsof的运行，输出结果保存在lsof.strace中：

# gcc testlsof.c -o testlsof
# ./testlsof &
[1] 3125
# strace -o lsof.strace lsof -p 3125

我们以”/tmp/foo”为关键字搜索输出文件lsof.strace，结果只有一条：

# grep '/tmp/foo' lsof.strace
readlink("/proc/3125/fd/3", "/tmp/foo", 4096) = 8

原来lsof巧妙的利用了/proc/nnnn/fd /目录（nnnn为pid）：Linux内核会为每一个进程在/proc/建立一个以其pid为名的目录用来保存进程的相关信息，而其子目录fd保存的是 该进程打开的所有文件的fd。目标离我们很近了。好，我们到/proc/3125/fd/看个究竟：

# cd /proc/3125/fd/
# ls -l
total 0
lrwx------    1 root     root           64 Nov  5 09:50 0 -> /dev/pts/0
lrwx------    1 root     root           64 Nov  5 09:50 1 -> /dev/pts/0
lrwx------    1 root     root           64 Nov  5 09:50 2 -> /dev/pts/0
lr-x------    1 root     root           64 Nov  5 09:50 3 -> /tmp/foo
# readlink /proc/3125/fd/3
/tmp/foo

答案已经很明显了：/proc/nnnn/fd/目录下的每一个fd文件都是符号链接，而此链接就指向被该进程打开的一个文件。我们只要用readlink()系统调用就可以获取某个fd对应的文件了，代码如下：

#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/stat.h>
int get_pathname_from_fd(int fd, char pathname[], int n)
{
        char buf[1024];
        pid_t  pid;
        bzero(buf, 1024);
        pid = getpid();
        snprintf(buf, 1024, "/proc/%i/fd/%i", pid, fd);
        return readlink(buf, pathname, n);
}
int main(void)
{
        int fd;
        char pathname[4096];
        bzero(pathname, 4096);
        fd = open("/tmp/foo", O_CREAT|O_RDONLY);
        get_pathname_from_fd(fd, pathname, 4096);
        printf("fd=%d; pathname=%s\n", fd, pathname);
        return 0;
}

【注】出于安全方面的考虑，在FreeBSD 5 之后系统默认已经不再自动装载proc文件系统，因此，要想使用truss或strace跟踪程序，你必须手工装载proc文件系统：mount -t procfs proc /proc；或者在/etc/fstab中加上一行：

proc                   /proc           procfs  rw              0       0

ltrace不需要使用procfs。

参考资料

• truss(1) manual page
• strace(1) manual page
• ltrace(1) manual page
• ptrace(2) manual page
• lsof(1) manual page
• Debugging with strace： http://www.devchannel.org/devtoolschannel/03/10/24/2057246.shtml

注意:进行tracelog时,尤其是ltrace时,log文件极其庞大,10秒钟即可达几十M,严禁长时间后台运行以防磁盘撑爆!

我们在性能分析shopex性能的时候。
发现用在php的语法解析上的损耗占了很大比重
如果用valgrind看他的C调用的话，就会发现大约50%的时间被用在lex&yacc上面。
也就是由php代码转成opcode的部分。即php的代码解释损耗。

这个方面性能的优化极限目标是： 一个访问只运行一个php文件，并且这个文件里不包含任何与这个流程无关的代码。

如何兼顾代码结构容易理解和性能是个挑战

我们的处理思路是，通过类似smarty的编译系统，将访问编译成一个个文件：因为shopex是mvc的结构，那么编译粒度就每个控制器的方法对应一个流程文件。

当控制器第一次调用时，通过一种方法监控流经的每个model-method，子过程等等，最后抽取剥离出来，加上公用的数据库连接函数，配置文件等等一起组合成一个单一的终极php文件。
至于缓存的更新基本就是版本的更新，每次升级的时候。touch一个cachestat文件的最后修改时间即可。

那么实现的挑战有两个：

* 一个叫model的函数化 (这样叫很酷，有点像虚的死神化) 。是弱化model层对象特性，让类退化为仅是函数的容器，减少继承，重载这些应用。
* 二是实现一个自己的编译引擎。

上面两条最新的shopex485已经走了很远了，商品和订单的函数都已经拆分了。
第二个我们自己实现了一个叫tramsy的解析器( 翻转(smart)+y )，特点是把大量的插件改成了编译型。
强化了编译插件的特性，增加了一种编译型modifier的插件类型。并且提出了变量预绑定的概念：

{if $var=1}

{/if}

如果是原生的smarty，生成的代码是：

vars['var']==1){ ?>

如果在tramsy里，程序员预测var一定是1，并且有把握在其值改变的时候系统自动清除模板缓存，就可以把他设置为”预绑定变量”
那么最终生成的代码就是：

这个设计大约减少了一倍多的编译结果。性能提升了大约20%。

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时间不一致。

查看果然如此。

解决方案如下：

备注，请开打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

这里没有我，只有我们！
Powered by Dev@ShopEx

5分钟前在写一段Delphi的程式，遇到一个很奇怪的bug，以下是具有bug的源代码：

Pos:= round((FCursorPos.x-ClientOrigin.x) * (FMax-FMin) / width)

代码的原意显然很简单，取上一次鼠标X轴的位置，减去当前鼠标的X轴位置，乘以最大和最小的点的差值再除以宽度

代码的功能是一个自定义控件中的一部分，控件的功能是TrackBar。

代码本意显然没问题，结果缺最大只有到6百五十多W，由于是算数运算，单步调试很困难，但是65XXXXX这种数字让我突然觉得是超出最大的INT边界，但检查了所有变脸，发现所有的变量都已经声明成了int64。

无奈中将代码略作修改：

Pos:= round((FCursorPos.x-ClientOrigin.x) * ((FMax-FMin) / width))

结果就对了。

小学老师所说的乘除运算不分运算优先级，被小学数学思维固化……

freebsd下:
sysctl net.inet.ip.portrange.reservedhigh=0

linux下：
安装fd_server

http://yaws.hyber.org/download/fd_server-2.3.0.tgz

向借口开刀是决定你能否胜出一般人的标志，褪墨最新系列《拒绝借口》。

事业生涯的发展是一个过程，绝非一蹴而就的事情。它需要人们拒绝借口，付出很多琐碎的努力。在这个过程中，你必须依靠日积月累的办法，最终，这些琐碎的努力都会像涓涓细流聚为势不可挡的汹涌波涛，而且有的时候，成功的到来比你预计的要早。因此，任何人都应当在事业生涯面前力戒浮躁性格的滋生。认识这一点，对你大有好处。

你知道吗，工作中失败的惟一可能是你渴望某种事物却不采取实际行动去争取它。对于梦想，你需要采取步骤去发现，去把握、去争取、甚至去创造！这就要踏踏实实开始你的计划。

明确了方向，确定了目标，就应该用实际行动去追求你的理想。

这听起来很简单，但成千上万的人们都没能做到这一点。

成功属于谁？属于那些充满自信、锲而不舍的追求者。他们永远全身心地投入、永远保持着高度的热忱。当然，要做到不屈不挠并不容易，人人都有脆弱的时候，没有必要永远硬着头皮保持一副硬汉形象。有时候，你的理想会显得那么遥不可及，或是看上去只是一个无法实现的幻想。原因很可能在于你自己太急于求成了。这时不妨放慢节奏，循序渐进。成功人士往往总比别人先行一步，日积月累，他们的身后便留下一串超越常人的值得骄傲的业绩。懂得了这个道理，都会成功。

某位演员认为：“当演员的收入并不高，但他说他永远不会放弃这一行，与此同时，他也知道自己对于成功的理解是与很多人大相径庭的。当今社会观念看来，我的工作并不稳定，也不成功，虽然我也一直梦想能够拥有自己的房子，每两年换一部新车，在很行里存一大笔钱，随心所欲地出入饭店，周游世界等等。但是为了心爱的演艺事业，我在很大程度上力戒浮躁的性格，放弃了一些奢侈的梦想。

从很早开始，基恩·罗德伯瑞就一直梦想创作一部关于到外星旅行的科幻系列片。可是，他的这一想法却没能得到电视台的支持，因为他们认为基恩的想法过于离奇，不会得到观众的认可。在这种情况下，基恩并没有浮躁，没有放弃自己的主张，他认为高质量的科幻片肯定能受到美国电视观众的欢迎。如今，距离他的《星球之旅》首播已有30多年了，这部片子成为美国文化的一部分，剧中的不少台词也进入我们的日常用语。《星球之旅——未来人类》是电视网最受欢迎的节目。

对吉姆·阿伯来说，不存在“浮躁“这个词。虽然生理上有缺陷，但他去没有因此滋生浮躁的性格。1992年，他成为历史上第一位入选一流棒球队的独臂投球手。1993年，他作为优秀的投球手，加盟纽约扬基队。

无论人是当演员，创作电视片，打棒球，还是组建自己的乐队或当喜剧明星，这并不要紧。要紧的是，你在为自己定下成功的目标以后开始行动，锲而不舍，力戒浮躁的性格困扰你。

具有浮躁性格的人常常翻箱倒柜地寻找他亲手放置的东西，有时连自己站在哪里都莫名其妙。他不知道自己所念过的书是否已经了解；他常常迟到；他记起账目来总得复算好几遍，涂改许多次，才能正确无误。总之，他无异于在杂乱无章的垃圾堆里过完了一生。这种环性格不但害了自己，并且还带环了别人，凡是在他手下工作的人，都将他视作榜样，不把事情当做事情去做，只知应付了事，因为他们看见上司也是这样，到头来，所有的人都将受害无穷。他们事事都做不好，处处都乱七八糟。他们的整个商店既已深深地中了这个毒，生意当然将大大地清淡下去，弄得门可罗雀。到那时惟有自怨自艾、自叹命薄了。他再也想不到自己一生的事业，完全会败在这样的性格病上。

我们真诚地希望一般青年男女牢记这几句话：事情不分大小，都应使出全部精力，做得完美无缺，否则还不如不做。一个人如能从小养成这样的好习惯，他的生活将一定过得满足愉快，无牵无绊。

要想过上一种美满愉快的生活，只需做事精益求精，力求完善。当一个人把事情处理得顺顺当当、无牵无挂时，他心里的愉快，真非笔墨所能形容。那些做事草率疏忽，错误多端的人，不但对不起事情，并且对不起自己。

这里我们谨以一句金言奉赠各位：“竭力养成爱美的习惯！”如果你接受这一贴兴奋剂，你的胸怀一定会开阔不少，你的品格一定将受到极大的感化。世上再没有其他好办法能使你在精神、才能上获得这样的益处。

有许多人往往不肯把事情做得尽善尽美，只用“足够了”、“差不多了”来搪塞了事。结果因为他们没有把根基打牢，所以不多时，便像一所不稳定的房屋一样倒塌了。

失败最有效的诀窍，就是从小养成不整洁的习惯。而成功的最好方法，就是把任何事情都做理精益求精，尽善尽美。

一个人把事情做得十分完善之后，即使晚上躺在床上，也会快活不少。这真是一贴延年益寿的奇方。

做事精益求精，不但可以使你的精神愉快、身强体健，并且可以使你的才能迅速进步，学识日渐充实，而逐步可以胜任其他更重大的工作。所以奉劝初入社会、希望成功的青年们都要熟记四个字：“尽善尽美”。它是你一生成败的最大关键。

快些下决心吧，不要管别人做得怎么样，事情一到了你的手里，就非将它做得很完美无缺不可。你一生的希望都在这个上面，千万不要再让那些偷闲、取巧、拖拉、不整、不洁的粗陋性格来阻碍你了。

转之于：http://www.mifengtd.cn/articles/no-excuse-18.html

推荐添加订阅：http://www.mifengtd.cn/

mysql根据配置文件会限制server接受的数据包大小。

有时候大的插入和更新会被max_allowed_packet 参数限制掉，导致失败。

1） 方法1

可以编辑my.cnf来修改（windows下my.ini）,在[mysqld]段或者mysql的server配置段进行修改。

max_allowed_packet = 20M

如果找不到my.cnf可以通过

mysql --help | grep my.cnf

去寻找my.cnf文件。

2） 方法2

（很妥协，很纠结的办法）

进入mysql server

mysql -h 主机 -u 账号 -p密码
set global max_allowed_packet = 2*1024*1024*10

然后关闭掉这此mysql server链接，再进入。

show variables like 'max_%'

查看下max_allowed_packet是否编辑成功。

软件架构师往往喜欢呆在自己的象牙塔里对开发人员颐指气使，下达他的技术决策和指令。这很容易引发大家的抵触情绪，造成上下不和，最后导致产品与最初的需求相去甚远。每一个软件架构师应该懂得如何沟通,并将项目目标贯彻执行。关键是明确有效的沟通和领导能力

沟通必须简明清晰。没有人愿意阅读冗长的架构书，言简意赅地表达你的观点是项目成功的必要条件。项目启动之初，凡事能简则简，千万不要上来就写大部头的文档。使用工具,例如Visio,画简单的图表来表达你的想法，尽量简单，毕竟需求和想法总是在变化中的。另一种有效的沟通手段是非正式的白板会议，没有比把开发人员（还有其他架构师）召集起来，在白板上写下你的想法更有效的了。此外，确保随身携带相机，拍下白板上的内容，通过wiki在团队内共享，毕竟只是把想法留在白板上而脑子空空是令人沮丧的。扔掉冗长的Word文档，想办法让大家接受你的观点，最后别忘了详细记录讨论结果。

另一方面，架构师往往忽略了自己也是领导者。作为领导者，我们必须获得同伴的尊敬才能顺利开展工作。如果开发人员对项目蓝图和决策过程一无所知，那将是一场灾难。安排一位你信得过的开发人员牵头创造协作环境，依靠大家共同验证你的架构决策。让开发人员参与架构的制订过程，他们才会买你的账。与开发人员携手去搭建好的框架,而不是跟他们对着干。时刻要意识到，所有的团队成员（包括质量控制小组、业务分析员、项目经理，以及开发人员）都渴望明确的沟通和开明的领导。只有通过简明清晰的表达方式和开明的领导作风才能创建团结健康的工作环境