地址：http://www.shangxueba.com/jingyan/2216074.html
最近刚好完成了一个DNS服务器的开发，因此积累一点对高性能UDP服务器的开发经验。如果你也遇到UDP服务器的性能不佳，远不如你的预期，也许你也可以采用本文的手段去优化一下试试。
udp不像tcp是有连接的，因此udp不能通过建立多个连接来提高对服务器的并发访问，然后我就遇到了在多核环境下通过多线程访问一个共享的udp socket时，无论如何我都无法将所有的cpu都利用起来，最后的结局当然就是无法压测出机器的瓶颈，性能也上不去。Google为了解决他们的DNS服务器性能问题，就给linux内核打了一个patch，这个patch就是SO_REUSEPORT，经过我的实战体验，reuseport对udp服务器在多核机器上的性能提升是非常大的，值得使用。
REUSEPORT的目的如其名，就是为了让多线程/多进程服务器的每个线程都listen同一个端口，并且最终每个线程拥有一个独立的socket，而不是所有线程都访问一个socket。没有reuseport这个patch的话，这么做的后果就是服务器会报出一个类似“地址/端口被占用的”错误信息。在没有reuseport的时候，客户端发给udp服务器的每个包都是被投递到唯一的一个socket上了，使用reuseport后，服务器有了多个socket，那么客户端发过来的包投递到哪个socket上呢？linux内核采用了一个四元组<客户端ip，客户端port，服务器ip，服务器port>的hash来进行包的分发，这样做至少有两个目的：一是保证同一个客户度过来的包都被递送到同一个socket上；二是在客户端量足够的时候，基本可以均衡到所有的socket上。在使用reuseport的时候需要注意：客户端太少的话，是很难压测出服务器的真实性能的，因为reuseport使用的是hash值来分发请求到socket上，所以可能出现每个socket上接收包不均衡的情况，使用较多的客户端机器来压测服务器，目的就是让每个socket尽可能的均衡。
使用reuseport后，udp服务器的并发能力大幅度的提高了，这个时候还可以继续使用recvmmsg来继续降低系统调用的开销。recvmmsg是一个批量接口，它可以从socket里一次读出多个udp数据包，不像recvfrom那样一次只能读一个。如果客户端多、请求量大的话，recvmmsg的批量读就很有优势了。不过，使用recvmmsg一定要清楚，它从socket里一次读出的所有包不一定是来自同一个客户端的，大多数情况应该都是来自不同客户端的。这不像tcp，从同一个连接里读到的数据一定是同一个客户端。我们的一个同学在使用recvmmsg的时候，就犯了这个错误，误认为一次收取的数据包都是同一个客户端的，最后将所有的应答都发给了同一个客户端，其他的客户端全都超时了。高性能服务器开发中，系统调用是昂贵的，所以没事就可以用strace看看一个请求周期内有哪些系统调用，尽一切可能去优化掉他们。
开发一个UDP服务器，不是说使用了reuseport和recvmmsg后性能就高了。一个高性能的网络服务器，是需要进行方方面面的优化才行的。
-----------------------------------------------------------
附上strace的用法：
1、直接strace运行命令：strace cat /dev/null 2、跟踪已运行进程：strace -p pid 3、输出结果到文件：strace -o filename -p pid4、在转载一篇文章：http://www.vimer.cn
用strace调试程序
在理想世界里，每当一个程序不能正常执行一个功能时，它就会给出一个有用的错误提示，告诉你在足够的改正错误的线索。但遗憾的是，我们不是生活在理想世界里，起码不总是生活在理想世界里。有时候一个程序出现了问题，你无法找到原因。
这就是调试程序出现的原因。strace是一个必不可少的调试工具，strace用来监视系统调用。你不仅可以调试一个新开始的程序，也可以调试一个已经在运行的程序（把strace绑定到一个已有的PID上面）。
首先让我们看一个真实的例子：
启动KDE时出现问题
前一段时间，我在启动KDE的时候出了问题，KDE的错误信息无法给我任何有帮助的线索。
代码：
_KDE_IceTransSocketCreateListener: failed to bind listener
_KDE_IceTransSocketUNIXCreateListener: …SocketCreateListener() failed
_KDE_IceTransMakeAllCOTSServerListeners: failed to create listener for local
Cannot establish any listening sockets DCOPServer self-test failed.
对我来说这个错误信息没有太多意义，只是一个对KDE来说至关重要的负责进程间通信的程序无法启动。我还可以知道这个错误和ICE协议（Inter Client Exchange）有关，除此之外，我不知道什么是KDE启动出错的原因。
我决定采用strace看一下在启动dcopserver时到底程序做了什么：
代码：
strace -f -F -o ~/dcop-strace.txt dcopserver
这里 -f -F选项告诉strace同时跟踪fork和vfork出来的进程，-o选项把所有strace输出写到~/dcop-strace.txt里面，dcopserver是要启动和调试的程序。
再次出现错误之后，我检查了错误输出文件dcop-strace.txt，文件里有很多系统调用的记录。在程序运行出错前的有关记录如下：
代码：
27207 mkdir(“/tmp/.ICE-unix”, 0777) = -1 EEXIST
(File exists)
27207 lstat64(“/tmp/.ICE-unix”, {st_mode=S_IFDIR|S_ISVTX|0755,
st_size=4096, …}) = 0
27207 unlink(“/tmp/.ICE-unix/dcop27207-1066844596″) = -1 ENOENT
(No such file or directory)
27207 bind(3, {sin_family=AF_UNIX, path=“/tmp/.ICE-unix/dcop27207-1066844596″}, 3 = -1 EACCES
(Permission denied)
27207 write(2, “_KDE_IceTrans”, 13) = 13
27207 write(2, “SocketCreateListener: failed to “…, 46) = 46
27207 close(3) = 0 27207 write(2, “_KDE_IceTrans”, 13) = 13
27207 write(2, “SocketUNIXCreateListener: …Soc”…, 59) = 59
27207 umask(0) = 0 27207 write(2, “_KDE_IceTrans”, 13) = 13
27207 write(2, “MakeAllCOTSServerListeners: fail”…, 64) = 64
27207 write(2, “Cannot establish any listening s”…, 39) = 39
其中第一行显示程序试图创建/tmp/.ICE-unix目录，权限为0777，这个操作因为目录已经存在而失败了。第二个系统调用（lstat64）检查 了目录状态，并显示这个目录的权限是0755，这里出现了第一个程序运行错误的线索：程序试图创建属性为0777的目录，但是已经存在了一个属性为 0755的目录。第三个系统调用（unlink）试图删除一个文件，但是这个文件并不存在。这并不奇怪，因为这个操作只是试图删掉可能存在的老文件。
但是，第四行确认了错误所在。他试图绑定到/tmp/.ICE-unix/dcop27207-1066844596，但是出现了拒绝访问错误。. ICE_unix目录的用户和组都是root，并且只有所有者具有写权限。一个非root用户无法在这个目录下面建立文件，如果把目录属性改成0777， 则前面的操作有可能可以执行，而这正是第一步错误出现时进行过的操作。
所以我运行了chmod 0777 /tmp/.ICE-unix之后KDE就可以正常启动了，问题解决了，用strace进行跟踪调试只需要花很短的几分钟时间跟踪程序运行，然后检查并分析输出文件。
说明：运行chmod 0777只是一个测试，一般不要把一个目录设置成所有用户可读写，同时不设置粘滞位(sticky bit)。给目录设置粘滞位可以阻止一个用户随意删除可写目录下面其他人的文件。一般你会发现/tmp目录因为这个原因设置了粘滞位。KDE可以正常启动 之后，运行chmod +t /tmp/.ICE-unix给.ICE_unix设置粘滞位。
解决库依赖问题
starce 的另一个用处是解决和动态库相关的问题。当对一个可执行文件运行ldd时，它会告诉你程序使用的动态库和找到动态库的位置。但是如果你正在使用一个比较老 的glibc版本（2.2或更早），你可能会有一个有bug的ldd程序，它可能会报告在一个目录下发现一个动态库，但是真正运行程序时动态连接程序 （/lib/ld-linux.so.2）却可能到另外一个目录去找动态连接库。这通常因为/etc/ld.so.conf和 /etc/ld.so.cache文件不一致，或者/etc/ld.so.cache被破坏。在glibc 2.3.2版本上这个错误不会出现，可能ld-linux的这个bug已经被解决了。
尽管这样，ldd并不能把所有程序 依赖的动态库列出来，系统调用dlopen可以在需要的时候自动调入需要的动态库，而这些库可能不会被ldd列出来。作为glibc的一部分的NSS （Name Server Switch）库就是一个典型的例子，NSS的一个作用就是告诉应用程序到哪里去寻找系统帐号数据库。应用程序不会直接连接到NSS库，glibc则会通 过dlopen自动调入NSS库。如果这样的库偶然丢失，你不会被告知存在库依赖问题，但这样的程序就无法通过用户名解析得到用户ID了。让我们看一个例 子：
whoami程序会给出你自己的用户名，这个程序在一些需要知道运行程序的真正用户的脚本程序里面非常有用，whoami的一个示例输出如下：
代码：
# whoami
root
假设因为某种原因在升级glibc的过程中负责用户名和用户ID转换的库NSS丢失，我们可以通过把nss库改名来模拟这个环境：
代码：
# mv /lib/libnss_files.so.2 /lib/libnss_files.so.2.backup
# whoami
whoami: cannot find username for UID 0
这里你可以看到，运行whoami时出现了错误，ldd程序的输出不会提供有用的帮助：
代码：
# ldd /usr/bin/whoami
libc.so.6 => /lib/libc.so.6 (0x4001f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0×40000000)
你只会看到whoami依赖Libc.so.6和ld-linux.so.2，它没有给出运行whoami所必须的其他库。这里时用strace跟踪whoami时的输出：
代码：
strace -o whoami-strace.txt whoami
open(“/lib/libnss_files.so.2″, O_RDONLY) = -1 ENOENT (No such file or directory)
open(“/lib/i686/mmx/libnss_files.so.2″, O_RDONLY) = -1 ENOENT (No such file or directory)
stat64(“/lib/i686/mmx”, 0xbffff190) = -1 ENOENT (No such file or directory)
open(“/lib/i686/libnss_files.so.2″, O_RDONLY) = -1 ENOENT (No such file or directory)
stat64(“/lib/i686″, 0xbffff190) = -1 ENOENT (No such file or directory)
open(“/lib/mmx/libnss_files.so.2″, O_RDONLY) = -1 ENOENT (No such file or directory)
stat64(“/lib/mmx”, 0xbffff190) = -1 ENOENT (No such file or directory)
open(“/lib/libnss_files.so.2″, O_RDONLY) = -1 ENOENT (No such file or directory)
stat64(“/lib”, {st_mode=S_IFDIR|0755, st_size=2352,
…}) = 0
open(“/usr/lib/i686/mmx/libnss_files.so.2″, O_RDONLY) = -1 ENOENT (No such file or directory)
stat64(“/usr/lib/i686/mmx”, 0xbffff190) = -1 ENOENT (No such file or directory)
open(“/usr/lib/i686/libnss_files.so.2″, O_RDONLY) = -1 ENOENT (No such file or directory)
你可以发现在不同目录下面查找libnss.so.2的尝试，但是都失败了。如果没有strace这样的工具，很难发现这个错误是由于缺少动态库造成的。现在只需要找到libnss.so.2并把它放回到正确的位置就可以了。
[BOLD]限制strace只跟踪特定的系统调用[/BOLD]
如果你已经知道你要找什么，你可以让strace只跟踪一些类型的系统调用。例如，你需要看看在configure脚本里面执行的程序，你需要监视的系统调用就是execve。让strace只记录execve的调用用这个命令：
代码：
strace -f -o configure-strace.txt -e execve ./configure
部分输出结果为：
代码：
2720 execve(“/usr/bin/expr”, ["expr", "a", ":", "(a)"],
[/* 31 vars */]) = 0
2725 execve(“/bin/basename”, ["basename", "./configure"], [/*
31 vars */]) = 0
2726 execve(“/bin/chmod”, ["chmod", "+x", "conftest.sh"],
[/* 31 vars */]) = 0
2729 execve(“/bin/rm”, ["rm", "-f", "conftest.sh"],
[/* 31 vars */]) = 0
2731 execve(“/usr/bin/expr”, ["expr", "99", "+", "1"],
[/* 31 vars */]) = 0
2736 execve(“/bin/ln”, ["ln", "-s", "conf2693.file", "conf2693"],
[/* 31 vars */]) = 0
你已经看到了，strace不仅可以被程序员使用，普通系统管理员和用户也可以使用strace来调试系统错误。必须承认，strace的输出不总是容易理解，但是很多输出对大多数人来说是不重要的。你会慢慢学会从大量输出中找到你可能需要的信息，像权限错误，文件未找到之类的，那时strace就会成为一个有力的工具了。