我已经阅读了这个提醒
字体大小：小中大
关于高负载服务器Kernel的TCP参数优化
net.ipv4.tcp_mem
内核分配给TCP连接的内存，单位是Page，1 Page = 4096 Bytes，可用命令查看：
& #getconf PAGESIZE
& net.ipv4.tcp_mem = 196608 & & & 3216
& 第一个数字表示，当 tcp 使用的 page 少于 196608 时，kernel 不对其进行任何的干预
& 第二个数字表示，当 tcp 使用了超过 262144 的 pages 时，kernel 会进入 &memory pressure& 压力模式
& 第三个数字表示，当 tcp 使用的 pages 超过 393216 时（相当于1.6GB内存），就会报：Out of socket memory
& 以上数值适用于4GB内存机器，对于8GB内存机器，建议用以下参数：
& net.ipv4.tcp_mem = 524288 & & 48576 &（TCP连接最多约使用4GB内存）
net.ipv4.tcp_rmem 和 net.ipv4.tcp_wmem
为每个TCP连接分配的读、写缓冲区内存大小，单位是Byte
& net.ipv4.tcp_rmem = 4096 & & & &8192 & &4194304
& net.ipv4.tcp_wmem = 4096 & & & &8192 & &4194304
& 第一个数字表示，为TCP连接分配的最小内存
& 第二个数字表示，为TCP连接分配的缺省内存
& 第三个数字表示，为TCP连接分配的最大内存
& 一般按照缺省值分配，上面的例子就是读写均为8KB，共16KB
& 1.6GB TCP内存能容纳的连接数，约为 &1600MB/16KB = 100K = 10万
& 4.0GB TCP内存能容纳的连接数，约为 &4000MB/16KB = 250K = 25万
net.ipv4.tcp_max_orphans
最大孤儿套接字(orphan sockets)数，单位是个
net.ipv4.tcp_max_orphans = 65536
表示最多65536个
注意：当cat /proc/net/sockstat看到的orphans数量达到net.ipv4.tcp_max_orphans的约一半时，就会报：Out of socket memory
详见kernel源码：
& &include/net/tcp.h:
&268 static inline bool tcp_too_many_orphans(struct sock *sk, int shift)
&270 & & & & struct percpu_counter *ocp = sk-&sk_prot-&orphan_
&271 & & & & int orphans = percpu_counter_read_positive(ocp);
&273 & & & & if (orphans && shift & sysctl_tcp_max_orphans) {
&274 & & & & & & & & orphans = percpu_counter_sum_positive(ocp);
&275 & & & & & & & & if (orphans && shift & sysctl_tcp_max_orphans)
&276 & & & & & & & & & & & &
&277 & & & & }
&279 & & & & if (sk-&sk_wmem_queued & SOCK_MIN_SNDBUF &&
&280 & & & & & & atomic_long_read(&tcp_memory_allocated) & sysctl_tcp_mem[2])
&281 & & & & & & & &
&282 & & & &
& 参考http://blog.tsunanet.net/2011/03/out-of-socket-memory.html
& 对于net.ipv4.tcp_max_orphans = 65536，当orphans达到32768个时，会报Out of socket memory，此时占用内存 32K*64KB=2048MB=2GB
& （每个孤儿socket可占用多达64KB内存），实际可能小一些
net.ipv4.tcp_orphan_retries
孤儿socket废弃前重试的次数，重负载web服务器建议调小
& net.ipv4.tcp_orphan_retries = 1
& 设置较小的数值，可以有效降低orphans的数量（net.ipv4.tcp_orphan_retries = 0并不是想像中的不重试）
net.ipv4.tcp_retries2
活动TCP连接重传次数，超过次数视为掉线，放弃连接。缺省值：15，建议设为 2或者3.
net.ipv4.tcp_synack_retries
TCP三次握手的syn/ack阶段，重试次数，缺省5，设为2-3
net.ipv4.tcp_fin_timeout = 30
FIN_WAIT状态的TCP连接的超时时间
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
TIME_WAIT状态的socket快速回收，循环使用
net.ipv4.tcp_max_syn_backlog = 4096
TCP连接SYN队列大小
net.core.netdev_max_backlog = 2048
网络设备的收发包的队列大小
net.ipv4.tcp_syncookies = 1
TCP SYN Cookies，防范DDOS攻击，防止SYN队列被占满
参考文献：
http://jaseywang.me//%E5%85%B3%E4%BA%8E-out-of-socket-memory-%E7%9A%84%E8%A7%A3%E9%87%8A-2/
http://blog.tsunanet.net/2011/03/out-of-socket-memory.html
/blog/cs/?p=1062
zih的人气博文
访问(18382)评论(0)
访问(16359)评论(0)
访问(10077)评论(0)
访问(9995)评论(0)
访问(6675)评论(0)
本博文的最近访客
我来评两句
本周推荐博文t117 的BLOG
用户名：t117
访问量：1617
注册日期：
阅读量：5863
阅读量：12276
阅读量：340106
阅读量：1042297
[匿名]ylw6006：
51CTO推荐博文
环境说明&1.硬件 -- Lenovo530/540 Intel(R) Xeon(R) CPU E5-2620 64G&2.系统 -- RHEL6.4X64问题表现& [见附件]&1. 系统未重启前正常运行。(reboot重启)&2. reboot后，过一段时间(过多长时间不一定,也并不是reboot之后一定会出问题)负载飙升不降。服务器可以Ping通，开放的端口可以telnet但无法ssh。&& 终端亦是无法登入。&3. 已出现问题的服务器，通过reboot重启无法恢复正常。&4. 可以确定拔电后再启动服务器此问题便可恢复。求助：&1.有没有什么办法可以确定这是什么原因造成的。&2.是否可以查具体是什么占用了系统资源导致负载超高。&3.是否有人遇到过类似问题，又是如何解决的。(大批量服务器出现该问题，一台台的拔电重启不太现实。)&本文出自 “” 博客，请务必保留此出处
了这篇文章
附件下载：　　
类别：未分类┆阅读(0)┆评论(0)
请输入验证码：查看:1592|回复：7
发布上去呀是怎么回事
1.硬件 -- Lenovo530/540 Intel(R) Xeon(R) CPU E5-2620 64G
2.系统 -- RHEL6.4X64
(347.56 KB)
1. 系统未重启前正常运行。(reboot重启)
2. reboot后，过一段时间(过多长时间不一定,也并不是reboot之后一定会出问题)负载飙升不降。服务器可以Ping通，开放的端口可以telnet但无法ssh。& &终端亦是无法登入。
3. 已出现问题的服务器，通过reboot重启无法恢复正常。
4. 可以确定拔电后再启动服务器此问题便可恢复。
1.有没有什么办法可以确定这是什么原因造成的。
2.是否可以查具体是什么占用了系统资源导致负载超高。
3.是否有人遇到过类似问题，又是如何解决的。(大批量服务器出现该问题，一台台的拔电重启不太现实。)
助理工程师
引用:原帖由 t117 于
18:33 发表
1. 系统未重启前正常运行。(reboot重启)
2. reboot后，过一段时间(过多长时间不一定,也并不是reboot之后一定会出问题)负载飙升不降。服务器可以Ping通，开放的端口可以telnet但无法ssh。& &终端亦是无法登入。
&&... 有可能存在服务器的问题，如果没过保，可以咨询联想的服务器售后
引用:原帖由 zhouhuaooo 于
07:50 发表
有可能存在服务器的问题，如果没过保，可以咨询联想的服务器售后 最早的时候是直接找他们换主板了。 但现在大量的服务器都有问题。也找他们工程师查过，没查到什么问题。。。还有没有别的办法
助理工程师
引用:原帖由 t117 于
09:16 发表
最早的时候是直接找他们换主板了。 但现在大量的服务器都有问题。也找他们工程师查过，没查到什么问题。。。还有没有别的办法 换一批其他型号的机器尝试下，不排除是这批服务器的问题
请问楼主解决这个问题了吗，我现在碰到的问题与你类似，找不到好的办法
看下是什么进程大量的占用资源服务器每天固定高负载 怎么排查-中国学网-中国IT综合门户网站-提供健康,养生,留学,移民,创业,汽车等信息
> 信息中心 >
服务器每天固定高负载 怎么排查
来源：互联网 发表时间： 17:53:17 责任编辑：王亮字体：
为了帮助网友解决“服务器每天固定高负载 怎么排查”相关的问题，中国学网通过互联网对“服务器每天固定高负载 怎么排查”相关的解决方案进行了整理,用户详细问题包括:RT,我想知道:服务器每天固定高负载 怎么排查，具体解决方案如下：解决方案1：
确认服务器硬件是否足够支持当前的流量。 第一，那么必须首先配置一台更高性能的专用服务器才能解决问题.，如果访问量比这个还要大。 普通的P4服务器一般最多能支持每天10万独立IP.，否则怎么优化都不可能彻底解决性说白了就是服务器的承受能力
相关文章：
最新添加资讯
24小时热门资讯
Copyright © 2004- All Rights Reserved. 中国学网 版权所有
京ICP备号-1 京公网安备02号用负载均衡技术建设高负载站点_服务器_中国百科网
用负载均衡技术建设高负载站点
    负载均衡技术(1)
