CentOS升级Git

Git现在的版本(我在写下本文时)已经是1.7.12了,然而CentOS的Git的版本却是1.7.1,而且用yum安装的Git的最高版本也只是去1.7.1,当然,如果你在工作使用中没有遇到问题,使用这个版本当然没有什么问题,但是如果你在工作中遇到只有高版本的Git才能支持的任务时,如何升级我们的Git呢?事实上,GitHub和许多Git服务依赖的Git版本不低于1.7.2。下面就以CentOS-6.5为例来说明,如何升级我们的Git。


一、安装证书
使用rpm的强大功能,从以下的地址中,导入安装所需要的证书,命令如下:

[plain] view plain copy

 print?在CODE上查看代码片派生到我的代码片

  1. # rpm –import http://apt.sw.be/RPM-GPG-KEY.dag.txt  

二、安装RPMForge
RPMForge源是什么呢?RPMForgeCentOS系统下的软件仓库,拥有4000多种的软件包,被CentOS社区认为是最安全也是最稳定的一个软件仓库。而CentOS默认自带CentOS-Base.repo源,但官方源中去除了很多有版权争议的软件,而且安装的软件也不是最新的稳定版。所以在这里,我们使用这个rpm软件仓库。其地址如下:

因为不同的CentOS版本的Git所对应的rpm包不同,所以在下载安装RPMForge时可先到该网站找到适合自己系统安装的RPMForgerpm。其地址如下:


因为我的CentOS是CentOS-6.5 32 位,所以我对应的rpm安装包就是:rpmforge-release-0.5.3-1.el6.rf.i686.rpm,所以可用以下命令来安装:

[plain] view plain copy

 print?在CODE上查看代码片派生到我的代码片

  1. # rpm -i http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.i686.rpm  
通过rpm的在线安装功能,我们也可以不下载rpm包,而直接在线安装

三、使用rpmforge-extra源更新
因为yum命令下载的软件依赖于其所使用的软件仓库,所以我们只要更改其指定的软件仓库,就能使用yum来方便地下载安装RPMForge源中的软件来更新本机的软件,从而简化安装操作。其命令如下:

[plain] view plain copy

 print?在CODE上查看代码片派生到我的代码片

  1. # yum –enablerepo=rpmforge-extras update  
你会看到由于软件仓库的切换,导致会有大量的软件可更新,你可以选择安装或不安装。若选择安装,则输入‘y’,那么当安装完成时,Git也就变为最新的版本了,我就是用这种方式的。但由于要更新的软件实在太多,所以,也可以选择只安装Git,输入了‘n’。

注:上面的命令其实与yum update是一样的,只是上面的命令指定更新对比的软件仓库为RPMForge。经过我的观察,选项–enablerepo=rpmforge-extras并不会改变yum的默认软件仓库,所以每次要想从下载软件,都需要该选项。要想一直使用第三方的源,应需要安装yum-priorities插件,并配置相关文件/etc/yum.repos.d/CentOS-Base.repo。(这里如有错误还望指出)

四、查看可用的git模块
由于我们并不知道,我们的系统可以安装哪些版本的Git,所以可用如下命令来查看,并选择一个最新版本的git来安装。其命令如下:

[cpp] view plain copy

 print?在CODE上查看代码片派生到我的代码片

  1. # yum –enablerepo=rpmforge-extras provides git  
五、安装Git
由于我们使用的是RPMForge的软件仓库,所以在安装时,如果没有运行上第四点的命令,而又想知道,自己的系统应该选择哪个版本来安装,我们可以到其仓库中找到我们版本所对应的Git,其地址如下:

由于我的是CentOS-6,所以最新的就是gitk-1.7.12.4-1.el6.rfx.i686.rpm了。

其命令如下:

[plain] view plain copy

 print?在CODE上查看代码片派生到我的代码片

  1. # yum –enablerepo=rpmforge-extras install gitk-1.7.12.4-1.el6.rfx.i686.rpm  
六、版本检查
至此,我们的Git已经升级好了,旧的Git会被新的覆盖,我们可以通过如下命令来查看,git的版本:

[plain] view plain copy

 print?在CODE上查看代码片派生到我的代码片

  1. # git –version  

[cpp] view plain copy

 print?在CODE上查看代码片派生到我的代码片

  1. # rpm -q git  

CentOS如何升级 Subversion (SVN) 1.8.15

感谢WANdisco,是维持最新的颠覆版的RPM包。这篇文章将帮助您安装Subversion(SVN)1.8.15 CentOS / RHEL 7 / 6 / 5系统。如果要配置颠覆服务器访问本文。

Thanks to Wandisco, which is maintaining the rpm packages for latest Subversion version. This article will help you to Install Subversion 1.8.15 ( SVN Client ) on CentOS/RHEL 7/6/5 Systems. If you want to configure Subversion server visit this article.

