通知设置 新通知
TIME_WAIT和CLOSE_WAIT解疑(上)
being 发表了文章 0 个评论 4459 次浏览 2016-02-20 18:11
一、你遇到过TIME_WAIT的问题吗？
我相信很多人都遇到过这个问题。一旦有用户在喊：网络变慢了。第一件事情就是：netstat -a | grep TIME_WAIT | wc -l
查看一下TIME——WAIT数量 ...查看全部
一、你遇到过TIME_WAIT的问题吗？
我相信很多人都遇到过这个问题。一旦有用户在喊：网络变慢了。第一件事情就是：
netstat -a | grep TIME_WAIT | wc -l
查看一下TIME——WAIT数量，哎哟好几千个TIME_WAIT.
然后，做的第一件事情就是：打开Google、Baidu或者Bing，输入关键词：too many time wait。一定能找到解决方案，而排在最前面或者被很多人到处转载的解决方案一定是：
打开 sysctl.conf 文件，修改以下几个参数：
net.ipv4.tcp_tw_recycle = 1你也会被告知，开启tw_recylce和tw_reuse一定需要timestamps的支持，而且这些配置一般不建议开启，但是对解决TIME_WAIT多的问题，有很大的用处。
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_timestamps = 1
接下来，你就直接修改了这几个参数，reload一下，发现，咦，没几分钟，TIME_WAIT的数量真的降低了，也没发现哪个用户说有问题，然后就没有然后了。
做到这一步，相信50%或者更高比例的运维或者开发就已经止步了。问题好像解决了，但是，要彻底理解并解决这个问题，可能就没这么简单，或者说，还有很长的路要走！
二、什么是TIME-WAIT和CLOSE-WAIT?
所谓，要解决问题，就要先理解问题。随便改两行代码，发现bug“没有了”，也不是bug真的没有了，只是隐藏在更深的地方，你没有发现，或者以你的知识水平，你无法发现而已。
大家知道，由于socket是全双工的工作模式，一个socket的关闭，是需要四次握手来完成的。
- []主动关闭连接的一方，调用close()；协议层发送FIN包[/][]被动关闭的一方收到FIN包后，协议层回复ACK；然后被动关闭的一方，进入CLOSE_WAIT状态，主动关闭的一方等待对方关闭，则进入FIN_WAIT_2状态；此时，主动关闭的一方 等待 被动关闭一方的应用程序，调用close操作[/][]被动关闭的一方在完成所有数据发送后，调用close()操作；此时，协议层发送FIN包给主动关闭的一方，等待对方的ACK，被动关闭的一方进入LAST_ACK状态；[/][]主动关闭的一方收到FIN包，协议层回复ACK；此时，主动关闭连接的一方，进入TIME_WAIT状态；而被动关闭的一方，进入CLOSED状态[/][]等待2MSL时间，主动关闭的一方，结束TIME-WAIT，进入CLOSED状态[/]
大家经常提socket，那么，到底什么是一个socket？其实，socket就是一个 五元组，包括：[list=1][]源IP[/][]源端口[/][]目的IP[/][]目的端口[/][]类型：TCP or UDP[/]这个五元组，即标识了一条可用的连接。注意，有很多人把一个socket定义成四元组，也就是 源IP:源端口 + 目的IP:目的端口，这个定义是不正确的。 例如，如果你的本地出口IP是180.172.35.150，那么你的浏览器在连接某一个Web服务器，例如百度的时候，这条socket连接的四元组可能就是：三、Socket连接到底是个什么概念？
[180.172.35.150:45678, tcp, 180.97.33.108:80]源IP为你的出口IP地址 180.172.35.150，源端口为随机端口 45678，目的IP为百度的某一个负载均衡服务器IP 180.97.33.108，端口为HTTP标准的80端口。 如果这个时候，你再开一个浏览器，访问百度，将会产生一条新的连接：[180.172.35.150:43678, tcp, 180.97.33.108:80]这条新的连接的源端口为一个新的随机端口 43678。 如此来看，如果你的本机需要压测百度，那么，你最多可以创建多少个连接呢？ 第二个问题，TIME_WAIT有什么用？如果我们来做个类比的话，TIME_WAIT的出现，对应的是你的程序里的异常处理，它的出现，就是为了解决网络的丢包和网络不稳定所带来的其他问题： 第一，防止前一个连接【五元组，我们继续以 180.172.35.150:45678, tcp, 180.97.33.108:80 为例】上延迟的数据包或者丢失重传的数据包，被后面复用的连接【前一个连接关闭后，此时你再次访问百度，新的连接可能还是由180.172.35.150:45678, tcp, 180.97.33.108:80 这个五元组来表示，也就是源端口凑巧还是45678】错误的接收（异常：数据丢了，或者传输太慢了），参见下图： 
- []如果没有TIME_WAIT，或者TIME_WAIT时间非常端，那么关闭的连接【180.172.35.150:45678, tcp, 180.97.33.108:80 的状态变为了CLOSED，源端口可被再次利用】，马上被重用【对180.97.33.108:80新建的连接，复用了之前的随机端口45678】，并连续发送SEQ=1,2 的数据包[/][]此时，前面的连接上的SEQ=3的数据包再次重传，同时，seq的序号刚好也是3（这个很重要，不然，SEQ的序号对不上，就会RST掉），此时，前面一个连接上的数据被后面的一个连接错误的接收[/]
- []主动关闭方关闭了连接，发送了FIN；[/][]被动关闭方回复ACK同时也执行关闭动作，发送FIN包；此时，被动关闭的一方进入LAST_ACK状态[/][]主动关闭的一方回去了ACK，主动关闭一方进入TIME_WAIT状态；[/][]但是最后的ACK丢失，被动关闭的一方还继续停留在LAST_ACK状态[/][]此时，如果没有TIME_WAIT的存在，或者说，停留在TIME_WAIT上的时间很短，则主动关闭的一方很快就进入了CLOSED状态，也即是说，如果此时新建一个连接，源随机端口如果被复用，在connect发送SYN包后，由于被动方仍认为这条连接【五元组】还在等待ACK，但是却收到了SYN，则被动方会回复RST[/][]造成主动创建连接的一方，由于收到了RST，则连接无法成功 [/]
所以，你看到了，TIME_WAIT的存在是很重要的，如果强制忽略TIME_WAIT，还是有很高的机率，造成数据粗乱，或者短暂性的连接失败。
那么，为什么说，TIME_WAIT状态会是持续2MSL（2倍的max segment lifetime）呢？这个时间可以通过修改内核参数调整吗？第一，这个2MSL，是RFC 793里定义的，参见RFC的截图标红的部分：
#define TCP_TIMEWAIT_LEN (60[i]HZ) /[/i] how long to wait to destroy TIME-WAIT所以，再次回想一下前面的问题，如果一条连接，即使在四次握手关闭了，由于TIME_WAIT的存在，这个连接，在1分钟之内，也无法再次被复用，那么，如果你用一台机器做压测的客户端，你一分钟能发送多少并发连接请求？如果这台是一个负载均衡服务器，一台负载均衡服务器，一分钟可以有多少个连接同时访问后端的服务器呢？
[i] state, about 60 seconds [/i]/
写到这里，也许你稍微理解了TIME_WAIT和CLOSE_WAIT的区别!
分享原文：大房说
服务器磁盘只读修复过程记录
Ansible 发表了文章 0 个评论 3646 次浏览 2016-01-29 11:04
服务器的磁盘也没有做监控，其实我也不知道如何对磁盘的状态做监控，突然查看不到新数据，上去看了一下磁盘的情况，发现磁盘出现只读的情况，无法写入数据，后续研究一下怎么可以监控磁盘只读的方法。
处理过程
1、磁盘坏 ...查看全部
服务器的磁盘也没有做监控，其实我也不知道如何对磁盘的状态做监控，突然查看不到新数据，上去看了一下磁盘的情况，发现磁盘出现只读的情况，无法写入数据，后续研究一下怎么可以监控磁盘只读的方法。
1、磁盘坏道检查
出现问题之后，首先把业务停掉了，然后把磁盘卸载掉来进行修复，出现这种问题有可能是磁盘的磁道有坏区，我首先检查了一下磁盘坏道的情况。
2、修复磁盘文件系统
在修复文件系统的时候发现无法修复，提示Superblock invalid。
修复好之后，挂载进去目录查看如下
好歹只是丢失了文件夹的名称，剩下的回复交由DBA来进行操作。
处理过程
1、磁盘坏道检查
出现问题之后，首先把业务停掉了，然后把磁盘卸载掉来进行修复，出现这种问题有可能是磁盘的磁道有坏区，我首先检查了一下磁盘坏道的情况。
badblocks -sv /dev/sdb差不多检查了一些时间，发现并没有坏道。
2、修复磁盘文件系统
在修复文件系统的时候发现无法修复，提示Superblock invalid。
[root@ad4 ~]# fsck -t ext4 /dev/sdb3、查看文件系统备份Superblock
fsck from util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193
[root@ad4 ~]# mke2fs -n /dev/sdb4、修复文件系统
mke2fs 1.41.12 (17-May-2010)
/dev/sdb is entire device, not just one partition!
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=1 blocks, Stripe width=0 blocks
122093568 inodes, 488364854 blocks
24418242 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
14904 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848
e2fsck -b 214990848 -y /dev/sdb出现了很多修复的东西，修复了一会
修复好之后，挂载进去目录查看如下
好歹只是丢失了文件夹的名称，剩下的回复交由DBA来进行操作。
浅谈堡垒机概念和工作原理
push 发表了文章 0 个评论 17683 次浏览 2016-01-27 15:40
摘要
在信息化社会，企事业单位业务对信息系统高度依赖，而信息系统维护人员往往拥有系统最高管理权限，其操作行为必须得到有效监管与审计。作为运维操作审计最佳解决方案的堡垒机通常会给人一种神秘莫测的感觉，为了让大家更清楚的了解堡垒机和运维操 ...查看全部
摘要
在信息化社会，企事业单位业务对信息系统高度依赖，而信息系统维护人员往往拥有系统最高管理权限，其操作行为必须得到有效监管与审计。作为运维操作审计最佳解决方案的堡垒机通常会给人一种神秘莫测的感觉，为了让大家更清楚的了解堡垒机和运维操作审计，本文对堡垒机的概念及主要工作原理进行简要分析。
前言
当今的时代是一个信息化社会，信息系统已成为各企事业单位业务运营的基础,由于信息系统运维人员掌握着信息系统的最高权限，一旦运维操作出现安全问题将会给企业或单位带来巨大的损失。因此,加强对运维人员操作行为的监管与审计是信息安全发展的必然趋势。在此背景之下,针对运维操作管理与审计的堡垒机应运而生。堡垒机提供了一套多维度的运维操作控管控与审计解决方案，使得管理人员可以全面对各种资源(如网络设备、服务器、安全设备和数据库等)进行集中账号管理、细粒度的权限管理和访问审计，帮助企业提升内部风险控制水平。
堡垒机概念和种类
"堡垒"一词的含义是指用于防守的坚固建筑物或比喻难于攻破的事物，因此从字面的意思来看"堡垒机"是指用于防御攻击的计算机。在实际应用中堡垒机又被称为"堡垒主机"，是一个主机系统，其自身通常经过了一定的加固，具有较高的安全性，可抵御一定的攻击，其作用主要是将需要保护的信息系统资源与安全威胁的来源进行隔离，从而在被保护的资源前面形成一个坚固的"堡垒"，并且在抵御威胁的同时又不影响普通用户对资源的正常访问,堡垒机还集成了行为审计和权限控制，从而加强了堆操作和安全的控制。基于其应用场景，堡垒机可分为两种类型：
1、网关型堡垒机
网关型的堡垒机被部署在外部网络和内部网络之间，其本身不直接向外部提供服务而是作为进入内部网络的一个检查点，用于提供对内部网络特定资源的安全访问控制。这类堡垒机不提供路由功能，将内外网从网络层隔离开来，因此除非授权访问外还可以过滤掉一些针对内网的来自应用层以下的攻击，为内部网络资源提供了一道安全屏障。但由于此类堡垒机需要处理应用层的数据内容，性能消耗很大，所以随着网络进出口处流量越来越大，部署在网关位置的堡垒机逐渐成为了性能瓶颈，因此网关型的堡垒机逐渐被日趋成熟的防火墙、UTM、IPS、网闸等安全产品所取代。2、运维审计型堡垒机
第二种类型的堡垒机是审计型堡垒机，有时也被称作"内控堡垒机",这种类型的堡垒机也是当前应用最为普遍的一种。
运维审计型堡垒机的原理与网关型堡垒机类似，但其部署位置与应用场景不同且更为复杂。运维审计型堡垒机被部署在内网中的服务器和网络设备等核心资源的前面，对运维人员的操作权限进行控制和操作行为审计;运维审计型堡垒机即解决了运维人员权限难以控制混乱局面，又可对违规操作行为进行控制和审计，而且由于运维操作本身不会产生大规模的流量，堡垒机不会成为性能的瓶颈，所以堡垒机作为运维操作审计的手段得到了快速发展。
最早将堡垒机用于运维操作审计的是金融、运营商等高端行业的用户，由于这些用户的信息化水平相对较高发展也比较快，随着信息系统安全建设发展其对运维操作审计的需求表现也更为突出，而且这些用户更容易受到 "信息系统等级保护"、"萨班斯法案"等法规政策的约束，因此基于堡垒机作为运维操作审计手段的上述特点，这些高端行业用户率先将堡垒机应用于运维操作审计。
随着互联网的快速发展，web 2.0快速化和互联网公司运维人员对编程技能的掌握程度越来越重要，互联网公司安全意思越来越强，好多公司都已经开发使用堡垒机，作为权限控制和运维行为审计。
堡垒机运维操作审计的工作原理
作为运维操作审计手段的堡垒机的核心功能是用于实现对运维操作人员的权限控制与操作行为审计。1、主要技术思路
如何实现对运维人员的权限控制与审计呢？堡垒机必须能够截获运维人员的操作，并能够分析出其操作的内容。堡垒机的部署方式，确保它能够截获运维人员的所有操作行为，分析出其中的操作内容以实现权限控制和行为审计的目的，同时堡垒机还采用了应用代理的技术。运维审计型堡垒机对于运维操作人员相当于一台代理服务器(Proxy Server)，其工作流程示意图如下所示：
- []运维人员在操作过程中首先连接到堡垒机，然后向堡垒机提交操作请求;[/][]该请求通过堡垒机的权限检查后，堡垒机的应用代理模块将代替用户连接到目标设备完成该操作，之后目标设备将操作结果返回给堡垒机，最后堡垒机再将操作结果返回给运维操作人员。[/]
通过这种方式，堡垒机逻辑上将运维人员与目标设备隔离开来，建立了从“运维人员->堡垒机用户账号->授权->目标设备账号->目标设备”的管理模式，解决操作权限控制和行为审计问题的同时，也解决了加密协议和图形协议等无法通过协议还原进行审计的问题。2、工作原理简介
下面就简单介绍一下堡垒机运维操作审计的工作原理，其工作原理示意图如下：
在实际使用场景中堡垒机的使用人员通常可分为管理人员、运维操作人员、审计人员三类用户。
管理员最重要的职责是根据相应的安全策略和运维人员应有的操作权限来配置堡垒机的安全策略。堡垒机管理员登录堡垒机后，在堡垒机内部，“策略管理”组件负责与管理员进行交互，并将管理员输入的安全策略存储到堡垒机内部的策略配置库中。
"应用代理"组件是堡垒机的核心，负责中转运维操作用户的操作并与堡垒机内部其他组件进行交互。"应用代理"组件收到运维人员的操作请求后调用“策略管理”组件对该操作行为进行核查，核查依据便是管理员已经配置好的策略配置库，如此次操作不符合安全策略“应用代理”组件将拒绝该操作行为的执行。
运维人员的操作行为通过"策略管理"组件的核查之后"应用代理"组件则代替运维人员连接目标设备完成相应操作，并将操作返回结果返回给对应的运维操作人员;同时此次操作过程被提交给堡垒机内部的"审计模块"，然后此次操作过程被记录到审计日志数据库中。
最后当需要调查运维人员的历史操作记录时，由审计员登录堡垒机进行查询，然后“审计模块”从审计日志数据库中读取相应日志记录并展示在审计员交互界面上。
如何选择一款好的堡垒机产品
对于信息系统的管理者来说除了工作原理以外可能更关心如何选择一款好的运维审计堡垒机产品。一个好的运维审计堡垒机产品应实现对服务器、网络设备、安全设备等核心资产的运维管理账号的集中账号管理、集中认证和授权，通过单点登录，提供对操作行为的精细化管理和审计，达到运维管理简单、方便、可靠的目的。1、管理方便
应提供一套简单直观的账号管理、授权管理策略，管理员可快速方便地查找某个用户，查询修改访问权限;同时用户能够方便的通过登录堡垒机对自己的基本信息进行管理，包括账号、口令等进行修改更新。2、可扩展性
当进行新系统建设或扩容时，需要增加新的设备到堡垒机时，系统应能方便的增加设备数量和设备种类。3、精细审计
针对传统网络安全审计产品无法对通过加密、图形运维操作协议进行为审计的缺陷，系统应能实现对RDP、VNC、X-Window、SSH、SFTP、HTTPS等协议进行集中审计，提供对各种操作的精细授权管理和实时监控审计。4、审计可查
可实时监控和完整审计记录所有维护人员的操作行为;并能根据需求，方便快速的查找到用户的操作行为日志，以便追查取证。5、安全性
堡垒机自身需具备较高的安全性，须有冗余、备份措施，如日志自动备份等6、部署方便
系统采用物理旁路，逻辑串联的模式，不需要改变网络拓扑结构，不需要在终端安装客户端软件，不改变管理员、运维人员的操作习惯，也不影响正常业务运行。
总结
上面简要分析了堡垒机的概念以及其运维操作审计的主要工作原理。随着信息安全的快速发展，来自内部的安全威胁日益增多，综合防护、内部威胁防护等思想越来越受到重视，而各个层面的政策合规，如“萨班斯法案”、“信息系统等级保护”等等也纷纷对运维人员的操作行为审计提出明确要求。堡垒机作为运维安全审计产品将成为信息系统安全的最后一道防线，其作用也将越来越重要，应用范围势必会快速扩展到各个行业的信息系统。因此在当前的形势之下，让大家更加清楚的了解堡垒机也就十分必要了。
上G大文件双机互传工具BBCP
chris 发表了文章 0 个评论 4738 次浏览 2016-01-27 11:52
原由
局域网双机拷贝单个大文件 【200G大小】，不要问我是啥！ 也不要问我为毛会生成那么大的单文件，事实就是这样！然后就开始了操蛋之旅！再次做下记录备忘！
方法尝试对比
方式一：s ...查看全部
原由
局域网双机拷贝单个大文件 【200G大小】，不要问我是啥！ 也不要问我为毛会生成那么大的单文件，事实就是这样！然后就开始了操蛋之旅！再次做下记录备忘！
方法尝试对比
方式一：scp
什么是scp: scp 命令是 SSH中最方便有用的命令了，scp就是secure copy，是用来进行远程文件拷贝的。数据传输使用 ssh，并且和ssh 使用相同的认证方式，提供相同的安全保证。 与rcp 不同的是，scp 在需要进行验证时会要求你输入密码或口令。方式二：rsync
速度：刚开始的时候33M/s 持续3分钟左右就跌落到3M左右的传输速度
什么是rsync: rsync是rcp的替代品之一，rsync 是一款高效的远程数据备份和镜象工具，方式三：wget
速度：无响应
什么是wget: wget 是一个经由 GPL 许可的可从网络上自动获取文件的自由软件包。它是一个非交互式的命令行工具。支持 HTTP，HTTPS 和 FTP 协议，支持代理服务器以及断点续传功能。 wget 可实现递归下载，即可跟踪 HTML 页面上的链接依次下载来创建远程服务器的本地版本，完全重建原始站点的目录结构，实现远程网站的镜像。在递归下载时，wget 将页面中的超级链接转换成指向本地文件，方便离线浏览。由于非交互特性，wget 支持后台运行，用户在退出系统后，仍可继续运行。功能强大，设置方便简单。方式四：bbcp
速度：刚开始的时候50M/s 持续3分钟左右就跌落到3M左右的传输速度
什么是bbcp: bbcp 是由SLAC(斯坦福直线加速器中心)的Andy Hanushevsky创立的点对点网络文件拷贝工具。经过简单测试，发现速度比 scp 快了10倍左右，因此推荐大家采用bbcp来取代scp等老家伙 :)附图为2G文件的传输速度：
速度：针对20G的文件进行了测试，测试下来平均下来速度在21M左右，耗时16分钟
总结
不同的应用场景使用不同的工具，单个大文件个人感觉bbcp还是极好极好的！安装bbcp【两端都要安装】
wget http://www.slac.stanford.edu/~abh/bbcp/bin/amd64_rhel60/bbcp -O /usr/bin/bbcp来自http://heylinux.com/archives/2984.html的中文参数解释：
chmod +x /usr/bin/bbcp
-k 保留所有未传输完成的文件，并允许在重试时进行覆盖参考文档：
-a 保留checkpoint信息用于校验文件的完整性
-r 递归传输指定路径下的所有文件
-P 2 每两秒显示传输的进程
-V 打印调试信息
-f 强制清除远程主机上传输失败的数据
-w 设置Disk (I/O) buffers
算法为(window = netspeed/8[i]RTT = 1000Mb/8[/i]74ms = 1000/1000/8*74 = 9.25 M)
对应链接：http://www.slac.stanford.edu/~abh/bbcp/#_Toc332986061
-s 16 设置并发数为16
参考官方建议：http://www.slac.stanford.edu/~abh/bbcp/#_Streams_(-s)
-T "ssh -x -a -p 2222 -oFallBackToRsh=no -i /home/dong.guo/.ssh/id_rsa -l heydevops heylinux.com /usr/bin/bbcp"
指定远端主机的认证方式：
采用-p 2222指定端口；
设置-oFallBackToRsh=no减少ssh响应时间；
设置-i /home/dong.guo/.ssh/id_rsa指定SSH Key；
设置-l heydevops指定登陆用户；
heylinux.com为远程主机地址；
/usr/bin/bbcp为远程主机的bbcp路径；
http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm
http://heylinux.com/archives/2984.html
http://imysql.cn/2008_12_08_using_bbcp_instead_scp
http://linux.cn/article-4527-1-rss.html
http://teachmyself.blog.163.com/blog/static/188814229201242314917237/
阅读分享原文：http://www.dwz.cn/2D55vI
nginx: [warn] cloud not build optimal proxy_headers_hash
being 回复了问题 2 人关注 2 个回复 6839 次浏览 2016-01-21 22:36
nfs挂载错误mount: wrong fs type, bad option, bad superblock
回复being 回复了问题 1 人关注 1 个回复 5296 次浏览 2016-01-13 18:50
大型网站系统架构演化之路
being 发表了文章 0 个评论 3338 次浏览 2016-01-10 16:26
前言
一个成熟的大型网站（如淘宝、天猫、腾讯等）的系统架构并不是一开始设计时就具备完整的高性能、高可用、高伸缩等特性的，它是随着用户量的增加，业务功能的扩展逐渐演变完善的，在这个过程中，开发模式、技术架构、设计思想也发生了很大的变化， ...查看全部
前言
一个成熟的大型网站（如淘宝、天猫、腾讯等）的系统架构并不是一开始设计时就具备完整的高性能、高可用、高伸缩等特性的，它是随着用户量的增加，业务功能的扩展逐渐演变完善的，在这个过程中，开发模式、技术架构、设计思想也发生了很大的变化，就连技术人员也从几个人发展到一个部门甚至一条产品线。所以成熟的系统架构是随着业务的扩展而逐步完善的，并不是一蹴而就；不同业务特征的系统，会有各自的侧重点，例如淘宝要解决海量的商品信息的搜索、下单、支付；例如腾讯要解决数亿用户的实时消息传输；百度它要处理海量的搜索请求；他们都有各自的业务特性，系统架构也有所不同。尽管如此我们也可以从这些不同的网站背景下，找出其中共用的技术，这些技术和手段广泛运用在大型网站系统的架构中，下面就通过介绍大型网站系统的演化过程，来认识这些技术和手段。
一、最开始的网站架构
最初的架构，应用程序、数据库、文件都部署在一台服务器上，如图：
二、应用、数据、文件分离
随着业务的扩展，一台服务器已经不能满足性能需求，故将应用程序、数据库、文件各自部署在独立的服务器上，并且根据服务器的用途配置不同的硬件，达到最佳的性能效果。
三、利用缓存改善网站性能
在硬件优化性能的同时，同时也通过软件进行性能优化，在大部分的网站系统中，都会利用缓存技术改善系统的性能，使用缓存主要源于热点数据的存在，大部分网站访问都遵循28原则（即80%的访问请求，最终落在20%的数据上），所以我们可以对热点数据进行缓存，减少这些数据的访问路径，提高用户体验。
缓存实现常见的方式是本地缓存、分布式缓存。当然还有CDN、反向代理等，这个后面再讲。本地缓存，顾名思义是将数据缓存在应用服务器本地，可以存在内存中，也可以存在文件，OSCache就是常用的本地缓存组件。本地缓存的特点是速度快，但因为本地空间有限所以缓存数据量也有限。分布式缓存的特点是，可以缓存海量的数据，并且扩展非常容易，在门户类网站中常常被使用，速度按理没有本地缓存快，常用的分布式缓存是Memcached、Redis。
四、使用集群改善应用服务器性能
应用服务器作为网站的入口，会承担大量的请求，我们往往通过应用服务器集群来分担请求数。应用服务器前面部署负载均衡服务器调度用户请求，根据分发策略将请求分发到多个应用服务器节点。
常用的负载均衡技术硬件的有F5，价格比较贵，软件的有LVS、Nginx、HAProxy。LVS是四层负载均衡，根据目标地址和端口选择内部服务器，Nginx和HAProxy是七层负载均衡，可以根据报文内容选择内部服务器，因此LVS分发路径优于Nginx和HAProxy，性能要高些，而Nginx和HAProxy则更具配置性，如可以用来做动静分离（根据请求报文特征，选择静态资源服务器还是应用服务器）。
五、数据库读写分离和分库分表
随着用户量的增加，数据库成为最大的瓶颈，改善数据库性能常用的手段是进行读写分离以及分库分表，读写分离顾名思义就是将数据库分为读库和写库，通过主备功能实现数据同步。分库分表则分为水平切分和垂直切分，水平切分则是对一个数据库特大的表进行拆分，例如用户表。垂直切分则是根据业务的不同来切分，如用户业务、商品业务相关的表放在不同的数据库中。
六、使用CDN和反向代理提高网站性能
假如我们的服务器都部署在成都的机房，对于四川的用户来说访问是较快的，而对于北京的用户访问是较慢的，这是由于四川和北京分别属于电信和联通的不同发达地区，北京用户访问需要通过互联路由器经过较长的路径才能访问到成都的服务器，返回路径也一样，所以数据传输时间比较长。对于这种情况，常常使用CDN解决，CDN将数据内容缓存到运营商的机房，用户访问时先从最近的运营商获取数据，这样大大减少了网络访问的路径。比较专业的CDN运营商有蓝汛、网宿。
而反向代理，则是部署在网站的机房，当用户请求达到时首先访问反向代理服务器，反向代理服务器将缓存的数据返回给用户，如果没有缓存数据才会继续访问应用服务器获取，这样做减少了获取数据的成本。反向代理有Squid，Nginx。
七、使用分布式文件系统
用户一天天增加，业务量越来越大，产生的文件越来越多，单台的文件服务器已经不能满足需求，这时就需要分布式文件系统的支撑。常用的分布式文件系统有GFS、HDFS、TFS。
八、使用NoSql和搜索引擎
对于海量数据的查询和分析，我们使用nosql数据库加上搜索引擎可以达到更好的性能。并不是所有的数据都要放在关系型数据中。常用的NOSQL有mongodb、hbase、redis，搜索引擎有lucene、solr、elasticsearch。
九、将应用服务器进行业务拆分
随着业务进一步扩展，应用程序变得非常臃肿，这时我们需要将应用程序进行业务拆分，如百度分为新闻、网页、图片等业务。每个业务应用负责相对独立的业务运作。业务之间通过消息进行通信或者共享数据库来实现。
十、搭建分布式服务
这时我们发现各个业务应用都会使用到一些基本的业务服务，例如用户服务、订单服务、支付服务、安全服务，这些服务是支撑各业务应用的基本要素。我们将这些服务抽取出来利用分部式服务框架搭建分布式服务。阿里的Dubbo是一个不错的选择。
总结
大型网站的架构是根据业务需求不断完善的，根据不同的业务特征会做特定的设计和考虑，本文只是讲述一个常规大型网站会涉及的一些技术和手段。
分享阅读整理原文：http://www.cnblogs.com/leefreeman/p/3993449.html
参考书籍：《大型网站技术架构》《海量运维运营规划》
十条命令一分钟分析出Linux服务器性能
push 发表了文章 0 个评论 3172 次浏览 2016-01-09 20:47
如果你的Linux服务器突然负载暴增，告警短信快发爆你的手机，如何在最短时间内找出Linux性能问题所在？下面让我们看看看Neflix通过十条命令在一分钟内对机器性能问题进行诊断。
概述
通过执行以下命令，可 ...查看全部
如果你的Linux服务器突然负载暴增，告警短信快发爆你的手机，如何在最短时间内找出Linux性能问题所在？下面让我们看看看Neflix通过十条命令在一分钟内对机器性能问题进行诊断。
通过执行以下命令，可以在1分钟内对系统资源使用情况有个大致的了解。
TCP连接数可以用来判断性能问题是否由于建立了过多的连接，进一步可以判断是主动发起的连接，还是被动接受的连接。TCP重传可能是因为网络环境恶劣，或者服务器压力过大导致丢包。
但是，top命令相对于前面一些命令，输出是一个瞬间值，如果不持续盯着，可能会错过一些线索。这时可能需要暂停top命令刷新，来记录和比对数据。
排查Linux服务器性能问题还有很多工具，上面介绍的一些命令，可以帮助我们快速的定位问题。例如前面的示例输出，多个证据证明有JAVA进程占用了大量CPU资源，之后的性能调优就可以针对应用程序进行。
概述
通过执行以下命令，可以在1分钟内对系统资源使用情况有个大致的了解。
- []uptime[/][]dmesg | tail[/][]vmstat 1[/][]mpstat -P ALL 1[/][]pidstat 1[/][]iostat -xz 1[/][]free -m[/][]sar -n DEV 1[/][]sar -n TCP,ETCP 1[/][]top[/]
uptime
$ uptime23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02这个命令可以快速查看机器的负载情况。在Linux系统中，这些数据表示等待CPU资源的进程和阻塞在不可中断IO进程（进程状态为D）的数量。这些数据可以让我们对系统资源使用有一个宏观的了解。命令的输出分别表示1分钟、5分钟、15分钟的平均负载情况。通过这三个数据，可以了解服务器负载是在趋于紧张还是区域缓解。如果1分钟平均负载很高，而15分钟平均负载很低，说明服务器正在命令高负载情况，需要进一步排查CPU资源都消耗在了哪里。反之，如果15分钟平均负载很高，1分钟平均负载较低，则有可能是CPU资源紧张时刻已经过去。上面例子中的输出，可以看见最近1分钟的平均负载非常高，且远高于最近15分钟负载，因此我们需要继续排查当前系统中有什么进程消耗了大量的资源。可以通过下文将会介绍的vmstat、mpstat等命令进一步排查。
dmesg | tail
$ dmesg | tail[1880957.563150] perl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0[...][1880957.563400] Out of memory: Kill process 18694 (perl) score 246 or sacrifice child[1880957.563408] Killed process 18694 (perl) total-vm:1972392kB, anon-rss:1953348kB, file-rss:0kB[2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request. Check SNMP counters.该命令会输出系统日志的最后10行。示例中的输出，可以看见一次内核的oom kill和一次TCP丢包。这些日志可以帮助排查性能问题。千万不要忘了这一步。
vmstat 1
$ vmstat 1procs ---------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st34 0 0 200889792 73708 591828 0 0 0 5 6 10 96 1 3 0 032 0 0 200889920 73708 591860 0 0 0 592 13284 4282 98 1 1 0 032 0 0 200890112 73708 591860 0 0 0 0 9501 2154 99 1 0 0 032 0 0 200889568 73712 591856 0 0 0 48 11900 2459 99 0 0 0 032 0 0 200890208 73712 591860 0 0 0 0 15898 4840 98 1 1 0 0^Cvmstat(8) 命令，每行会输出一些系统核心指标，这些指标可以让我们更详细的了解系统状态。后面跟的参数1，表示每秒输出一次统计信息，表头提示了每一列的含义，这几介绍一些和性能调优相关的列：
- []r：等待在CPU资源的进程数。这个数据比平均负载更加能够体现CPU负载情况，数据中不包含等待IO的进程。如果这个数值大于机器CPU核数，那么机器的CPU资源已经饱和。[/][]free：系统可用内存数（以千字节为单位），如果剩余内存不足，也会导致系统性能问题。下文介绍到的free命令，可以更详细的了解系统内存的使用情况。[/][]si, so：交换区写入和读取的数量。如果这个数据不为0，说明系统已经在使用交换区（swap），机器物理内存已经不足。[/][]us, sy, id, wa, st：这些都代表了CPU时间的消耗，它们分别表示用户时间（user）、系统（内核）时间（sys）、空闲时间（idle）、IO等待时间（wait）和被偷走的时间（stolen，一般被其他虚拟机消耗）。[/]
mpstat -P ALL 1
$ mpstat -P ALL 1Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)07:38:49 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle07:38:50 PM all 98.47 0.00 0.75 0.00 0.00 0.00 0.00 0.00 0.00 0.7807:38:50 PM 0 96.04 0.00 2.97 0.00 0.00 0.00 0.00 0.00 0.00 0.9907:38:50 PM 1 97.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 2.0007:38:50 PM 2 98.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 1.0007:38:50 PM 3 96.97 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 3.03[...]该命令可以显示每个CPU的占用情况，如果有一个CPU占用率特别高，那么有可能是一个单线程应用程序引起的。pidstat 1
$ pidstat 1Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)07:41:02 PM UID PID %usr %system %guest %CPU CPU Command07:41:03 PM 0 9 0.00 0.94 0.00 0.94 1 rcuos/007:41:03 PM 0 4214 5.66 5.66 0.00 11.32 15 mesos-slave07:41:03 PM 0 4354 0.94 0.94 0.00 1.89 8 java07:41:03 PM 0 6521 1596.23 1.89 0.00 1598.11 27 java07:41:03 PM 0 6564 1571.70 7.55 0.00 1579.25 28 java07:41:03 PM 60004 60154 0.94 4.72 0.00 5.66 9 pidstat07:41:03 PM UID PID %usr %system %guest %CPU CPU Command07:41:04 PM 0 4214 6.00 2.00 0.00 8.00 15 mesos-slave07:41:04 PM 0 6521 1590.00 1.00 0.00 1591.00 27 java07:41:04 PM 0 6564 1573.00 10.00 0.00 1583.00 28 java07:41:04 PM 108 6718 1.00 0.00 0.00 1.00 0 snmp-pass07:41:04 PM 60004 60154 1.00 4.00 0.00 5.00 9 pidstat^Cpidstat命令输出进程的CPU占用率，该命令会持续输出，并且不会覆盖之前的数据，可以方便观察系统动态。如上的输出，可以看见两个JAVA进程占用了将近1600%的CPU时间，既消耗了大约16个CPU核心的运算资源。
iostat -xz 1
$ iostat -xz 1Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)avg-cpu: %user %nice %system %iowait %steal %idle 73.96 0.00 3.73 0.03 0.06 22.21Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %utilxvda 0.00 0.23 0.21 0.18 4.52 2.08 34.37 0.00 9.98 13.80 5.42 2.44 0.09xvdb 0.01 0.00 1.02 8.94 127.97 598.53 145.79 0.00 0.43 1.78 0.28 0.25 0.25xvdc 0.01 0.00 1.02 8.86 127.79 595.94 146.50 0.00 0.45 1.82 0.30 0.27 0.26dm-0 0.00 0.00 0.69 2.32 10.47 31.69 28.01 0.01 3.23 0.71 3.98 0.13 0.04dm-1 0.00 0.00 0.00 0.94 0.01 3.78 8.00 0.33 345.84 0.04 346.81 0.01 0.00dm-2 0.00 0.00 0.09 0.07 1.35 0.36 22.50 0.00 2.55 0.23 5.62 1.78 0.03[...]^Ciostat命令主要用于查看机器磁盘IO情况。该命令输出的列，主要含义是：- []r/s, w/s, rkB/s, wkB/s：分别表示每秒读写次数和每秒读写数据量（千字节）。读写量过大，可能会引起性能问题。[/][]await：IO操作的平均等待时间，单位是毫秒。这是应用程序在和磁盘交互时，需要消耗的时间，包括IO等待和实际操作的耗时。如果这个数值过大，可能是硬件设备遇到了瓶颈或者出现故障。[/][]avgqu-sz：向设备发出的请求平均数量。如果这个数值大于1，可能是硬件设备已经饱和（部分前端硬件设备支持并行写入）。[/][]%util：设备利用率。这个数值表示设备的繁忙程度，经验值是如果超过60，可能会影响IO性能（可以参照IO操作平均等待时间）。如果到达100%，说明硬件设备已经饱和。[/]
free –m
$ free -m total used free shared buffers cachedMem: 245998 24545 221453 83 59 541-/+ buffers/cache: 23944 222053Swap: 0 0 0free命令可以查看系统内存的使用情况，-m参数表示按照兆字节展示。最后两列分别表示用于IO缓存的内存数，和用于文件系统页缓存的内存数。需要注意的是，第二行-/+ buffers/cache，看上去缓存占用了大量内存空间。这是Linux系统的内存使用策略，尽可能的利用内存，如果应用程序需要内存，这部分内存会立即被回收并分配给应用程序。因此，这部分内存一般也被当成是可用内存。如果可用内存非常少，系统可能会动用交换区（如果配置了的话），这样会增加IO开销（可以在iostat命令中提现），降低系统性能。
sar -n DEV 1
$ sar -n DEV 1Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)12:16:48 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil12:16:49 AM eth0 18763.00 5032.00 20686.42 478.30 0.00 0.00 0.00 0.0012:16:49 AM lo 14.00 14.00 1.36 1.36 0.00 0.00 0.00 0.0012:16:49 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.0012:16:49 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil12:16:50 AM eth0 19763.00 5101.00 21999.10 482.56 0.00 0.00 0.00 0.0012:16:50 AM lo 20.00 20.00 3.25 3.25 0.00 0.00 0.00 0.0012:16:50 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00^Csar命令在这里可以查看网络设备的吞吐率。在排查性能问题时，可以通过网络设备的吞吐量，判断网络设备是否已经饱和。如示例输出中，eth0网卡设备，吞吐率大概在22 Mbytes/s，既176 Mbits/sec，没有达到1Gbit/sec的硬件上限。
sar -n TCP,ETCP 1
$ sar -n TCP,ETCP 1Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)12:17:19 AM active/s passive/s iseg/s oseg/s12:17:20 AM 1.00 0.00 10233.00 18846.0012:17:19 AM atmptf/s estres/s retrans/s isegerr/s orsts/s12:17:20 AM 0.00 0.00 0.00 0.00 0.0012:17:20 AM active/s passive/s iseg/s oseg/s12:17:21 AM 1.00 0.00 8359.00 6039.0012:17:20 AM atmptf/s estres/s retrans/s isegerr/s orsts/s12:17:21 AM 0.00 0.00 0.00 0.00 0.00^Csar命令在这里用于查看TCP连接状态，其中包括：
- []active/s：每秒本地发起的TCP连接数，既通过connect调用创建的TCP连接；[/][]passive/s：每秒远程发起的TCP连接数，即通过accept调用创建的TCP连接；[/][]retrans/s：每秒TCP重传数量；[/]
TCP连接数可以用来判断性能问题是否由于建立了过多的连接，进一步可以判断是主动发起的连接，还是被动接受的连接。TCP重传可能是因为网络环境恶劣，或者服务器压力过大导致丢包。
top
$ toptop命令包含了前面好几个命令的检查的内容。比如系统负载情况（uptime）、系统内存使用情况（free）、系统CPU使用情况（vmstat）等。因此通过这个命令，可以相对全面的查看系统负载的来源。同时，top命令支持排序，可以按照不同的列排序，方便查找出诸如内存占用最多的进程、CPU占用率最高的进程等。
top - 00:15:40 up 21:56, 1 user, load average: 31.09, 29.87, 29.92
Tasks: 871 total, 1 running, 868 sleeping, 0 stopped, 2 zombie
%Cpu(s): 96.8 us, 0.4 sy, 0.0 ni, 2.7 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 25190241+total, 24921688 used, 22698073+free, 60448 buffers
KiB Swap: 0 total, 0 used, 0 free. 554208 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20248 root 20 0 0.227t 0.012t 18748 S 3090 5.2 29812:58 java
4213 root 20 0 2722544 64640 44232 S 23.5 0.0 233:35.37 mesos-slave
66128 titancl+ 20 0 24344 2332 1172 R 1.0 0.0 0:00.07 top
5235 root 20 0 38.227g 547004 49996 S 0.7 0.2 2:02.74 java
4299 root 20 0 20.015g 2.682g 16836 S 0.3 1.1 33:14.42 java
1 root 20 0 33620 2920 1496 S 0.0 0.0 0:03.82 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:05.35 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:06.94 kworker/u256:0
8 root 20 0 0 0 0 S 0.0 0.0 2:38.05 rcu_sched
但是，top命令相对于前面一些命令，输出是一个瞬间值，如果不持续盯着，可能会错过一些线索。这时可能需要暂停top命令刷新，来记录和比对数据。
总结
排查Linux服务器性能问题还有很多工具，上面介绍的一些命令，可以帮助我们快速的定位问题。例如前面的示例输出，多个证据证明有JAVA进程占用了大量CPU资源，之后的性能调优就可以针对应用程序进行。
英文原文：http://techblog.netflix.com/2015/11/linux-performance-analysis-in-60s.html
翻译原文：http://www.infoq.com/cn/news/2015/12/linux-performance
