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顯示線程棧

得到如下線程棧