libunwind库源码（libunwind安装）
本文目录一览：
- 1、net core 安装到哪儿了
- 2、如何使用clang+llvm+binutils+newlib+gdb搭建交叉编译环境
- 3、如何判断 ngnix 走了 静态文件路径
- 4、您好，我的论坛linux nginx服务器 速度有些慢，请问有优化方法吗
- 5、求教，在安装google-perftools，make时报错，已装libunwind
net core 安装到哪儿了
先要安装libunwind，
libunwind库为基于64位CPU和操作系统的程序提供了基本的堆栈辗转开解功能，32位操作系统不要安装。其中包括用于输出堆栈跟踪的API、用于以编程方式辗转开解堆栈的API以及支持C++异常处理机制的API。
The primary goal of this project is to define a portable and efficient C programming interface (API) to determine the call-chain of a program.
yum install libunwind
curl -sSL | bash /dev/stdin --version 1.0.0-preview1-002702 --install-dir ~/dotnet
sudo ln -s ~/dotnet/dotnet /usr/local/bin
mkdir hwapp
cd hwapp
dotnet new
dotnet restore
dotnet run
输出Hello world!
如何使用clang+llvm+binutils+newlib+gdb搭建交叉编译环境
1，Build llvm/clang/lldb/lld 3.5.0等组件
1.0 准备：
至少需要从llvm.org下载llvm, cfe, lldb, compiler-rt,lld等3.5.0版本的代码。
$tar xf llvm-3.5.0.src.tar.gz
$cd llvm-3.5.0.src
$mkdir -p tools/clang
$mkdir -p tools/clang/tools/extra
$mkdir -p tools/lld
$mkdir -p projects/compiler-rt
$tar xf cfe-3.5.0.src.tar.xz -C tools/clang --strip-components=1
$tar xf compiler-rt-3.5.0.src.tar.xz -C projects/compiler-rt --strip-components=1
$tar xf lldb-3.5.0.src.tar.xz -C tools/clang/tools/extra --strip-components=1
$tar xf lld-3.5.0.src.tar.xz -C tools/lld --strip-components=1
1.1 【可选】使用clang --stdlib=libc++时，自动添加-lc++abi。
libc++组件可以使用gcc libstdc++的supc++ ABI，也可以使用c++abi，cxxrt等，实际上自动添加-lc++abi是不必要的，这里这么处理，主要是为了方便起见。实际上完全可以在“clang++ -stdlib=libc++”时再手工添加-lc++abi给链接器。
这里涉及到链接时DSO隐式还是显式的问题，早些时候ld在链接库时会自动引入由库引入的依赖动态库，后来因为这个行为的不可控性，所以ld链接器的行为做了修改，需要显式的写明所有需要链接的动态库，才会有手工添加-lc++abi这种情况出现。
--- llvm-3.0.src/tools/clang/lib/Driver/ToolChain.cpp 2012-03-26 18:49:06.663029075 +0800
+++ llvm-3.0.srcn/tools/clang/lib/Driver/ToolChain.cpp 2012-03-26 19:36:04.260071355 +0800
@@ -251,6 +251,7 @@
switch (Type) {
case ToolChain::CST_Libcxx:
CmdArgs.push_back("-lc++");
+ CmdArgs.push_back("-lc++abi");
break;
case ToolChain::CST_Libstdcxx:
1.2 【必要】给clang++添加-fnolibgcc开关。
这个开关主要用来控制是否连接到libgcc或者libunwind。
注：libgcc不等于libunwind。libgcc_eh以及supc++的一部分跟libunwind功能相当。
注：libgcc_s和compiler_rt的一部分相当。
这个补丁是必要的， 不会对clang的正常使用造成任何影响 ，只有在使用“-fnolibgcc"参数时才会起作用。
之所以进行了很多unwind的引入，主要是为了避免不必要的符号缺失麻烦，这里的处理相对来说是干净的，通过as-needed规避了不必要的引入。
--- llvm-static-3.5.0.bak/tools/clang/lib/Driver/Tools.cpp 2014-09-10 13:46:02.581543888 +0800
+++ llvm-static-3.5.0/tools/clang/lib/Driver/Tools.cpp 2014-09-10 16:03:37.559019321 +0800
@@ -2060,9 +2060,15 @@
".a");
CmdArgs.push_back(Args.MakeArgString(LibClangRT));
- CmdArgs.push_back("-lgcc_s");
- if (TC.getDriver().CCCIsCXX())
- CmdArgs.push_back("-lgcc_eh");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else {
+ CmdArgs.push_back("-lgcc_s");
+ if (TC.getDriver().CCCIsCXX())
+ CmdArgs.push_back("-lgcc_eh");
+ }
}
static void addProfileRT(
@@ -7150,24 +7156,50 @@
bool isAndroid = Triple.getEnvironment() == llvm::Triple::Android;
bool StaticLibgcc = Args.hasArg(options::OPT_static_libgcc) ||
Args.hasArg(options::OPT_static);
+
+
+
if (!D.CCCIsCXX())
- CmdArgs.push_back("-lgcc");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else
+ CmdArgs.push_back("-lgcc");
if (StaticLibgcc || isAndroid) {
if (D.CCCIsCXX())
- CmdArgs.push_back("-lgcc");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else
+ CmdArgs.push_back("-lgcc");
} else {
if (!D.CCCIsCXX())
CmdArgs.push_back("--as-needed");
- CmdArgs.push_back("-lgcc_s");
+ if (Args.hasArg(options::OPT_fnolibgcc))
+ CmdArgs.push_back("-lunwind");
+ else
+ CmdArgs.push_back("-lgcc_s");
if (!D.CCCIsCXX())
CmdArgs.push_back("--no-as-needed");
}
if (StaticLibgcc !isAndroid)
- CmdArgs.push_back("-lgcc_eh");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else
+ CmdArgs.push_back("-lgcc_eh");
else if (!Args.hasArg(options::OPT_shared) D.CCCIsCXX())
- CmdArgs.push_back("-lgcc");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else
+ CmdArgs.push_back("-lgcc");
// According to Android ABI, we have to link with libdl if we are
// linking with non-static libgcc.
--- llvm-static-3.5.0.bak/tools/clang/include/clang/Driver/Options.td 2014-08-07 12:51:51.000000000 +0800
+++ llvm-static-3.5.0/tools/clang/include/clang/Driver/Options.td 2014-09-10 13:36:34.598511176 +0800
@@ -788,6 +788,7 @@
def fomit_frame_pointer : Flag["-"], "fomit-frame-pointer", Groupf_Group;
def fopenmp : Flag["-"], "fopenmp", Groupf_Group, Flags[CC1Option, NoArgumentUnused];
def fopenmp_EQ : Joined["-"], "fopenmp=", Groupf_Group, Flags[CC1Option];
+def fnolibgcc : Flag["-"], "fnolibgcc", Groupf_Group, Flags[CC1Option, NoArgumentUnused];
def fno_optimize_sibling_calls : Flag["-"], "fno-optimize-sibling-calls", Groupf_Group;
def foptimize_sibling_calls : Flag["-"], "foptimize-sibling-calls", Groupf_Group;
def force__cpusubtype__ALL : Flag["-"], "force_cpusubtype_ALL";
1.3 llvm的其他补丁。
llvm/clang将gcc toolchain的路径hard code在代码中，请查阅tools/clang/lib/Driver/ToolChains.cpp。
找到x86_64-redhat-linux之类的字符串。
如果没有你系统特有的gcc tripple string，请自行添加。
这个tripple string主要是给llvm/clang搜索gcc头文件等使用的，不影响本文要构建的toolchain
1.4 构建clang/llvm/lldb
本文使用ninja。顺便说一下，llvm支持configure和cmake两种构建方式。可能是因为工程太大，这两种构建方式的工程文件都有各种缺陷（主要表现在开关选项上，比如configure有，但是cmake却没有等）。llvm-3.4.1就是因为cmake工程文件的错误而导致了3.4.2版本的发布。
综合而言，cmake+ninja的方式是目前最快的构建方式之一，可以将构建时间缩短一半以上。
mkdir build
cd build
cmake \
-G Ninja \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_BUILD_TYPE="Release" \
-DCMAKE_CXX_FLAGS="-std=c++11" \
-DBUILD_SHARED_LIBS=OFF \
-DLLVM_ENABLE_PIC=ON \
-DLLVM_TARGETS_TO_BUILD="all" \
-DCLANG_VENDOR="MyOS" ..
ninja
ninja install
如果系统原来就有clang/clang++的可用版本，可以添加：
-DCMAKE_C_COMPILER=clang \
-DCMAKE_CXX_COMPILER=clang++ \
这样就会使用系统的clang++来构建llvm/clang
2，测试clang/clang++。
自己找几个简单的c/cpp/objc等编译测试一下即可。完整测试可以在构建时作ninja check-all
3，libunwind/libc++/libc++abi，一套不依赖libgcc, libstdc++的c++运行库。
3.1 从 获取代码。
libunwind有很多个实现，比如gnu的libunwind, path64的libunwind，还有libcxxabi自带的Unwinder.
这里作下说明：
1)，gnu的libunwind会有符号缺失和冲突。
2)，libcxxabi自带的Unwinder是给mac和ios用的，也就是只能在darwin体系构建。目前Linux的实现仍然不全，等linux实现完整了或许就不再需要path64的unwind实现了。
暂时建议使用pathscale的unwind实现。
mkdir -p build
cd build
cmake -G Ninja -DCMAKE_C_COMPILER=clang -DCMAKE_C_FLAGS="-m64" ..
ninja
mkdir -p /usr/lib
cp src/libunwind.so /usr/lib
cp src/libunwind.a /usr/lib
3.2 第一次构建libcxx.
必须先构建一次libcxx，以便后面构建libcxxabi。这里构建的libcxx实际上是使用gcc的libgcc/stdc++/supc++的。
打上这个补丁来禁止libgcc的引入：
diff -Nur libcxx/cmake/config-ix.cmake libcxxn/cmake/config-ix.cmake
--- libcxx/cmake/config-ix.cmake 2014-06-25 06:57:50.000000000 +0800
+++ libcxxn/cmake/config-ix.cmake 2014-06-25 09:05:24.980350544 +0800
@@ -28,5 +28,4 @@
check_library_exists(c printf "" LIBCXX_HAS_C_LIB)
check_library_exists(m ccos "" LIBCXX_HAS_M_LIB)
check_library_exists(rt clock_gettime "" LIBCXX_HAS_RT_LIB)
-check_library_exists(gcc_s __gcc_personality_v0 "" LIBCXX_HAS_GCC_S_LIB)
编译安装：
mkdir build
cd build
cmake \
-G Ninja \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_C_COMPILER=clang \
-DCMAKE_CXX_COMPILER=clang++ \
..
ninja
ninja install
3.3，测试第一次构建的libcxx。
使用"clang++ -stdlib=libc++ -o test test.cpp -lstdc++"编译简单c++代码，检查是否出错。(如果前面构建clang是已经apply了c++abi的链接补丁，这里会出现找不到c++abi的情况，跳过即可)
使用"ldd test"查看test二进制动态库使用情况。可以发现，test依赖于libgcc_s/libc++/libstdc++。（多少有些不爽了吧？使用了libc++居然还要依赖libstdc++？）
如何判断 ngnix 走了 静态文件路径
Nginx以其消耗资源少，承受并发量大，配置文件简洁等特点，深受广大sa们的喜欢，但是网上传播的nginx 配置并没有对做过多的优化。那么接下来，我就从某大型媒体网站的实际运维nginx优化角度，来给大家讲解一下nginx主要优化的那些方面。
nginx的启动命令是：/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.confbr-c制定配置文件的路径，不加-nginx会自动加载默认路径的配置文件。br
停止操作
停止操作是通过向nginx进程发送信号（什么是信号请参阅linux文 章）来进行的
步骤1：查询nginx主进程号
ps -ef | grep nginx
在进程列表里 面找master进程，它的编号就是主进程号了。
步骤2：发送信号
从容停止Nginx：
kill -QUIT 主进程号
快速停止Nginx：
kill -TERM 主进程号
强制停止Nginx：
pkill -9 nginx
另外， 若在nginx.conf配置了pid文件存放路径则该文件存放的就是Nginx主进程号，如果没指定则放在nginx的logs目录下。有了pid文 件，我们就不用先查询Nginx的主进程号，而直接向Nginx发送信号了，命令如下：
kill -信号类型 '/usr/nginx/logs/nginx.pid'
平滑重启
如果更改了配置就要重启Nginx，要先关闭Nginx再打开？不是的，可以向Nginx 发送信号，平滑重启。
平滑重启命令：
kill -HUP 住进称号或进程号文件路径
或者使用
/usr/nginx/sbin/nginx -s reload
注意，修改了配置文件后最好先检查一下修改过的配置文件是否正 确，以免重启后Nginx出现错误影响服务器稳定运行。判断Nginx配置是否正确命令如下：
nginx -t -c /usr/nginx/conf/nginx.conf
或者
/usr/nginx/sbin/nginx -t
平滑升级
如果服务器正在运行的Nginx要进行升级、添加或删除模块时，我们需 要停掉服务器并做相应修改，这样服务器就要在一段时间内停止服务，Nginx可以在不停机的情况下进行各种升级动作而不影响服务器运行。
步骤1：
如 果升级Nginx程序，先用新程序替换旧程序文件，编译安装的话新程序直接编译到Nginx安装目录中。
步 骤2：执行命令
kill -USR2 旧版程序的主进程号或进程文件名
此时旧的Nginx主进程将会把自己的进程文件改名为.oldbin，然后执行新版 Nginx。新旧Nginx会同市运行，共同处理请求。
这时要逐步停止旧版 Nginx，输入命令：
kill -WINCH 旧版主进程号
慢慢旧的工作进程就都会随着任务执行完毕而退出，新版的Nginx的工作进程会逐渐取代旧版 工作进程。
此 时，我们可以决定使用新版还是恢复到旧版。
不重载配置启动新/旧工作进程
kill -HUP 旧/新版主进程号
从容关闭旧/新进程
kill -QUIT 旧/新主进程号
如果此时报错，提示还有进程没有结束就用下面命令先关闭旧/新工作进程，再关闭主进程号：
kill -TERM 旧/新工作进程号
这样下来，如果要恢复到旧版本，只需要上面的几个步 骤都是操作新版主进程号，如果要用新版本就上面的几个步骤都操作旧版主进程号就行了。
上面就是Nginx的一些基本的操作，希望以后Nginx能有更好的方法来处理这些操作， 最好是Nginx的命令而不是向Nginx进程发送系统信号。
一、编译方面优化
1、首先就要从configure 参数分析，根据网上最常用的configure 参数来说，大都是：
# ./configure \
--prefix=/usr/local/nginx \
--user=www \
--group=www \
--with-http_stub_status_module \
--with-http_ssl_module
应该说这个参数是通用的，适用于各种环境的需要，比如php环境、纯静态文件环境、代理环境等等。编译nginx程序文件大约有2M大小，跟全面优化的500多K，相差了不少。
下面我们修改一下参数，减少不必要的功能。
纯静态文件环境参数
# ./configure \
--prefix=/usr/local/nginx \
--user=www \
--group=www \
--with-http_stub_status_module \
--without-http_fastcgi_module \
--without-http_proxy_module \
--without-http_upstream_ip_hash_module \
--without-http_autoindex_module \
--without-http_ssi_module \
--without-http_proxy_module \
--without-mail_pop3_module \
--without-mail_imap_module \
--without-mail_smtp_module \
--without-http_uwsgi_module \
--without-http_scgi_module \
--without-http_memcached_module
去掉了在mail模块fastcgi模块 代理模块 ip_hash模块等，在纯静态文件用不到的模块，现在看看nginx程序文件是不是少了一些。Php环境的话，只需要去掉 --with-http_fastcgi_module 重新编译即可。代理环境的话，只需要去掉--with_proxy_module重新编译即可。
2、去掉nginx 默认的debug跟踪设置。这一步需要修改nginx 源码。
# cd nginx-1.0.x
# vim auto/cc/gcc
第175行：前面加#注释掉改行。
#CFLAGS="$CFLAGS -g"
这样的话，编译的参数，就会减少到500多K的标准，这样在大并发量的条件下，性能提升明显。
二、利用google-perftools来优化高并发条件下的nginx
在32位系统下，可以直接安装google-peftools，64位条件下，需要先安装libunwind库。然后再nginx configure 参数增加--with-google_perftools_module 重新编译安装nginx。
这里以64位环境为准
1. 安装libunwind库
# wget
# tar zxvf libunwind-0.99.tar.gz
# cd libunwind-0.99/
# CFLAGS=-fPIC ./configure –prefix=/usr
# make CFLAGS=-fPIC
# make CFLAGS=-fPIC install
2. 安装google-perftools
# wget
# tar xzvf google-perftools-1.7.tar.gz
# cd google-perftools-1.7
然后开始配置：
# ./configure --prefix=/usr --enable-frame-pointers (32位可以不添加--enable-frame-pointers)
# make --j4 make installnginx
configure 参数加上--with-google-perftools 重新编译nginx
# ./configure \
--prefix=/usr/local/nginx \
--user=www \
--group=www \
--with-http_stub_status_module \
--without-http_fastcgi_module \
--without-http_proxy_module \
--without-http_upstream_ip_hash_module \
--without-http_autoindex_module \
--without-http_ssi_module \
--without-http_proxy_module \
--without-mail_pop3_module \
--without-mail_imap_module \
--without-mail_smtp_module \
--without-http_uwsgi_module \
--without-http_scgi_module \
--without-http_memcached_module \
--with-google_perftools_module
# make make install
3、在nginx.conf 的pid部分下，增加
google_perftools_profiles /data0/google_cache;
# service nginx restart 重启即可生效。
4. 安装
yum -y install gcc gcc-c++ autoconf automake
yum -y install zlib zlib-devel openssl openssl--devel pcre pcre-devel
wget
rpm -ivh nginx-release-centos-6-0.el6.ngx.noarch.rpm
yum install nginx
三、nginx 工作进程优化
nginx指令中的优化（配置文件）
worker_processes 8;
nginx进程数，建议按照cpu数目来指定，一般为它的倍数。
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
为每个进程分配cpu，上例中将8个进程分配到8个cpu，当然可以写多个，或者将一个进程分配到多个cpu。
worker_rlimit_nofile 102400;
这个指令是指当一个nginx进程打开的最多文件描述符数目，理论值应该是最多打开文件数（ulimit -n）与nginx进程数相除，但是nginx分配请求并不是那么均匀，所以最好与ulimit -n的值保持一致。
use epoll;
使用epoll的I/O模型，这个不用说了吧。
worker_connections 102400;
每个进程允许的最多连接数，理论上每台nginx服务器的最大连接数为worker_processes*worker_connections。
keepalive_timeout 60;
keepalive超时时间。
client_header_buffer_size 4k;
客户端请求头部的缓冲区大小，这个可以根据你的系统分页大小来设置，一般一个请求的头部大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。分页大小可以用命令getconf PAGESIZE取得。
open_file_cache max=102400 inactive=20s;
这个将为打开文件指定缓存，默认是没有启用的，max指定缓存数量，建议和打开文件数一致，inactive是指经过多长时间文件没被请求后删除缓存。
open_file_cache_valid 30s;
这个是指多长时间检查一次缓存的有效信息。
open_file_cache_min_uses 1;
open_file_cache指令中的inactive参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive时间内一次没被使用，它将被移除。
内核参数的优化
net.ipv4.tcp_max_tw_buckets = 6000
timewait的数量，默认是180000。
net.ipv4.ip_local_port_range = 1024 65000
允许系统打开的端口范围。
net.ipv4.tcp_tw_recycle = 1
启用timewait快速回收。
net.ipv4.tcp_tw_reuse = 1
开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接。
net.ipv4.tcp_syncookies = 1
开启SYN Cookies，当出现SYN等待队列溢出时，启用cookies来处理。
net.core.somaxconn = 262144
web应用中listen函数的backlog默认会给我们内核参数的net.core.somaxconn限制到128，而nginx定义的NGX_LISTEN_BACKLOG默认为511，所以有必要调整这个值。
net.core.netdev_max_backlog = 262144
每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。
net.ipv4.tcp_max_orphans = 262144
系统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上。如果超过这个数字，孤儿连接将即刻被复位并打印出警告信息。这个限制仅仅是为了防止简单的DoS攻击，不能过分依靠它或者人为地减小这个值，更应该增加这个值(如果增加了内存之后)。
net.ipv4.tcp_max_syn_backlog = 262144
记录的那些尚未收到客户端确认信息的连接请求的最大值。对于有128M内存的系统而言，缺省值是1024，小内存的系统则是128。
net.ipv4.tcp_timestamps = 0
时间戳可以避免序列号的卷绕。一个1Gbps的链路肯定会遇到以前用过的序列号。时间戳能够让内核接受这种“异常”的数据包。这里需要将其关掉。
net.ipv4.tcp_synack_retries = 1
为了打开对端的连接，内核需要发送一个SYN并附带一个回应前面一个SYN的ACK。也就是所谓三次握手中的第二次握手。这个设置决定了内核放弃连接之前发送SYN+ACK包的数量。
net.ipv4.tcp_syn_retries = 1
在内核放弃建立连接之前发送SYN包的数量。
net.ipv4.tcp_fin_timeout = 1
如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间。对端可以出错并永远不关闭连接，甚至意外当机。缺省值是60秒。2.2 内核的通常值是180秒，你可以按这个设置，但要记住的是，即使你的机器是一个轻载的WEB服务器，也有因为大量的死套接字而内存溢出的风险，FIN- WAIT-2的危险性比FIN-WAIT-1要小，因为它最多只能吃掉1.5K内存，但是它们的生存期长些。
net.ipv4.tcp_keepalive_time = 30
当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时。
一个完整的内核优化配置
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.tcp_max_tw_buckets = 6000
net.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_wmem = 4096 16384 4194304
net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 262144
net.core.somaxconn = 262144
net.ipv4.tcp_max_orphans = 3276800
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_mem = 94500000 915000000 927000000
net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_keepalive_time = 30
net.ipv4.ip_local_port_range = 1024 65000
一个简单的nginx优化配置文件
您好，我的论坛linux nginx服务器 速度有些慢，请问有优化方法吗
一、编译安装过程优化
1.减小Nginx编译后的文件大小
在编译Nginx时，默认以debug模式进行，而在debug模式下会插入很多跟踪和ASSERT之类的信息，编译完成后，一个Nginx要有好几兆字
节。在编译前取消Nginx的debug模式，编译完成后Nginx只有几百千字节，因此可以在编译之前，修改相关源码，取消debug模式，具体方法如
下：
在Nginx源码文件被解压后，找到源码目录下的auto/cc/gcc文件，在其中找到如下几行：
# debug CFLAGS=”$CFLAGS -g”
注释掉或删掉这两行，即可取消debug模式。
2.为特定的CPU指定CPU类型编译优化
在编译Nginx时，默认的GCC编译参数是“-O”，要优化GCC编译，可以使用以下两个参数：
--with-cc-opt='-O3'
--with-cpu-opt=CPU #为特定的 CPU 编译，有效的值包括：pentium, pentiumpro, pentium3, pentium4, athlon, opteron, amd64, sparc32, sparc64, ppc64
要确定CPU类型，可以通过如下命令:
[root@localhost home]#cat /proc/cpuinfo | grep "model name"
二、利用TCMalloc优化Nginx的性能
TCMalloc的全称为Thread-Caching
Malloc，是谷歌开发的开源工具“google-perftools”中的一个成员。与标准的glibc库的malloc相比，TCMalloc库在
内存分配效率和速度上要高很多，这在很大程度上提高了服务器在高并发情况下的性能，从而降低系统负载。下面简单介绍如何为Nginx添加TCMalloc
库支持。
要安装TCMalloc库，需要安装libunwind（32位操作系统不需要安装）和google-perftools两个软件包，libunwind
库为基于64位CPU和操作系统的程序提供了基本函数调用链和函数调用寄存器功能。下面介绍利用TCMalloc优化Nginx的具体操作过程：
1.安装libunwind库
可以从下载相应的libunwind版本，这里下载的是libunwind-0.99-alpha.tar.gz，安装过程如下：
[root@localhost home]#tar zxvf libunwind-0.99-alpha.tar.gz [root@localhost home]# cd libunwind-0.99-alpha/ [root@localhost libunwind-0.99-alpha]#CFLAGS=-fPIC ./configure [root@localhost libunwind-0.99-alpha]#make CFLAGS=-fPIC [root@localhost libunwind-0.99-alpha]#make CFLAGS=-fPIC install
2.安装google-perftools
可以从下载相应的google-perftools版本，这里下载的是google-perftools-1.8.tar.gz，安装过程如下：
[root@localhost home]#tar zxvf google-perftools-1.8.tar.gz [root@localhost home]#cd google-perftools-1.8/ [root@localhost google-perftools-1.8]# ./configure [root@localhost google-perftools-1.8]#make make install [root@localhost google-perftools-1.8]#echo "/usr/local/lib" /etc/ld.so.conf.d/usr_local_lib.conf [root@localhost google-perftools-1.8]# ldconfig
至此，google-perftools安装完成。
3.重新编译Nginx
为了使Nginx支持google-perftools，需要在安装过程中添加“–with-google_perftools_module”选项重新编译Nginx，安装代码如下：
[root@localhostnginx-0.7.65]#./configure \ --with-google_perftools_module --with-http_stub_status_module --prefix=/opt/nginx [root@localhost nginx-0.7.65]#make [root@localhost nginx-0.7.65]#make install
到这里Nginx安装完成。
4.为google-perftools添加线程目录
创建一个线程目录，这里将文件放在/tmp/tcmalloc下，操作如下：
[root@localhost home]#mkdir /tmp/tcmalloc [root@localhost home]#chmod 0777 /tmp/tcmalloc
5.修改Nginx主配置文件
修改nginx.conf文件，在pid这行的下面添加如下代码：
#pid logs/nginx.pid; google_perftools_profiles /tmp/tcmalloc;
接着，重启Nginx，完成google-perftools的加载。
6.验证运行状态
为了验证google-perftools已经正常加载，通过如下命令查看：
[root@ localhost home]# lsof -n | grep tcmalloc nginx 2395 nobody 9w REG 8,8 0 1599440 /tmp/tcmalloc.2395 nginx 2396 nobody 11w REG 8,8 0 1599443 /tmp/tcmalloc.2396 nginx 2397 nobody 13w REG 8,8 0 1599441 /tmp/tcmalloc.2397 nginx 2398 nobody 15w REG 8,8 0 1599442 /tmp/tcmalloc.2398
由于在Nginx配置文件中，设置worker_processes的值为4，因此开启了4个Nginx线程，每个线程会有一行记录。每个线程文件后面的数字值就是启动的Nginx的PID值。
至此，利用TCMalloc优化Nginx的操作完成。
三、Nginx内核参数优化
内核参数的优化，主要是在Linux系统中针对Nginx应用而进行的系统内核参数优化，常见的优化参数值如下。
下面给出一个优化实例以供参考：
net.ipv4.tcp_max_tw_buckets = 6000 net.ipv4.ip_local_port_range = 1024 65000 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_syncookies = 1 net.core.somaxconn = 262144 net.core.netdev_max_backlog = 262144 net.ipv4.tcp_max_orphans = 262144 net.ipv4.tcp_max_syn_backlog = 262144 net.ipv4.tcp_synack_retries = 1 net.ipv4.tcp_syn_retries = 1 net.ipv4.tcp_fin_timeout = 1 net.ipv4.tcp_keepalive_time = 30
将上面的内核参数值加入/etc/sysctl.conf文件中，然后执行如下命令使之生效：
[root@ localhost home]#/sbin/sysctl -p
下面是对实例中选项的含义进行介绍：
net.ipv4.tcp_max_tw_buckets参数用来设定timewait的数量，默认是180000，这里设为6000。
net.ipv4.ip_local_port_range选项用来设定允许系统打开的端口范围。
net.ipv4.tcp_tw_recycle选项用于设置启用timewait快速回收。
net.ipv4.tcp_tw_reuse选项用于设置开启重用，允许将TIME-WAIT sockets重新用于新的TCP连接。
net.ipv4.tcp_syncookies选项用于设置开启SYN Cookies，当出现SYN等待队列溢出时，启用cookies进行处理。
net.core.somaxconn选项默认值是128， 这个参数用于调节系统同时发起的tcp连接数，在高并发的请求中，默认的值可能会导致链接超时或者重传，因此，需要结合并发请求数来调节此值。
net.core.netdev_max_backlog选项表示当每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许发送到队列的数据包的最大数目。
net.ipv4.tcp_max_orphans选项用于设定系统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上。如果超过这个数
字，孤立连接将立即被复位并打印出警告信息。这个限制只是为了防止简单的DoS攻击。不能过分依靠这个限制甚至人为减小这个值，更多的情况是增加这个值。
net.ipv4.tcp_max_syn_backlog选项用于记录那些尚未收到客户端确认信息的连接请求的最大值。对于有128MB内存的系统而言，此参数的默认值是1024，对小内存的系统则是128。
net.ipv4.tcp_synack_retries参数的值决定了内核放弃连接之前发送SYN+ACK包的数量。
net.ipv4.tcp_syn_retries选项表示在内核放弃建立连接之前发送SYN包的数量。
net.ipv4.tcp_fin_timeout选项决定了套接字保持在FIN-WAIT-2状态的时间。默认值是60秒。正确设置这个值非常重要，有时候即使一个负载很小的Web服务器，也会出现因为大量的死套接字而产生内存溢出的风险。
net.ipv4.tcp_keepalive_time选项表示当keepalive启用的时候，TCP发送keepalive消息的频度。默认值是2（单位是小时）。
求教，在安装google-perftools，make时报错，已装libunwind
删除了系统原带的sqlite3 ，到官网上下一个源码，重新编译安装sqlite3。 如： 把sqlite3安装到 /usr/local/sqlite3 tar zxf sqlite3.xxxx.tar.gz cd sqlite.3.xxxx ./configura --prefix=/usr/local/sqlite3 make make install cd .. 最后在编译Gearman时带上 --with-sqlite3=/usr/local/sqlite3，告诉编译器应该使用这个新的sqlite即可。
