Lua-5.2.2

lua-5.2.2发布已有一段时间了，最近在redhat Linux平台编译时报错。这里给出解决方案，或许对某人会有帮助。

编译报错，如下：

lua@home> make linux  ... gcc -O2 -Wall -DLUA_COMPAT_ALL -DLUA_USE_LINUX    -c -o lstrlib.o lstrlib.c gcc -O2 -Wall -DLUA_COMPAT_ALL -DLUA_USE_LINUX    -c -o ltablib.o ltablib.c gcc -O2 -Wall -DLUA_COMPAT_ALL -DLUA_USE_LINUX    -c -o loadlib.o loadlib.c gcc -O2 -Wall -DLUA_COMPAT_ALL -DLUA_USE_LINUX    -c -o linit.o linit.c ar rcu liblua.a lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o         lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o lbitlib.o     lcorolib.o ldblib.o liolib.o lmathlib.o loslib.o lstrlib.o ltablib.o loadlib.o linit.o  ranlib liblua.a gcc -O2 -Wall -DLUA_COMPAT_ALL -DLUA_USE_LINUX    -c -o lua.o lua.c gcc -o lua   lua.o liblua.a -lm -Wl,-E -ldl -lreadline  /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libreadline.so: undefined reference to `PC' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libreadline.so: undefined reference to `tgetflag' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libreadline.so: undefined reference to `tgetent' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libreadline.so: undefined reference to `UP' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libreadline.so: undefined reference to `tputs' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libreadline.so: undefined reference to `tgoto' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libreadline.so: undefined reference to `tgetnum' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libreadline.so: undefined reference to `BC' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libreadline.so: undefined reference to `tgetstr' collect2: ld returned 1 exit status make[1]: *** [lua] Error 1 make[1]: Leaving directory `/home/lua/lua-5.2.2/src' make: *** [linux] Error 2 

由于lua编译依赖readline库，而其依赖ncurses库，但没有指定，所以出现“未定义的符合引用”错误。需要修改${LUA_DIR}/src/Makefile中linux编译target，在SYSLIBS变量中追加‘-lncurses’选项即可。修改后，如下：

linux:
        $(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX" SYSLIBS="-Wl,-E -ldl -lreadline -lncurses"
 

http://wangkaisino.blog.163.com/blog/static/1870444202011431112323846/

今年年初由于facebook而火起来的jemalloc广为人之，但殊不知，它在malloc界里面很早就出名了。Jemalloc的创始人Jason Evans也是在FreeBSD很有名的开发人员。此人就在2006年为提高低性能的malloc而写的jemalloc。Jemalloc是从2007年开始以FreeBSD标准引进来的。软件技术革新很多是FreeBSD发起的。在FreeBSD应用广泛的技术会慢慢导入到linux。

目前jemalloc在firefox中也在使用。在firefox2中出现了内存碎片问题之后，便在firefox3中使用了jemalloc。在safari和chrome中使用的是google的tcmalloc。

Jemalloc的技术特性

Jemalloc聚集了malloc的使用过程中所验证的很多技术。忽略细节，从架构着眼，最出色的部分仍是arena和thread cache。（事实上，这两个与tcmalloc的架构几乎相同。Jemalloc only的部分将会在另一次posting中继续探讨。）

Arena

与其像malloc一样集中管理一整块内存，不如将其分成许多个小块来分而治之。此小块便称为arena。让我们想象一下，给几个小朋友一张大图纸，让他们随意地画点。结果可想而知，他们肯定相互顾忌对方而不敢肆意地画（synchronization），从而影响画图效率。但是如果老师事先在大图纸上划分好每个人的区域，小朋友们就可以又快又准地在各自地领域上画图。这样的概念就是arena。

Thread cache

如果是开辟小块内存，为使不参照arena而直接malloc，给各自的线程thread cache领域。此idea是google的tcmalloc的核心部分，亦在jemalloc中体现。

再拿上面的例子，这次给小朋友们除了一张大图纸外，再各自给A4纸一张。这样，小朋友们在不画大面积的点时，只在自己的A4纸上心情地画即可（no arena seeking）。可以在自己手上的纸上画或涂（using thread cache），完全不用顾忌别人（no synchronization, no locking），迅速有效地画。

下图是jemalloc的核心layout。看着复杂，其实都是上面说明的部分。

 

实际jemalloc的性能呢？

 

最左边的就是glibc的malloc，最右边的就是jemalloc。从图表上可以看出，jemalloc的性能有glibc的两倍以上。非常压倒性的性能差异。因此，使用了jemalloc的应用程序自然会快很多。Jemalloc旁边的就是tcmalloc。Tcmalloc的性能与其相差甚微，低jemalloc2.1.0慢4.5%。图上和tcmalloc的1.4版本，而如今它已经到了1.6版本，因此实际上这两者应该是不相仲伯的。Jemalloc的创始人jason evans也意识到这一点，说在cpu core 8以上的计算机上jemalloc效率更高。

给程序员的最后的免费午餐 – kth分布式技术lab的实例      

2005年发表了一篇文章“免费午餐的时代结束了”。在之前，程序就算不用费脑子，随着cpu时钟速度增加，程序性能自己就会上去。但现在不同，现在cpu时钟趋于稳定，而核数不断地增加。程序员需要适应这样的多线程多进程的环境，并要开发出适合的程序。文章讲的大概是这样的内容。

6年之后的如今，这篇文章完全变成现实了。事实上cpu时钟停留在3GHz，而核不断上升。现在程序要适应多线程多进程的分布式计算，速度才能上升。但是这样的程序很难。

现在在多线程的环境下，给程序员们的最后一道午餐便是tcmalloc，jemalloc这样的malloc library。对于使用多线程的程序而言，性能会提高数十%。

共享一下我本人的经验。我本人在kth技术研究所分布式技术lab中承担iLock（分布式同步工具，请参考google的chubby）。在iLock中用了google的tcmalloc的结果，性能提升了18~22%。

最大的优点就是你不需要做任何复杂的工作便可得到这样的效果。不需要代码重编译。只需在执行二进制之前，在cmd窗口中输入

$ LD_PRELOAD=”tcmalloc所设置的文件夹/libtcmalloc.so”

这样在之后执行的应用程序会使用tcmalloc或jemalloc，从而代替glibc标准malloc（ptmalloc）。这需设置此处，我们便可得到性能20%的提升，这真可谓是送给我们的最后的免费午餐。

如今，在分布式技术lab中使用google的tcmalloc。原因在于性能上两者差不多，但google的tcmalloc所提供的程序分析工具非常（heap profiler, cpu profiler）丰富。所以tcmalloc可能更方便一些。

一定要使用最新的malloc么？一定要的！

Q:如何配置varnish缓存到硬盘？

A:http://softbeta.iteye.com/blog/1681716

Q:如果debug VCL?

A:http://stackoverflow.com/questions/12576248/how-to-debug-vcl-in-varnish

Q:怎样不重启varnish让新的vcl生效？

A:用varnishadm进入管理员页面：

Shell代码  

1. vcl.load <configname> <filename> //加载一个新的vcl配置，configname：给配置起个名字，filename：配置的路径  
2. vcl.use <configname> //使用新的配置  
3. vcl.discard <configname> // 删除某个配置  
4. vcl.list //查看所有加载的配置  

Q:VCL怎么urlrewrite?

A:https://www.varnish-cache.org/trac/wiki/RedirectsAndRewrites

PS:regsub函数支持后向引用(backreferences)。

eg:

Vcl代码  

1. set req.url = regsub(req.url,"/attachment/(.+)(&token=.+)$","/cache/attachment/\1");  

Q:503 service unavailable?  

A:503错误，这是因为varnish对后端服务器响应header有限制，默认长度是2048，可将其调大一些

启动参数代码  

1. -p http_resp_hdr_len=8192  

VCL官方文档：https://www.varnish-cache.org/docs/3.0/reference/vcl.html

使用top观察是否存在CPU使用率过高现象

对CPU使用率过高的进程的所有线程进行排序

使用gdb attach nmsagent所在的进程,在gdb中使用 info threads显示所有线程

得到如下结果,可以发现2909线程的编号是12

使用thread 切换线程,使用bt显示线程栈

得到如下线程栈