Step 1: Setup Yum Repository

首先,我们需要在我们的系统中配置yum仓库。创建一个新的回购文件/ etc / yum.repos.d/wandisco-svn.repo并添加以下内容按你的操作系统版本。

Firstly we need to configure yum repository in our system. Create a new repo file/etc/yum.repos.d/wandisco-svn.repo and add following content as per your operating system version.

[WandiscoSVN]
name=Wandisco SVN Repo
baseurl=http://opensource.wandisco.com/centos/$releasever/svn-1.8/RPMS/$basearch/
enabled=1
gpgcheck=0

Step 2: Install Subversion Package

Before installing latest package remove existing subversion packages from system to remove conflict.

在安装最新方案之前,从系统中删除现有的颠覆软件,以消除冲突。

# yum remove subversion*

Now install latest available Subversion package using yum command line package manager utility.现在安装新的颠覆包使用yum命令行软件包管理器。

# yum clean all
# yum install subversion

Step 3: Verify Subversion Version

At this stage you have successfully install Subversion client on your system. Lets use following command to verify version of svn client.在这个阶段,您已经成功地安装了系统的颠覆客户端。让我们用以下命令来验证SVN客户端版本。

# svn --version


svn, version 1.8.15 (r1718365)
   compiled Dec 11 2015, 14:28:48 on x86_64-redhat-linux-gnu

Copyright (C) 2015 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository access (RA) modules are available:

* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
  - using serf 1.3.7
  - handles 'http' scheme
  - handles 'https' scheme

References: 
1. http://opensource.wandisco.com/

在Linux CentOS 6.6上升级Python 2.7.9

CentOS 6.6自带的是Python 2.6.6,而编译llvm需要Python 2.7以上,必须升级Python 

checking for python... /usr/bin/python
checking for python >= 2.7... not found
configure: error: found python 2.6.6 (/usr/bin/python); required >= 2.7

yum中最新的也是Python 2.6.6,只能下载Python 2.7.9的源代码自己编译安装。

操作步骤如下:

1)安装devtoolset

yum groupinstall "Development tools"

2)安装编译Python需要的包包

yum install zlib-devel
yum install bzip2-devel
yum install openssl-devel
yum install ncurses-devel
yum install sqlite-devel

3)下载并解压Python 2.7.9的源代码

cd /opt
wget --no-check-certificate https://www.python.org/ftp/python/2.7.9/Python-2.7.9.tar.xz
tar xf Python-2.7.9.tar.xz
cd Python-2.7.9

4)编译与安装Python 2.7.9

./configure --prefix=/usr/local
make && make altinstall

5)将python命令指向Python 2.7.9

ln -s /usr/local/bin/python2.7 /usr/local/bin/python

6)检查Python版本

sh
sh-4.1# python -V
Python 2.7.9

网站502与504错误分析及解决办法

不管你是做运维还是做开发,哪怕你是游客,时不时会遇到502 Bad Gateway或504 Gateway Time-out。出现这页面,把服务重启下,再实在不行重启下服务器,问题就解决了,但是,这问题还是会困扰着你,特别是做运维的人员。夜黑风高正酣睡时,一个电话响起,让你重启服务或IISRESET,肯定是极大不爽,立马要问候他妈了。呵呵,本文总结502与504故障分析与解决方法。

二. 状态码解释

502 Bad Gateway:作为网关或者代理工作的服务器尝试执行请求时,从上游服务器接收到无效的响应。

504 Gateway Time-out:作为网关或者代理工作的服务器尝试执行请求时,未能及时从上游服务器(URI标识出的服务器,例如HTTP、FTP、LDAP)或者辅助服务器(例如DNS)收到响应。

三. 502 Bad Gateway原因分析

将请求提交给网关如php-fpm执行,但是由于某些原因没有执行完毕导致php-fpm进程终止执行。说到此,这个问题就很明了了,与网关服务如php-fpm的配置有关了。

php-fpm.conf配置文件中有两个参数就需要你考虑到,分别是max_children和request_terminate_timeout。

max_children最大子进程数,在高并发请求下,达到php-fpm最大响应数,后续的请求就会出现502错误的。可以通过netstat命令来查看当前连接数。

request_terminate_timeout设置单个请求的超时终止时间。还应该注意到php.ini中的max_execution_time参数。当请求终止时,也会出现502错误的。

当积累了大量的php请求,你重启php-fpm释放资源,但一两分钟不到,502又再次呈现,这是什么原因导致的呢? 这时还应该考虑到数据库,查看下数据库进程是否有大量的locked进程,数据库死锁导致超时,前端终止了继续请求,但是SQL语句还在等待释放锁,这时就要重启数据库服务了或kill掉死锁SQL进程了。