用负载均衡技术建设高负载站点
　Internet的快速增长使多媒体网络服务器，特别是Web服务器，面对的访问者数量快速增加，网络服务器需要具备提供大量并发访问服务的能力。例如Yahoo每天会收到数百万次的访问请求，因此对于提供大负载Web服务的服务器来讲，CPU、I/O处理能力很快会成为瓶颈。 　　简单的提高硬件性能并不能真正解决这个问题，因为单台服务器的性能总是有限的，一般来讲，一台PC服务器所能提供的并发访问处理能力大约为1000个，更为高档的专用服务器能够支持个并发访问，这样的能力还是无法满足负载较大的网站的要求。尤其是网络请求具有突发性，当某些重大事件发生时，网络访问就会急剧上升，从而造成网络瓶颈，例如在网上发布的克林顿弹劾书就是很明显的例子。必须采用多台服务器提供网络服务，并将网络请求分配给这些服务器分担，才能提供处理大量并发服务的能力。　　当使用多台服务器来分担负载的时候，最简单的办法是将不同的服务器用在不同的方面。按提供的内容进行分割时，可以将一台服务器用于提供新闻页面，而另一台用于提供游戏页面；或者可以按服务器的功能进行分割，将一台服务器用于提供静态页面访问，而另一些用于提供CGI等需要大量消耗资源的动态页面访问。然而由于网络访问的突发性，使得很难确定那些页面造成的负载太大，如果将服务的页面分割的过细就会造成很大浪费。事实上造成负载过大的页面常常是在变化中的，如果要经常按照负载变化来调整页面所在的服务器，那么势必对管理和维护造成极大的问题。因此这种分割方法只能是大方向的调整，对于大负载的网站，根本的解决办法还需要应用负载均衡技术。　　负载均衡的思路下多台服务器为对称方式，每台服务器都具备等价的地位，都可以单独对外提供服务而无须其他服务器的辅助。然后通过某种负载分担技术，将外部发送来的请求均匀分配到对称结构中的某一台服务器上，而接收到请求的服务器都独立回应客户机的请求。由于建立内容完全一致的Web服务器并不复杂，可以使用服务器同步更新或者共享存储空间等方法来完成，因此负载均衡技术就成为建立一个高负载Web站点的关键性技术。 　　基于特定服务器软件的负载均衡 　　很多网络协议都支持“重定向”功能，例如在HTTP协议中支持Location指令，接收到这个指令的浏览器将自动重定向到Location指明的另一个URL上。由于发送Location指令比起执行服务请求，对Web服务器的负载要小的多，因此可以根据这个功能来设计一种负载均衡的服务器。任何时候Web服务器认为自己负载较大的时候，它就不再直接发送回浏览器请求的网页，而是送回一个Locaction指令，让浏览器去服务器集群中的其他服务器上获得所需要的网页。 　　在这种方式下，服务器本身必须支持这种功能，然而具体实现起来却有很多困难，例如一台服务器如何能保证它重定向过的服务器是比较空闲的，并且不会再次发送Location指令？Location指令和浏览器都没有这方面的支持能力，这样很容易在浏览器上形成一种死循环。因此这种方式实际应用当中并不多见，使用这种方式实现的服务器集群软件也较少。有些特定情况下可以使用CGI（包括使用FastCGI或mod_perl扩展来改善性能）来模拟这种方式去分担负载，而Web服务器仍然保持简洁、高效的特性，此时避免Location循环的任务将由用户的CGI程序来承担。 　　基于DNS的负载均衡 　　由于基于服务器软件的负载均衡需要改动软件，因此常常是得不偿失，负载均衡最好是在服务器软件之外来完成，这样才能利用现有服务器软件的种种优势。最早的负载均衡技术是通过DNS服务中的随机名字解析来实现的，在DNS服务器中，可以为多个不同的地址配置同一个名字，而最终查询这个名字的客户机将在解析这个名字时得到其中的一个地址。因此，对于同一个名字，不同的客户机会得到不同的地址，他们也就访问不同地址上的Web服务器，从而达到负载均衡的目的。
　　例如如果希望使用三个Web服务器来回应对www.的HTTP请求，就可以设置该域的DNS服务器中关于该域的数据包括有与下面例子类似的结果： 　　www1 IN A 192.168.1.1 　　www2 IN A 192.168.1.2 　　www3 IN A 192.168.1.3 　　www IN CNAME www1 　　www IN CNAME www2 　　www IN CNAME www3 　　此后外部的客户机就可能随机的得到对应www的不同地址，那么随后的HTTP请求也就发送给不同地址了。 　　DNS负载均衡的优点是简单、易行，并且服务器可以位于互联网的任意位置上，当前使用在包括Yahoo在内的Web站点上。然而它也存在不少缺点，一个缺点是为了保证DNS数据及时更新，一般都要将DNS的刷新时间设置的较小，但太小就会造成太大的额外网络流量，并且更改了DNS数据之后也不能立即生效；第二点是DNS负载均衡无法得知服务器之间的差异，它不能做到为性能较好的服务器多分配请求，也不能了解到服务器的当前状态，甚至会出现客户请求集中在某一台服务器上的偶然情况。 　　反向代理负载均衡 　　使用代理服务器可以将请求转发给内部的Web服务器，使用这种加速模式显然可以提升静态网页的访问速度。因此也可以考虑使用这种技术，让代理服务器将请求均匀转发给多台内部Web服务器之一上，从而达到负载均衡的目的。这种代理方式与普通的代理方式有所不同，标准代理方式是客户使用代理访问多个外部Web服务器，而这种代理方式是多个客户使用它访问内部Web服务器，因此也被称为反向代理模式。 　　实现这个反向代理能力并不能算是一个特别复杂的任务，但是在负载均衡中要求特别高的效率，这样实现起来就不是十分简单的了。每针对一次代理，代理服务器就必须打开两个连接，一个为对外的连接，一个为对内的连接，因此对于连接请求数量非常大的时候，代理服务器的负载也就非常之大了，在最后反向代理服务器会成为服务的瓶颈。例如，使用Apache的mod_rproxy模块来实现负载均衡功能时，提供的并发连接数量受Apache本身的并发连接数量的限制。一般来讲，可以使用它来对连接数量不是特别大，但每次连接都需要消耗大量处理资源的站点进行负载均衡，例如搜寻。 　　使用反向代理的好处是，可以将负载均衡和代理服务器的高速缓存技术结合在一起，提供有益的性能，具备额外的安全性，外部客户不能直接访问真实的服务器。并且实现起来可以实现较好的负载均衡策略，将负载可以非常均衡的分给内部服务器，不会出现负载集中到某个服务器的偶然现象。 　　基于NAT的负载均衡技术 　　网络地址转换为在内部地址和外部地址之间进行转换，以便具备内部地址的计算机能访问外部网络，而当外部网络中的计算机访问地址转换网关拥有的某一外部地址时，地址转换网关能将其转发到一个映射的内部地址上。因此如果地址转换网关能将每个连接均匀转换为不同的内部服务器地址，此后外部网络中的计算机就各自与自己转换得到的地址上服务器进行通信，从而达到负载分担的目的。
　　地址转换可以通过软件方式来实现，也可以通过硬件方式来实现。使用硬件方式进行操作一般称为交换，而当交换必须保存TCP连接信息的时候，这种针对OSI网络层的操作就被称为第四层交换。支持负载均衡的网络地址转换为第四层交换机的一种重要功能，由于它基于定制的硬件芯片，因此其性能非常优秀，很多交换机声称具备400MB-800MB的第四层交换能力，然而也有一些资料表明，在如此快的速度下，大部分交换机就不再具备第四层交换能力了，而仅仅支持第三层甚至第二层交换。 　　然而对于大部分站点来讲，当前负载均衡主要是解决Web服务器处理能力瓶颈的，而非网络传输能力，很多站点的互联网连接带宽总共也不过10MB，只有极少的站点能够拥有较高速的网络连接，因此一般没有必要使用这些负载均衡器这样的昂贵设备。 　　使用软件方式来实现基于网络地址转换的负载均衡则要实际的多，除了一些厂商提供的解决方法之外，更有效的方法是使用免费的自由软件来完成这项任务。其中包括Linux Virtual Server Project中的NAT实现方式，或者本文作者在FreeBSD下对natd的修订版本。一般来讲，使用这种软件方式来实现地址转换，中心负载均衡器存在带宽限制，在100MB的快速以太网条件下，能得到最快达80MB的带宽，然而在实际应用中，可能只有40MB-60MB的可用带宽。 　　扩展的负载均衡技术 　　上面使用网络地址转换来实现负载分担，毫无疑问所有的网络连接都必须通过中心负载均衡器，那么如果负载特别大，以至于后台的服务器数量不再在是几台、十几台，而是上百台甚至更多，即便是使用性能优秀的硬件交换机也回遇到瓶颈。此时问题将转变为，如何将那么多台服务器分布到各个互联网的多个位置，分散网络负担。当然这可以通过综合使用DNS和NAT两种方法来实现，然而更好的方式是使用一种半中心的负载均衡方式。 　　在这种半中心的负载均衡方式下，即当客户请求发送给负载均衡器的时候，中心负载均衡器将请求打包并发送给某个服务器，而服务器的回应请求不再返回给中心负载均衡器，而是直接返回给客户，因此中心负载均衡器只负责接受并转发请求，其网络负担就较小了。
　　上图来自Linux Virtual Server Project，为他们使用IP隧道实现的这种负载分担能力的请求/回应过程，此时每个后台服务器都需要进行特别的地址转换，以欺骗浏览器客户，认为它的回应为正确的回应。 　　同样，这种方式的硬件实现方式也非常昂贵，但是会根据厂商的不同，具备不同的特殊功能，例如对SSL的支持等。 　　由于这种方式比较复杂，因此实现起来比较困难，它的起点也很高，当前情况下网站并不需要这么大的处理能力。 　　比较上面的负载均衡方式，DNS最容易，也最常用，能够满足一般的需求。但如果需要进一步的管理和控制，可以选用反向代理方式或NAT方式，这两种之间进行选择主要依赖缓冲是不是很重要，最大的并发访问数量是多少等条件。而如果网站上对负载影响很厉害的CGI程序是由网站自己开发的，也可以考虑在程序中自己使用Locaction来支持负载均衡。半中心化的负载分担方式至少在国内当前的情况下还不需要。
Copyright by ；All rights reserved.