Lua-5.2.2

lua-5.2.2發(fā)布已有一段時(shí)間了，最近在redhat Linux平臺(tái)編譯時(shí)報(bào)錯(cuò)。這里給出解決方案，或許對(duì)某人會(huì)有幫助。

編譯報(bào)錯(cuò)，如下：

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庫(kù)，而其依賴ncurses庫(kù)，但沒有指定，所以出現(xiàn)“未定義的符合引用”錯(cuò)誤。需要修改${LUA_DIR}/src/Makefile中l(wèi)inux編譯target，在SYSLIBS變量中追加‘-lncurses’選項(xiàng)即可。修改后，如下：

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的創(chuàng)始人Jason Evans也是在FreeBSD很有名的開發(fā)人員。此人就在2006年為提高低性能的malloc而寫的jemalloc。Jemalloc是從2007年開始以FreeBSD標(biāo)準(zhǔn)引進(jìn)來的。軟件技術(shù)革新很多是FreeBSD發(fā)起的。在FreeBSD應(yīng)用廣泛的技術(shù)會(huì)慢慢導(dǎo)入到linux。

目前jemalloc在firefox中也在使用。在firefox2中出現(xiàn)了內(nèi)存碎片問題之后，便在firefox3中使用了jemalloc。在safari和chrome中使用的是google的tcmalloc。

Jemalloc的技術(shù)特性

Jemalloc聚集了malloc的使用過程中所驗(yàn)證的很多技術(shù)。忽略細(xì)節(jié)，從架構(gòu)著眼，最出色的部分仍是arena和thread cache。（事實(shí)上，這兩個(gè)與tcmalloc的架構(gòu)幾乎相同。Jemalloc only的部分將會(huì)在另一次posting中繼續(xù)探討。）

Arena

與其像malloc一樣集中管理一整塊內(nèi)存，不如將其分成許多個(gè)小塊來分而治之。此小塊便稱為arena。讓我們想象一下，給幾個(gè)小朋友一張大圖紙，讓他們隨意地畫點(diǎn)。結(jié)果可想而知，他們肯定相互顧忌對(duì)方而不敢肆意地畫（synchronization），從而影響畫圖效率。但是如果老師事先在大圖紙上劃分好每個(gè)人的區(qū)域，小朋友們就可以又快又準(zhǔn)地在各自地領(lǐng)域上畫圖。這樣的概念就是arena。

Thread cache

如果是開辟小塊內(nèi)存，為使不參照arena而直接malloc，給各自的線程thread cache領(lǐng)域。此idea是google的tcmalloc的核心部分，亦在jemalloc中體現(xiàn)。

再拿上面的例子，這次給小朋友們除了一張大圖紙外，再各自給A4紙一張。這樣，小朋友們在不畫大面積的點(diǎn)時(shí)，只在自己的A4紙上心情地畫即可（no arena seeking）。可以在自己手上的紙上畫或涂（using thread cache），完全不用顧忌別人（no synchronization, no locking），迅速有效地畫。

下圖是jemalloc的核心layout?？粗?/span>復(fù)雜，其實(shí)都是上面說明的部分。

 

實(shí)際jemalloc的性能呢？

 

最左邊的就是glibc的malloc，最右邊的就是jemalloc。從圖表上可以看出，jemalloc的性能有glibc的兩倍以上。非常壓倒性的性能差異。因此，使用了jemalloc的應(yīng)用程序自然會(huì)快很多。Jemalloc旁邊的就是tcmalloc。Tcmalloc的性能與其相差甚微，低jemalloc2.1.0慢4.5%。圖上和tcmalloc的1.4版本，而如今它已經(jīng)到了1.6版本，因此實(shí)際上這兩者應(yīng)該是不相仲伯的。Jemalloc的創(chuàng)始人jason evans也意識(shí)到這一點(diǎn)，說在cpu core 8以上的計(jì)算機(jī)上jemalloc效率更高。

給程序員的最后的免費(fèi)午餐 – kth分布式技術(shù)lab的實(shí)例      

2005年發(fā)表了一篇文章“免費(fèi)午餐的時(shí)代結(jié)束了”。在之前，程序就算不用費(fèi)腦子，隨著cpu時(shí)鐘速度增加，程序性能自己就會(huì)上去。但現(xiàn)在不同，現(xiàn)在cpu時(shí)鐘趨于穩(wěn)定，而核數(shù)不斷地增加。程序員需要適應(yīng)這樣的多線程多進(jìn)程的環(huán)境，并要開發(fā)出適合的程序。文章講的大概是這樣的內(nèi)容。

6年之后的如今，這篇文章完全變成現(xiàn)實(shí)了。事實(shí)上cpu時(shí)鐘停留在3GHz，而核不斷上升。現(xiàn)在程序要適應(yīng)多線程多進(jìn)程的分布式計(jì)算，速度才能上升。但是這樣的程序很難。

現(xiàn)在在多線程的環(huán)境下，給程序員們的最后一道午餐便是tcmalloc，jemalloc這樣的malloc library。對(duì)于使用多線程的程序而言，性能會(huì)提高數(shù)十%。

共享一下我本人的經(jīng)驗(yàn)。我本人在kth技術(shù)研究所分布式技術(shù)lab中承擔(dān)iLock（分布式同步工具，請(qǐng)參考google的chubby）。在iLock中用了google的tcmalloc的結(jié)果，性能提升了18~22%。

最大的優(yōu)點(diǎn)就是你不需要做任何復(fù)雜的工作便可得到這樣的效果。不需要代碼重編譯。只需在執(zhí)行二進(jìn)制之前，在cmd窗口中輸入

$ LD_PRELOAD=”tcmalloc所設(shè)置的文件夾/libtcmalloc.so”

這樣在之后執(zhí)行的應(yīng)用程序會(huì)使用tcmalloc或jemalloc，從而代替glibc標(biāo)準(zhǔn)malloc（ptmalloc）。這需設(shè)置此處，我們便可得到性能20%的提升，這真可謂是送給我們的最后的免費(fèi)午餐。

如今，在分布式技術(shù)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進(jìn)入管理員頁面：

Shell代碼  

1. vcl.load <configname> <filename> //加載一個(gè)新的vcl配置，configname：給配置起個(gè)名字，filename：配置的路徑  
2. vcl.use <configname> //使用新的配置  
3. vcl.discard <configname> // 刪除某個(gè)配置  
4. vcl.list //查看所有加載的配置  

Q:VCL怎么urlrewrite?

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

PS:regsub函數(shù)支持后向引用(backreferences)。

eg:

Vcl代碼  

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

Q:503 service unavailable?  

A:503錯(cuò)誤，這是因?yàn)関arnish對(duì)后端服務(wù)器響應(yīng)header有限制，默認(rèn)長(zhǎng)度是2048，可將其調(diào)大一些

啟動(dòng)參數(shù)代碼  

1. -p http_resp_hdr_len=8192  

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

使用top觀察是否存在CPU使用率過高現(xiàn)象

對(duì)CPU使用率過高的進(jìn)程的所有線程進(jìn)行排序

使用gdb attach nmsagent所在的進(jìn)程,在gdb中使用 info threads顯示所有線程

得到如下結(jié)果,可以發(fā)現(xiàn)2909線程的編號(hào)是12

使用thread 切換線程,使用bt顯示線程棧

得到如下線程棧