对于长时间的请求可以考虑使用异步方式,可以参阅《关于PHP实现异步操作的研究》。

四. 504 Gateway Time-out原因分析

504错误一般是与nginx.conf配置有关了。主要与以下几个参数有关:fastcgi_connect_timeout、fastcgi_send_timeout、fastcgi_read_timeout、fastcgi_buffer_size、fastcgi_buffers、fastcgi_busy_buffers_size、fastcgi_temp_file_write_size、fastcgi_intercept_errors。特别是前三个超时时间。如果fastcgi缓冲区太小会导致fastcgi进程被挂起从而演变为504错误。

五. 小结

总而言之,502错误主要从四个方向入手:

1. max_children

2. request_terminate_timeout、max_execution_time

3. 数据库

4. 网关服务是否启动如php-fpm

504错误主要查看nginx.conf关于网关如fastcgi的配置。

Akamai面临大客户危机?“自建”趋势冲击下的CDN案例

近日,国际具有强大影响力的互联网基础设施服务提供商Akamai在其季度财报会上,给投资商发出警告,提醒其未来Akamai CDN业务的两个核心客户,Apple以及Microsoft将会出现业务量下滑,并将直接影响到Akamai作为CDN服务提供商的商业情况,而据Akamai CEO Tom Leighton称,这些都是“自建”惹的祸。

QQ截图20160219141902.jpg

苹果在Maiden自建的数据中心

在季度财报会上,Tom Leighton向投资者警示这一消息,“在过去的两年时间里,Akamai有两个核心的客户——“微软”和“苹果”,大约占到Akamai整体收入的13%。尽管随着媒体趋势的发展,苹果与微软依然会是Akamai最大的客户,但其对于Akamai收入的贡献将从原先的13%下降到6%。而这其中7%的变化,主要原因来自于互联网公司的‘自建’。”

苹果的自建CDN自2013年开始使用,基于ATS及时建造自己的CDN,于2014年7月开始承载自身业务的流量,并逐步将业务流量迂回,目前Akamai服务已经确认从iTunes的项目中移除,但似乎依然在支撑其Apple Music业务。

Apple,作为一家在全球范围内拥有数个数据中心,在云计算基础设备中投入超过数十亿的公司,其公开的声明以及公司的业务发展,使其完全有理由在CDN专项领域再投资1个亿(2016年规划),而这部分资金将有可能包含现有数据中心的软件开发以及存储空间的延展,同时也将用于互联网服务提供商之间的互联协议。

苹果和微软多年来一直都是Akamai客户列表中首要的核心客户,所以一旦由于某些原因使其对于Akamai不再依赖,那么对于Akamai来说业务将会受到严重的冲击。而祸不单行的是,另一方面,Akamai已经在面临Amazon的激烈竞争。为了寻找其新的生长空间,其不得不在信息安全领域获得其稳定的发展方向。

从Akamai公布2015年第四季度与全年财报看CDN行业变化

Akamai作为内容分发网络(CDN)的全球领导者,于2月9日正式公布了截止至2015年12月31日的第四季度及全年财务业绩,这对于国内不少参考国际领先CDN运营商运营策略的从业者也是重要的参考依据。在其季度与年度财报会上,Akamai的CEO Tom Leighton也向投资商发出警告,提醒其未来Akamai CDN的核心业务,可能会由于Apple以及Microsoft通过自建将流量渐渐掌控,而影响到其业绩,但总体来说,2015年,Akamai收入稳中有升,转型安全与性能、增值服务的策略初见成功,而面对的挑战也让其必须谨慎对待。

QQ截图20160219134445.jpg

单从Akamai第四季度的收入来看,有明显上升,达到5.79亿美金,同比年增长率超过8%,每股收益均摊为0.49美金,同比下降9%,而此前分析师在第四季度预测的是5.68亿美金,每股收益0.62美金,基本超出预期。综合全年,Akamai在2015年收益达到22亿美金,同比增长12%,每股收益均摊为1.78美金,同比下降3%。

对此,Akamai的CEO Tom Leighton表示基本满意,“Akamai坚实的表现为2015年做了一个压轴的结尾,由于年末节日消费季的出现,让收益在第四季度有了稳步的增长,同时云安全服务的快速成长也成为2015年第四季度取得成绩的原因。目前Akamai的安全业务相比去年同期已经有了50%的增长,目前也已实现近3亿美金的年化运营率。”

在CDN领域具有领导者地位的Akamai目前市值预估有67亿美金,其竞争对手,包括VeriSign、Red Hat、Level3等市值均在77亿美金、109亿美金以及143亿美金。

QQ截图20160219134530.jpg

如果单独将业务拆分来看,同样在第四季度,Akamai的视频传输技术解决方案在2015年第四季度同比下滑2%,但在整个2015年依然上升7%,尽管外汇比率的变化可能是其中一个比较重要的原因,但在媒体传输解决方案上,Akamai依然需要保持一个谨慎的态度,尤其当其重要的客户Appl、Microsoft已经开始将流量逐步转移到自身的CDN中。

