我正在尝试通过“具有大量连接和小数据包高流量的千兆网络”来提高我的 TCP 吞吐量。我的服务器操作系统是 Ubuntu 11.10 Server 64bit。
大约有 50.000 个（并且还在不断增加）客户端通过 TCP 套接字（都在同一个端口上）连接到我的服务器。
我 95% 的数据包大小为 1-150 字节（TCP 标头和有效负载）。其余 5% 从 150 到 4096+ 字节不等。
使用下面的配置，我的服务器可以处理高达 30 Mbps（全双工）的流量。
您能否建议最佳实践以根据我的需要调整操作系统？
我的/etc/sysctl.cong看起来像这样：
kernel.pid_max = 1000000
net.ipv4.ip_local_port_range = 2500 65000
fs.file-max = 1000000
#
net.core.netdev_max_backlog=3000
net.ipv4.tcp_sack=0
#
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.somaxconn = 2048
#
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
#
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_mem = 50576 64768 98152
#
net.core.wmem_default = …在基于以前的配置构建新内核时，有没有办法使该make oldconfig过程自动化，以便将新选项设置为其默认值？
编辑：我的意思是，在较新的内核上使用 .config（来自/boot/config-*或/proc/config.gz）时，该make oldconfig过程会询问您是否要启用旧内核中不可用的选项。您可以回答 Y/n/m 或按 Enter 接受默认值。我想在没有用户交互的情况下自动接受默认值。
Linux 上的 OOM 杀手时常对各种应用程序造成严重破坏，而且似乎在内核开发方面并没有真正做很多事情来改进这一点。作为设置新服务器时的最佳实践，在内存过量使用时反转默认设置，即关闭它 ( vm.overcommit_memory=2) ，除非您知道需要将其打开以用于特定用途，这不是更好吗？这些用例是什么，你知道你想要过度使用？
作为奖励，由于情况下的行为vm.overcommit_memory=2取决于vm.overcommit_ratio和交换空间，因此调整后两者的大小以便整个设置保持合理工作的良好经验法则是什么？
我注意到在我刚从 EC2 启动的新 CentOS 映像上，ulimit 默认值是 1024 个打开的文件，但是 /proc/sys/fs/file-max 设置为 761,408，我想知道这两个限制是如何工作的一起。我猜 ulimit -n 是每个用户的文件描述符数量限制，而 /proc/sys/fs/file-max 是系统范围的？如果是这种情况，假设我已经以同一用户身份登录了两次——每个登录用户的打开文件数是否有 1024 个限制，或者每个登录的用户之间是否有 1024 个组合打开文件的限制——在用户？
如果您的系统从未打开过很多文件，那么将最大文件描述符设置为非常高的数字是否会对性能产生很大影响？
最近我们有一个 apache 服务器，由于 SYN 泛滥，它的响应非常缓慢。解决方法是启用 tcp_syncookies ( net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf)。
如果您想要更多背景知识，我在这里发布了一个关于此的问题。
启用 syncookies 后，我们开始大约每 60 秒在 /var/log/messages 中看到以下消息：
[84440.731929] possible SYN flooding on port 80. Sending cookies.
Vinko Vrsalovic 告诉我，这意味着 syn backlog 已满，所以我将 tcp_max_syn_backlog 提高到 4096。在某些时候，我还通过发出sysctl -w net.ipv4.tcp_synack_retries=3. 这样做之后，频率似乎下降了，消息的间隔在大约 60 到 180 秒之间变化。
接下来我发出了sysctl -w net.ipv4.tcp_max_syn_backlog=65536，但仍然在日志中收到消息。
在所有这一切中，我一直在观察处于 SYN_RECV 状态的连接数（通过运行watch --interval=5 'netstat -tuna |grep "SYN_RECV"|wc -l'），它永远不会高于大约 240，远低于积压的大小。但是我有一个 Red Hat 服务器，它在 512 左右徘徊（此服务器的限制是默认值 1024）。
是否有任何其他 tcp 设置会限制积压的大小，或者我是否在咆哮错误的树？SYN_RECV 连接的数量是否应该netstat -tuna与积压的大小相关？
尽我所能，我正在处理这里的合法连接， …
在 Linux 上有没有办法获取有关数据包被丢弃的各种原因的统计信息？
在多个服务器上的所有网络接口 (openSUSE 12.3) 上，ifconfig并netstat -i在接收时报告丢弃的数据包。当我执行 a 时tcpdump，丢弃的数据包数量停止增加，这意味着接口队列未满并丢弃数据。所以一定有其他原因导致这种情况发生（例如，接收到多播 pkts 而接口不是该多播组的一部分）。
我在哪里可以找到此类信息？（/proc？/sys？一些日志？）
统计示例（/sys/class/net/<dev>/statistics 和 ethtool 输出的合并）：
alloc_rx_buff_failed: 0
collisions: 0
dropped_smbus: 0
multicast: 1644
rx_align_errors: 0
rx_broadcast: 23626
rx_bytes: 1897203
rx_compressed: 0
rx_crc_errors: 0
rx_csum_offload_errors: 0
rx_csum_offload_good: 0
rx_dropped: 4738
rx_errors: 0
rx_fifo_errors: 0
rx_flow_control_xoff: 0
rx_flow_control_xon: 0
rx_frame_errors: 0
rx_length_errors: 0
rx_long_byte_count: 1998731
rx_long_length_errors: 0
rx_missed_errors: 0
rx_multicast: 1644
rx_no_buffer_count: 0
rx_over_errors: 0
rx_packets: 25382
rx_short_length_errors: 0
rx_smbus: 0
tx_aborted_errors: 0
tx_abort_late_coll: …给定如下内核堆栈跟踪，您如何确定发生问题的特定代码行？
kernel: [<ffffffff80009a14>] __link_path_walk+0x173/0xfb9
kernel: [<ffffffff8002cbec>] mntput_no_expire+0x19/0x89
kernel: [<ffffffff8000eb94>] link_path_walk+0xa6/0xb2
kernel: [<ffffffff80063c4f>] __mutex_lock_slowpath+0x60/0x9b
kernel: [<ffffffff800238de>] __path_lookup_intent_open+0x56/0x97
kernel: [<ffffffff80063c99>] .text.lock.mutex+0xf/0x14
kernel: [<ffffffff8001b222>] open_namei+0xea/0x712
kernel: [<ffffffff8006723e>] do_page_fault+0x4fe/0x874
kernel: [<ffffffff80027660>] do_filp_open+0x1c/0x38
kernel: [<ffffffff8001a061>] do_sys_open+0x44/0xbe
kernel: [<ffffffff8005d28d>] tracesys+0xd5/0xe0
虽然我可以轻松找到函数调用——但将__link_path_walk加上偏移量转换为实际行号是困难的部分。
假设这是针对标准发行版提供的内核，我知道其确切版本和内部版本号，那么获取必要元数据并进行相应查找的过程是什么？
我有一些生产 Fedora 和 Debian 网络服务器，它们托管我们的站点以及用户 shell 帐户（用于 git vcs 工作、一些 screen+irssi 会话等）。
有时，新的内核更新会在yum/ 中的管道中出现apt-get，我想知道大多数修复是否严重到足以保证重新启动，或者我是否可以应用修复而无需重新启动。
我们的主要开发服务器目前有 213 天的正常运行时间，我不确定运行这么旧的内核是否不安全。
我最近为我的 Debian 服务器购买了一个新的 16TB 硬盘。我首先通过我的类似 Ubuntu 的桌面在其上创建了一个分区 (gpt)，对其进行了格式化 (ext4)，并在其上 rsync 了旧数据。该磁盘现在可以使用，因此我将其插入到我的服务器中。现在开始一个我无法识别的奇怪的 I/O。
iotop -ao报告 3MB/s，Current DISK WRITE 但没有任何迹象表明是谁在执行此操作fatrace -c -t报告没有写入或读取，但如果我自己有touch一个文件，请报告它。dstat -tdD /dev/sdx --top-io报告每秒稳定的 3072k 写入，与 一致iotop，但也没有罪魁祸首，只是在i/o process应该有名称的地方有一个空白，但它确实确认了 I/O 操作是在所述磁盘上，这是我最初推断的它发出的噪音……现在我知道 iotop 标头显示的内容与 I/O 写入和/或从进程读取的总和之间可能存在不一致，如此处所述。但与之前的帖子相反，当时：
几个小时后（至少 10，不超过 20）噪音消失了，磁盘上不再有 3MB/s 的输入。
我的问题是：编写一些缓存系统、初始化表或类似的东西可以解释这个恒定的 3MB/s 写入 10-20 小时是否是正常行为（虽然我以前从未观察到过）（可能来自内核？） ？
我最初想到的是加密/随机病毒，但即使以 3MB/s 的速度运行 20 小时也不可能覆盖 16 个可用磁盘上写入的 12TB。
这有什么合乎逻辑的解释吗？
当某些与时间相关的程序（如ntpd）在 Linux 系统上运行时，内核将切换到所谓的“十一分钟模式”（参见hwclock手册页），从而每十一分钟从系统时钟自动更新硬件时钟.
在 SLES11 上，我凭经验确定，如果我将硬件时钟设置为比系统时钟晚 10 小时，11 分钟模式似乎无法使硬件时钟与系统时钟匹配。但是如果我将硬件时钟设置为比系统时钟晚 5 分钟，那么 11 分钟模式就完美匹配了。
所以显然有一些 11 分钟模式可以处理的最大更新，我想知道它是什么。
更新：
这很奇怪...
更多的试验表明，当我身边有系统时钟落后20分钟HW时钟的11分钟的模式将设置硬件时钟是准确的系统时钟落后30分钟（！）：
# date
Tue Dec 6 10:16:52 EST 2011
# hwclock --set --date "12/6/11 09:56"
#
# date
Tue Dec 6 10:17:16 EST 2011
# hwclock --show
Tue Dec 6 09:56:06 2011 -0.156551 seconds
#
# date
Tue Dec 6 10:23:09 EST 2011
# hwclock --show
Tue Dec 6 10:01:58 2011 -0.535772 seconds
#
# date …