分析师认为,从长期来看,一些互联网公司诸如Netflix与Alphabet都希望将流量掌控在自己的网络上,这点从互联网企业2016年上浮的技术预算投入就能揣测出其意图,而Amazon入局CDN市场也同时给Akamai带来不少的挑战。当然建立内部网的成本巨大,中小型客户依然会是Akamai重要的客户来源,但是否能从中填补大客户流失带来的损失,目前尚不可知。

QQ截图20160219134604.jpg

另一方面,在面对挑战的同时,Akamai也致力于努力转型,在2015年第四季度云安全解决方案收益同比增长46%,增长至7300万美金,全年同比增长50%达到2.54亿美金。Akamai第四季度总体性能与安全解决方案收益同比上涨16%,达到2.86亿美金,全年收益增长至10.5亿美金,同比增长17%。

Akamai的服务与支持解决方案同比增长18%,至4600万美金,全年达到1.7亿美金,同比16%。

针对于竞争对手的介入以及自建的趋势,Akamai日益将精力投入到发展新业务上,Akamai通过多项增值服务,包括针对性的广告以及基于云计算的业务,逐步将增值服务的收入提高到几乎能占到总收入的50%。

QQ截图20160219134630.jpg

尽管Akamai的研究与开发成本从2014年的6%上升至6.5%,但从毛利率来看,Akamai似乎并没有受到此影响,2015年第四季度的毛利率从2014年30.4%上升至33.4%,Akamai的营销以及市场成本保持在了20.5%,行政开支略有上升,达到17.3%,去年同期为16%。

Akamai还表示,其中这部分成本支出还要包括其为了网站与媒体业务部门的重心分配进行了重要业务的组织结构调整,在2015年第四季度,这部分的开支就达到了20万美金。于是从总体结果上来看,Akamai第四季度的运营利润率从25.4%同比下降到21.2%,净利润也从18.3%下降到15.3%,相比全年,Level3、RedHat、VeriSign分别净利润均为16%,15%与57%。

综上所述,Akamai作为全球CDN业务的领头羊,其转型的策略对于全球CDN服务提供商都有极为重要的借鉴意义,尽管面对大公司逐步自建内部网的腰斩,但增值服务与安全性能方案也成功顶住Akamai的半边天,为CDN服务提供了增值空间。

与此同时,互联网服务产业的发展也为Akamai提供了业绩上升的空间,但在不断上升的市场空间中,如何与传统IDC企业的入局形成差异化的产业特征,通过提供互联网用户更直接便捷,价格明晰的产品,也是CDN行业要面临的挑战。更重要的是,在DT时代,如何把握数据,整合数据,运用数据,对于传统单单只是将流量作为分发任务的CDN服务提供商同样是一项挑战。

2016年4月26~27日“第四届2016亚太CDN峰会”将于北京召开,作为每年聚焦IDC与CDN产业,从全球范围内聚合Akamai、网宿科技、Level3、腾讯云、阿里云、华为、中兴、各大运营商等IDC/CDN行业领袖的盛会,针对于2015年整个CDN市场的变革将出现的分享,也值得众人的期待。

迎接万亿级VR市场CDN布局要趁早

要问目前最火的黑科技是什么?当然非VR(VirtualReality)莫属。自从美国VPL公司创建人拉尼尔(Jaron Lanier)在上世纪80年代初提出虚拟现实技术以来,VR总是出现在前沿、未来的生活场景或是游戏体验中,并未真正走入人们的生活。

 

且看看来自互联网、IT的各路巨头对VR技术公司的投资和收购,或是建立自己的VR技术储备,都说明2016将成为VR技术的井喷年。“可能在很多人的眼里对于VR的理解,只是一个智能硬件或者是可穿戴设备,但作为CDN业内领先者的北京快网认为,继PC移动设备、智能电视后,VR或将成为下一屏个人终端内容集合平台!”北京快网副总经理严波如是说。

 

这一点显而易见。在年初的各大展会上,VR是绝对的主角。分析公司KZero数据表明,2015年全球VR终端设备的销量呈现上升趋势,2015年VR硬件设备的收入达到14亿美金,2016年将预计成长到21亿美金,2017年将达到24亿美金。

 

VR应用前景最被看好的领域则是游戏和社交。Facebook、Google、索尼、三星、任天堂相继在VR上的投入巨资,三星还刚刚建立了自己的VR实验室。玩家手中的牌越大,产业的爆发越迅速,而所需的配套设施也会越高。

 

当普通观众惊叹VR创造的各种身临其境神奇之感时,CDN从业者们却敏锐的发现VR对流量传输的高要求。

 

“许多VR厂商已经意识到流量、带宽对于自身发展是巨大的成本和难题。从业内最近的一些动作可以看出,VR厂商与CDN厂商之间的互动愈发频繁。”严波告诉记者。他口中所说的互动应是年前迅雷与大朋VR的投资和系列合作,这说明两个领域的企业都已经在互相试水了。

 

众所周知,3D视频或是VR游戏的上乘体验,都建立在巨大的存储和流畅的速度基础上。例如一个60帧的4K视频,每分钟就需要消耗约1GB至10GB的流量,一个20分钟的视频甚至需要100GB空间。要将这样大的文件传输并分发到用户手中,还要保证用户体验,想必只有CDN能帮到它。

 

“我们将这样的内容成为互联网的‘重应用’,因为无论从大小还是行动上来说,都跟那些轻巧的App或者轻视频有着天壤之别,凭借北京快网CloudCDN多年的技术积累和运营经验,能够让用户不必为了心仪的游戏缓冲等了又等,也不用再忍受视频开始前旋转的圆圈。”严波说。

 

的确,CDN能够让用户在任何地方从最近的节点找到想要的文件,从而保障VR游戏的交互感。由于CDN网络可以在多个节点进行数据的复制,以保障缓存数据可以接近100%传输给用户,所以即使某一地区或者服务器发生故障或者停电,其他的节点也可以自动接管负载,给平台提供了不同于单个数据中心的可靠性解决方案。

 

“目前国内主流CDN厂商都瞄上了VR的市场,无论是资本层面还是技术层面,都投入了相当大的资源,准备迎接VR的爆发。这既是CDN产业创新的契机,也是VR技术产业化和生态化的完善。”严波表示,北京快网已经率先在该领域内做好了相关技术的储备工作,稍加时日更加有针对性且较为完善的产品解决方案,将会融入到CloudCDN核心体系中。在VR产业风暴爆发前做好迎接万亿级市场的准备。

星域CDN给力助攻春晚 实现真正“同步直播”

央视刚刚公布了春晚大数据,最大的亮点莫过于多终端网络收视人数同比增长超4成,高达1.38亿人,堪称历史上同时观看人数最多的在线视频直播事件。而支持这场直播盛事的最大幕后功臣自然少不了网络加速工——各大CDN服务商们,不过,与往年不同的是,创新型专业CDN首次加入这支幕后推手行列中,并为春晚直播献上了最给力助攻。



作为央视春晚及多家地方台春晚的官方直播方之一,小米盒子正借助了战略合作伙伴、国内首个创新型专业CDN服务商——网心科技的星域CDN,成功为无数终端用户送上了零缓冲、零故障的高效优质直播服务。完全不同于传统CDN的“疲于应对”,革新性十足的后者可为小米盒子的用户们带去了“猴顺”、“猴快”的观看体验。

辟蹊径避拥堵骨干网无限节点助春晚“先睹为快”



春晚是中国人最重要的“年夜饭”,春晚直播本身创下最高在线观看人数不说,春节期间,抢红包、网络拜年等热门互动及各大社交平台也都创下了各自全年在线人数最高峰值,这个时候,容量有限的骨干网的压力可想而知。与传统CDN疲于挖掘骨干网带宽资源不同,星域CDN独创的无限节点模式独辟蹊径地绕开了拥挤的骨干网,盘活起数量更为庞大的个人节点网络,并最终实现视频直播最高效化。



星域CDN的最大杀手锏——无限节点技术在足够数量的骨干网节点基础上,布下几十万遍布全国个人家庭中的节点,在春晚直播期间,全新开辟了一条总量更庞大分布更均匀且数据传输距离近至1km的网络加速通道。配合星域CDN独创的星域调度技术,精准实时近距离调取数据,让用户观看春晚时,甚至实现自同一小区同一栋楼的邻居家中调动视频数据,以彻底实现春晚“先睹为快”。



此外,无限密布的节点加上就近数据调度,使得星域CDN帮助小米盒子实现了春晚直播全网延迟同步,每个小米盒子用户都可在第一时间收到同样的视频画面,真正同步观看直播。

多项创新绝技加身弱网下仍可极稳直播



事实上,星域CDN自去年中问世以来,就创下了业内最低直播延迟记录,视频等流媒体直播延迟均可低于2s。除无限节点和星域调度技术外,星域CDN可10倍提升流媒体传输效率与传输质量的弱网加速技术,又进一步保证了各种弱网环境下的直播流畅度,这让不少春节期间回偏僻乡村过年的用户们,也能在看春晚时避免缓冲及掉线烦恼。



值得一提的是,与传统CDN的“只管自家事儿”不同,星域CDN还主动通过采用业界领先的H.265技术,主动帮助客户“带宽大幅减少、流畅度翻倍”,实现视频直播、点播延时和卡顿率的大幅下降。



正是凭借强大的流媒体直播实力,尽管问世尚不到8个月,星域CDN已成为小米电视、小米盒子、爱奇艺等对传输速度、质量有苛刻要求的行业龙头的CDN服务商。而这个创新型专业CDN在今年春晚直播中的最抢眼“首演”,也为自身的2016年赢得了令人称道的开年好彩头。

您的企业的最佳选择:全球CDN还是数据中心?

企业如何规模化其在全球范围内的在线服务?在一般情况下,它们要么在企业所在地建立区域本地化的数据中心;要么则是采用全球内容分发网络(CDN)服务。

这种决策的制定需要权衡企业相关具体目标的可用资源。例如,一些目标可能需要加速动态内容,在亚洲建立电子商务;或是为欧洲用户减轻延迟或互动所需时间(TTI),或是减少全球的数据管理和安全成本费用。为达到成功,在线互联网企业必须对以下基本资源进行检查、测量,并适当分配。

预算

构建数据中心网络的相关建造和维护成本是相当昂贵的,一处占地面积约1000平方英尺的数据中心的耗资约160万美元。持续运营费用成本占到数据中心构建的65%左右。其他的费用包括消防安全,电力和冷却供应,寻找一个适当的地理位置,并获得相关建筑许可证,寻找一家专业的总承包商,以及相关的劳动力成本,包括扩充IT人员的成本。

而外包给CDN提供商并不需要很多的前期成本投入。即使从客户的立场出发,员工维护CDN的费用也大幅度减少,多余的费用可能需要用来培训现有的IT人员,以便通过服务提供商的云门户网站远程访问CDN。CDN服务的成本(和功能)会因CDN服务商的不同而有所不同,但它们通常都会是基于流量按月收取费用。其费用也要看具体的内容加速服务。静态内容站点大多会比全球优化的CDN更便宜。尽管静态站点可能更便宜,但应用程序交付网络(ADN)的加速动态内容则提供了更具吸引力的用户体验,并可能带来更广泛的站点使用。

时间

当涉及到内容加速选项时,时间作为资源拥有充足的方面。时间的投资回报率可能需要数年的数据中心构建;然而,在数据中心发展适当的基础设施,而不是选择CDN,能够允许企业显著控制内容分发的方式。这种控制来自于决策的制定,包括在哪里建立数据中心,可以控制内容的有效交付,提供尽可能最小的延迟性。由于内容分发网络和基础设施已经建成,时间的投资回报率被认为可以通过达到一个国家所选择的CDN支持而大大缩短。

企业需要综合考虑网站的性能KPI指标,如首字节时间(Time to First Byte,TTFB)和目标地区的TTI,来决定是否自建数据中心还是采用CDN。基础的性能,如一般性延迟是由数据发送起源地与目标地之间的距离、网络的拓扑结构、对等点,以及需要加速内容的类型等综合因素决定的。这个问题只有企业自身才能回答,基于独特的变量,企业自建数据中心是否要比采用外包的CDN让内容交付得更快?以及,这是否是一种可靠的方法?

可扩展性

选择外包的CDN和企业自建数据中心的网络规模均是可扩展的。然而,如上所述,全球CDN可以帮助企业更快的实现规模化扩展,因为其网络已经建立好了,并有能力处理尖峰时期的流量。当然,一些CDN较之本地数据中心可能在优化站点的某些SSL安全或SPDY功能方面有更多的困难。

无论企业选择采用哪种内容加速路径,网站本身的优化应该加速进行。利用CSS精灵,启用HTTP压缩,利用浏览器缓存等,保证内容不会经不必要的路径传递或为不必要的组件添加TTI。企业的规模越大,就越有可能因站点加载时间缓慢而影响企业营收。对于大型电子商务巨头亚马逊而言,他们就曾见证了网站加载每延迟100ms,销售下降了1%的惨痛局面。

服务器的安全性

企业对于安全性的维护对于其自身免受网络安全威胁,同时赢得消费者或客户对站点信任也是至关重要额。建立CDN 基础设施能够防止大规模的DDoS攻击、停机时间、网站崩溃和数据丢失。另一方面,企业网络全面的历史也提供了操作和维护企业最佳利益所需的内容。

尽管企业能够利用CDN洞察其数据的功能,决定不选择外包,并将控制权把握在自己手中。从理论上说,这无疑是非常严格的安全控制措施。现在的问题是企业是否能充分在不同的地理区域保持其服务器的安全,以抵御各具特色的安全和金融威胁。

文化联络人因素

如果进入某个具有不同的地域文化或母语的区域,企业需要有相关的文化联络人以便能够与当地的受众进行有效的沟通。如果企业没有在当地雇佣工作人员或已签约的人员,雇佣文化联系人以便了解如何开拓该市场,以及了解地方性的法规需要企业花费额外的费用。

当企业选择自建一处数据中心时,需要考虑利用文化资源,并与目标区域建立良好的关系。其预算必须包括雇佣联络人的成本以及在本地有影响力的网络推广的成本。而一些CDN提供商能够提供文化联络服务的内容或相关的应用程序交付加速。这可能会吸引一部分企业,由于其预先已经与当地政府和内部建立了联系,掌握了如何获得适当的许可证和执照的信息。

您的企业应如何选择?

无论选择利用全球CDN或是建立一处数据中心网络是一个需要进行权衡的行为。企业如何才能充分利用时间启动并运行CDN较之其保留所需的控制水平,自行建立数据中心,是决策的核心因素。所有的资源应充分权衡,相关的预算项目必须列出,时间的经济价值(time-value-money ,TVM)应该讨论。总之,关于如何做出正确的决策并没有统一的公式可遵循;然而,通过仔细的比对企业的目标,并深入研究,将有助于企业确定是否是建立一个数据中心网络或利用全球CDN。

如何用十条命令在一分钟内检查Linux服务器性能

通过执行以下命令,可以在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

其中一些命令需要安装sysstat包,有一些由procps包提供。这些命令的输出,有助于快速定位性能瓶颈,检查出所有资源(CPU、内存、磁盘IO等)的利用率(utilization)、饱和度(saturation)和错误(error)度量,也就是所谓的USE方法。

下面我们来逐一介绍下这些命令,有关这些命令更多的参数和说明,请参照命令的手册。

uptime

$ uptime 23: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 1 procs ---------memory---------- ---swap-- -----io---- -system-- ------cpu----- r  b swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st 34  0    0 200889792  73708 591828    0    0     0     5    6   10 96  1  3  0  0 32  0    0 200889920  73708 591860    0    0     0   592 13284 4282 98  1  1  0  0 32  0    0 200890112  73708 591860    0    0     0     0 9501 2154 99  1  0  0  0 32  0    0 200889568  73712 591856    0    0     0    48 11900 2459 99  0  0  0  0 32  0    0 200890208  73712 591860    0    0     0     0 15898 4840 98  1  1  0  0 ^C

vmstat(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,一般被其他虚拟机消耗)。

上述这些CPU时间,可以让我们很快了解CPU是否出于繁忙状态。一般情况下,如果用户时间和系统时间相加非常大,CPU出于忙于执行指令。如果IO等待时间很长,那么系统的瓶颈可能在磁盘IO。

示例命令的输出可以看见,大量CPU时间消耗在用户态,也就是用户应用程序消耗了CPU时间。这不一定是性能问题,需要结合r队列,一起分析。

mpstat-P ALL 1

$ mpstat -P ALL 1 Linux 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  %idle 07:38:50 PM  all  98.47   0.00   0.75    0.00   0.00   0.00    0.00    0.00    0.00   0.78 07:38:50 PM    0  96.04   0.00   2.97    0.00   0.00   0.00    0.00    0.00    0.00   0.99 07:38:50 PM    1  97.00   0.00   1.00    0.00   0.00   0.00    0.00    0.00    0.00   2.00 07:38:50 PM    2  98.00   0.00   1.00    0.00   0.00   0.00    0.00    0.00    0.00   1.00 07: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 1 Linux 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  Command 07:41:03 PM     0         9    0.00    0.94    0.00    0.94     1  rcuos/0 07:41:03 PM     0      4214    5.66    5.66    0.00   11.32    15  mesos-slave 07:41:03 PM     0      4354    0.94    0.94    0.00    1.89     8  java 07:41:03 PM     0      6521 1596.23    1.89    0.00 1598.11    27  java 07:41:03 PM     0      6564 1571.70    7.55    0.00 1579.25    28  java 07:41:03 PM 60004     60154    0.94    4.72    0.00    5.66     9  pidstat 07:41:03 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command 07:41:04 PM     0      4214    6.00    2.00    0.00    8.00    15  mesos-slave 07: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  java 07:41:04 PM   108      6718    1.00    0.00    0.00    1.00     0  snmp-pass 07:41:04 PM 60004     60154    1.00    4.00    0.00    5.00     9  pidstat ^C

pidstat命令输出进程的CPU占用率,该命令会持续输出,并且不会覆盖之前的数据,可以方便观察系统动态。如上的输出,可以看见两个JAVA进程占用了将近1600%的CPU时间,既消耗了大约16个CPU核心的运算资源。

iostat-xz 1

$ iostat -xz 1 Linux 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.21 Device:   rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util xvda        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.09 xvdb        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.25 xvdc        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.26 dm-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.04 dm-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.00 dm-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 [...] ^C

iostat命令主要用于查看机器磁盘IO情况。该命令输出的列,主要含义是:

  • r/s, w/s, rkB/s, wkB/s:分别表示每秒读写次数和每秒读写数据量(千字节)。读写量过大,可能会引起性能问题。

  • await:IO操作的平均等待时间,单位是毫秒。这是应用程序在和磁盘交互时,需要消耗的时间,包括IO等待和实际操作的耗时。如果这个数值过大,可能是硬件设备遇到了瓶颈或者出现故障。

  • avgqu-sz:向设备发出的请求平均数量。如果这个数值大于1,可能是硬件设备已经饱和(部分前端硬件设备支持并行写入)。

  • %util:设备利用率。这个数值表示设备的繁忙程度,经验值是如果超过60,可能会影响IO性能(可以参照IO操作平均等待时间)。如果到达100%,说明硬件设备已经饱和。

如果显示的是逻辑设备的数据,那么设备利用率不代表后端实际的硬件设备已经饱和。值得注意的是,即使IO性能不理想,也不一定意味这应用程序性能会不好,可以利用诸如预读取、写缓存等策略提升应用性能。

free -m

$ free -m             total       used       free     shared    buffers     cached Mem:        245998      24545     221453         83         59        541 -/+ buffers/cache:      23944     222053 Swap:            0          0          0

free命令可以查看系统内存的使用情况,-m参数表示按照兆字节展示。最后两列分别表示用于IO缓存的内存数,和用于文件系统页缓存的内存数。需要注意的是,第二行-/+ buffers/cache,看上去缓存占用了大量内存空间。这是Linux系统的内存使用策略,尽可能的利用内存,如果应用程序需要内存,这部分内存会立即被回收并分配给应用程序。因此,这部分内存一般也被当成是可用内存。

如果可用内存非常少,系统可能会动用交换区(如果配置了的话),这样会增加IO开销(可以在iostat命令中提现),降低系统性能。

sar -n DEV 1

$ sar -n DEV 1 Linux 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   %ifutil 12:16:49 AM      eth0  18763.00   5032.00  20686.42    478.30      0.00      0.00      0.00      0.00 12:16:49 AM        lo     14.00     14.00      1.36      1.36      0.00      0.00      0.00      0.00 12:16:49 AM   docker0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00 12:16:49 AM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s   %ifutil 12:16:50 AM      eth0  19763.00   5101.00  21999.10    482.56      0.00      0.00      0.00      0.00 12:16:50 AM        lo     20.00     20.00      3.25      3.25      0.00      0.00      0.00      0.00 12:16:50 AM   docker0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00 ^C

sar命令在这里可以查看网络设备的吞吐率。在排查性能问题时,可以通过网络设备的吞吐量,判断网络设备是否已经饱和。如示例输出中,eth0网卡设备,吞吐率大概在22 Mbytes/s,既176 Mbits/sec,没有达到1Gbit/sec的硬件上限。

sar -n TCP,ETCP 1

$ sar -n TCP,ETCP 1 Linux 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/s 12:17:20 AM      1.00      0.00  10233.00  18846.00 12:17:19 AM  atmptf/s  estres/s retrans/s isegerr/s   orsts/s 12:17:20 AM      0.00      0.00      0.00      0.00      0.00 12:17:20 AM  active/s passive/s    iseg/s    oseg/s 12:17:21 AM      1.00      0.00   8359.00   6039.00 12:17:20 AM  atmptf/s  estres/s retrans/s isegerr/s   orsts/s 12:17:21 AM      0.00      0.00      0.00      0.00      0.00 ^C

sar命令在这里用于查看TCP连接状态,其中包括:

  • active/s:每秒本地发起的TCP连接数,既通过connect调用创建的TCP连接;

  • passive/s:每秒远程发起的TCP连接数,即通过accept调用创建的TCP连接;

  • retrans/s:每秒TCP重传数量;

TCP连接数可以用来判断性能问题是否由于建立了过多的连接,进一步可以判断是主动发起的连接,还是被动接受的连接。TCP重传可能是因为网络环境恶劣,或者服务器压力过大导致丢包。

top

$ top 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命令包含了前面好几个命令的检查的内容。比如系统负载情况(uptime)、系统内存使用情况(free)、系统CPU使用情况(vmstat)等。因此通过这个命令,可以相对全面的查看系统负载的来源。同时,top命令支持排序,可以按照不同的列排序,方便查找出诸如内存占用最多的进程、CPU占用率最高的进程等。

但是,top命令相对于前面一些命令,输出是一个瞬间值,如果不持续盯着,可能会错过一些线索。这时可能需要暂停top命令刷新,来记录和比对数据。

总结

排查Linux服务器性能问题还有很多工具,上面介绍的一些命令,可以帮助我们快速的定位问题。例如前面的示例输出,多个证据证明有JAVA进程占用了大量CPU资源,之后的性能调优就可以针对应用程序进行。