什么样的硬件设备在支撑 Stack Overflow? - 开源中国社区
什么样的硬件设备在支撑 Stack Overflow?
oschina 2014年03月10日

什么样的硬件设备在支撑 Stack Overflow?

oschina oschina 发布于2014年03月10日 收藏 138 评论 63

Stack Overflow 是使用 ASP.NET 开发的。

我更愿意把 Stack Overflow 看作是能够运行于大规模数据下,但本身并不算大规模的(running with scale but not at scale)。意思是我们的网站非常有效率,但至少目前为止,我们的规模还不够“大”。让我们通过一些数字来介绍Stack Overflow当前是一个怎样的规模吧。以下是一些核心的数字,来自于不久前在一整天(24小时)内的统计,准确说是2013年11月12日。这是一个典型的工作日,并且只统计了我们活动的数据中心,也就是我们自己的服务器。那些对CDN节点的请求和流量被排除在外,因为它们并不直接访问我们的网络。

  • 负载均衡器接受了148,084,833次HTTP请求

  • 其中36,095,312次是加载页面

  • 833,992,982,627 bytes (776 GB) 的HTTP流量用于发送

  • 总共接收了286,574,644,032 bytes (267 GB) 数据

  • 总共发送了1,125,992,557,312 bytes (1,048 GB) 数据

  • 334,572,103次SQL查询(仅包含来自于HTTP请求的)

  • 412,865,051次Redis请求

  • 3,603,418次标签引擎请求

  • 耗时558,224,585 ms (155 hours) 在SQL查询上

  • 耗时99,346,916 ms (27 hours) 在Redis请求上

  • 耗时132,384,059 ms (36 hours) 在标签引擎请求上

  • 耗时2,728,177,045 ms (757 hours) 在ASP.Net程序处理上

(我觉得应该发表一篇文章介绍我们如何快速采集这些数据,以及为什么值得耗费精力去获取它们)

注意以上数字包括了整个Stack Exchange网络,但那并不是我们全部的。除此之外,这些数字也仅仅来自于我们为了检测性能而记录的HTTP请求。“哇,一天有这么多个小时,你们怎 么做到的?”我们把这叫做魔法,当然有些人喜欢说成“许多个有多核处理器的服务器”,但我们依然坚持这是魔法。以下是那个数据中心里运行Stack Exchange网络的设备:

有图有真相:
stack_overflow_1

我们不仅仅运行网站,旁边架子上还有一些运行着虚拟机的服务器和其他设备,它们并不直接服务于网站,而是进行部署、域名控制、监控、操作数据库等其他工作。上面列表中的两个数据库服务器之前一直都是用作备份,直到最近才作为只读的负载(主要用于Stack Exchange API),于是我们可以不需要太多考虑便继续扩大规模了。Web服务器有两个分别用于开发和存储元数据,运行负载非常低。

核心设备

如果除去那些多余的设备,以下是Stack Exchange运行需要的(保持目前的性能水平):

  • 2个MS SQL服务器(Stack Overflow在一台,其他的在另一台,实际上只需一台机器运行还能有富余)

  • 2个Web服务器(或许3个吧,不过我有信心2个足矣)

  • 1个Redis服务器

  • 1个标签引擎服务器

  • 1个ElasticSearch服务器

  • 1个负载均衡器

  • 1个交换机

  • 1个ASA

  • 1个路由器

(我们真该找个机会尝试这个配置,关闭部分设备,看看极限在哪)

现在还有一些虚拟机运行在后台,执行一些辅助功能,比如域名控制等等。但那都是些相当低负载的任务,我们就不做讨论了,这里把重心放在Stack Overflow本身,看看它是怎样全速加载出页面的。如果你希望更精确全面,可以增加一个VMware虚拟机进来,用于执行所有的辅助工作。这样看来并 不需要很多机器,但是这些机器的规格通常在云上难以实现,除非你有足够多的钱。以下是这些“增强型”服务器简要的配置介绍:

  • 数据库服务器有384GB内存和1.8TB的SSD硬盘

  • Redis服务器有96GB内存

  • ElasticSearch服务器有196GB内存

  • 标签引擎服务器有着我们能买得起的最快的处理器

  • 交换机每个端口有10Gb的带宽

  • Web服务器不是很特别,有32GB内存、2个4核处理器和300GB的SSD硬盘

  • 有些服务器有2个10Gb带宽的接口(比如数据库),其他有4个1Gb带宽的

20Gb的带宽太多余了?你还真特么说对了,活动的数据库服务器平均只利用了20Gb通道中的100-200Mb。然而,像备份、重建等等操作,根据当前内存和SSD硬盘的情况,可以使带宽完全饱和,所以说这样设计还是有意义的。

存储设备

我们目前有大约2TB的数据库存储(第一个集群有18块SSD硬盘—— 总共1.63TB,使用1.06TB;第二个集群由4块SSD硬盘组成—— 总共1.45TB,使用889GB),这是我们在云服务器上需要的(嗯哼,又要吐槽价格了吧),请记住这全部都是SSD硬盘。归功于存储器良好的表现,我 们数据库的平均写入时间是0毫秒,甚至超出我们能度量的精度了。算上内存中的数据以及两级缓存,Stack Overflow中实际的数据库读写比例是40:60。你没看错,60%是写操作(点此了解读写比)。此外,每个Web服务器都有两块320GB SSD硬盘组成的RAID1。ElasticSearch在每个区块大约需要300GB的容量,由于我们会非常频繁的写入或重建索引,SSD硬盘在这里是更好的选择。

值得注意的是我们拥有一个SAN(存储区域网络)连接到核心网络,那就是 Equal Logic PS6110X,它有24个可热交换的10K SAS磁盘和2个10Gb的控制器。这个设备仅仅被VM服务器用作共享储存空间以保证虚拟机高度的可用性,但并不实际支撑网站的运行。换句话说,如果SAN挂掉了,在一段时间内网站甚至无法察觉(只有虚拟机中的域名控制器能感知到)。

整合到一起

这所有的设备在一起是为了什么?性能。我们需要很高的性能,这是一个对我们来说很重要的特性。所有站点的首页都是问题页面,我们内部把它亲切地称作Question/Show(路由的名字)。在11月12日,这个页面平均渲染时间是28毫秒, 而我们的要求是至多50ms。为了使用户获得更好的体验,我们尽一切可能缩短页面加载的时间,哪怕只有一毫秒。在和性能有关的问题上,我们所有的开发人员 都是“锱铢必较”的,这也有助于我们的网站保持快速响应。以下是一些Stack Overflow上热门页面的平均渲染时间,数据还是来自于前面统计的那24小时:

  • Question/Show: 28 ms (2970万次点击)

  • User Profiles: 39 ms (170万次点击)

  • Question List: 78 ms (110万次点击)

  • Home page: 65 ms (100万次点击) (这对我们来说已经很慢了,Kevin Montrose正在着手修复这个问题

凭借对每一次请求的时间线的记录,我们能够准确观察到页面加载的过程。我们需要这样的数据,否则难道靠脑补来做决定吗?有数据在手,我们就可以这样监控性能:
stack_overflow_2

如果你对某个特定页面的数据感兴趣,我也很乐意发布出来。但这里我重点关注渲染时间,因为它表示我们的服务器需要多久来生成一个网页。网络传输速度是一个完全不同的话题了(尽管不得不承认它也有很大的关系),不过将来我会讲到的。

增长空间

非常值得一提的是我们这些服务器运行时的使用率都非常低。比如Web服务器的CPU平均使用率为5-15%,内存只使用了15.5GB,网络流量只有20-40Mb/s;而数据库服务器CPU平均使用率为5-10%, 使用了365GB内存,以及100-200Mb/s的网络。这使我们能做到几件重要的事情:在网站规模增大时不至于需要马上升级设备;当出现问题时(错误 的查询、代码以及攻击等等,无论是什么样的问题),我们能保持网站始终不挂;在必要的时候降低功耗。这里有个我们Web层的监控项目
stack_overflow_3

利用率如此之低的主要原因是高效的代码。尽管本文的主题并不是这个,但是高效的代码对挖掘服务器的性能也有着决定性的作用。做一件非必要的事情所损 失的,居然比无所作为还要多——把这引申到代码中就是说,你需要把它们改进得更高效了。这些损失或者消耗可以是能源、硬件(你需要更多更快的服务器)、开 发人员理解代码更困难(平心而论,这个有两面性,高效的代码并不一定那么简单),以及缓慢的页面渲染——可能导致用户更少地浏览网站其他页面甚至再也不访 问你的网站了。低效率代码带来的损失可能比你想象的大很多。

现在我们了解了Stack Overflow运行在怎样的硬件上,下次可以讨论一下为何我们不使用云。

原文链接: SO 团队成员 Nick Craver   翻译: 伯乐在线 - 蒋生武
译文链接: http://blog.jobbole.com/61646/

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:什么样的硬件设备在支撑 Stack Overflow?
分享
评论(63)
最新评论
0

开源网站喷子真多

0
什么数据库,尽然要耗3百多G内存
0
去看看whatsapp
0

引用来自“仗剑逐风”的评论

。。。。都没看别人数据库内存是300多G吗?硬盘是ssd吗?这样的硬件还有什么说的

对于访问这么大的网站这个配置已经很低了吧。
0
。。。。都没看别人数据库内存是300多G吗?硬盘是ssd吗?这样的硬件还有什么说的
0

引用来自“Brin想写程序”的评论

引用来自“imzhi”的评论

引用来自“JohnnyCage”的评论

对.NET又增添了一些信心

对.NET的信心,只要知道StackOverflow和Microsoft的站点,就足够有了

还有大京东啊。。

京东 已经采用java
0

引用来自“Brin想写程序”的评论

引用来自“neo-chen”的评论

使用 window 与 linux, mssql 与 mysql。商业与开源,对于打工的来说没有什么不同。仅仅是创造了一个工作岗位。

linux和mysql的工作岗位更多,把给公司的钱,给了程序员。

开发windows就不是程序员了?你说如果没有商业软件大家现在都不不知道啥是电脑。赚钱才是王道
0
mark
不参与无谓的语言之争
0
中小公司用.Net用不起。
.Net也需要维护人员,工资不见得比Linux低。
综合成本,开源完胜商业闭源。否则开源不会这么火。
0
还特意注明Stack Overflow 是使用 ASP.NET 开发的...
0
以现在京东的实力,不会承受不起那点授权费的,而是做大了之后.NET不再适合自己了。stackoverflow和京东,淘宝,twitter,amazon完全不是一个量级的,这些都用的java的。比语法特性这些小孩子家家的东西,.net完爆java,比框架,和生态,.NET在大java面前就是渣渣。看看TechEmpower/FrameworkBenchmark的web框架测试,不论是跑在ec2上的还是i7实机环境,windows平台或linux平台,java在测试中都是遥遥领先,只有少数几个测试中被c/c++的框架性能超越。
.NET这种就是中小企业用用,大企业还是算了,一是没有主动权,二是不够灵活,大企业有的是资金,物力和人力搞适合自己企业的框架,不需要微软这一套。
就像刚开始起步的时候用微软的全套东西发现能快速的产品上线,出了问题有售后负责,很省心。可是随着企业规模做大,就会发现这种大而全的东西越来越不适合企业自己的变化需求,淘宝全部是自己实现的框架,百度也是,京东现在也在搞自己的,怎么可能把自己的未来赌在.NET上,被别人牵着鼻子走丧失主动性。中小企业没有这个资金和技术能力,也没有这个必要,但大企业却不同。csdn也由之前完全依赖.NET变成现在的多种技术框架并存,而且之前使用的ruby on rails那种大而全的框架,全套的所谓的方便的东西也都给扔了。
很简单的道理,就像刚开始的学.NET的人喜欢拖控件,喜欢这种方便性,但随着学习的深入慢慢的发现这些东西最终会变成束缚自己的东西。java有不如.NET的地方,但java也有.NET很难比得过的地方,很多第一次搞java的在对比.net之后都抱怨java生态圈太乱,框架太多,没有.NET那样一条龙服务省心,但随着慢慢做深入了,却未必依就是如此了。
0
我关心监控
0
问题出在票是有限的,每次购买都要查询一下。
0
外国开源模式,我看到很多公司将开源技术包装,商业化,提供很好的服务于售后。
中国的模式还是自己招人二次开发。
0

引用来自“neo-chen”的评论

引用来自“Brin想写程序”的评论

引用来自“neo-chen”的评论

使用 window 与 linux, mssql 与 mysql。商业与开源,对于打工的来说没有什么不同。仅仅是创造了一个工作岗位。

linux和mysql的工作岗位更多,把给公司的钱,给了程序员。

window 比linux 成本低,在于一次投入,售后,800电话....
不需要养一个系统管理员,常年发工资。在美国裁员成本比买windows贵N倍

任何公司都需要至少一名系统管理员或者技术人员,售后服务往往不解决问题,需要一个从技术出发的甲方人员的,否则设备和软件采购都没法做。而这名系统管理员,养着他平时就打800电话也太亏了。所以其实不如上linux节省成本,系统管理的成就感也高。
0

引用来自“Brin想写程序”的评论

引用来自“neo-chen”的评论

使用 window 与 linux, mssql 与 mysql。商业与开源,对于打工的来说没有什么不同。仅仅是创造了一个工作岗位。

linux和mysql的工作岗位更多,把给公司的钱,给了程序员。

window 比linux 成本低,在于一次投入,售后,800电话....
不需要养一个系统管理员,常年发工资。在美国裁员成本比买windows贵N倍
0

引用来自“neo-chen”的评论

使用 window 与 linux, mssql 与 mysql。商业与开源,对于打工的来说没有什么不同。仅仅是创造了一个工作岗位。

linux和mysql的工作岗位更多,把给公司的钱,给了程序员。
0
使用 window 与 linux, mssql 与 mysql。商业与开源,对于打工的来说没有什么不同。仅仅是创造了一个工作岗位。
0

引用来自“Brin想写程序”的评论

引用来自“imzhi”的评论

引用来自“JohnnyCage”的评论

对.NET又增添了一些信心

对.NET的信心,只要知道StackOverflow和Microsoft的站点,就足够有了

还有大京东啊。。

不知京东的某教授看了会如何感想?
0

引用来自“javaflex”的评论

引用来自“eechen”的评论

引用来自“Brin想写程序”的评论

引用来自“imzhi”的评论

引用来自“JohnnyCage”的评论

对.NET又增添了一些信心

对.NET的信心,只要知道StackOverflow和Microsoft的站点,就足够有了

还有大京东啊。。

真不凑巧,京东已经是个反例.
京东后端大体已经转到Java,但前端还有一些.Net遗留系统.
技术招聘岗位要求里频繁出现Linux、Java、Spring、ibatis、Hadoop、Oracle、MySQL等字眼.
http://zhaopin.jd.com/

另外上面这篇给人一种错觉,以为StackOverflow完全运行在Windows上,以为是一个全DotNet技术堆栈,其实不然。
看下面这篇在2011年写的文章:

http://highscalability.com/blog/2011/3/3/stack-overflow-architecture-update-now-at-95-million-page-vi.html
10台 IIS
2台 SQL Server
2台 HAProxy(Ubuntu 负载均衡)
2台 Redis (CentOS 数据缓存)
1台 Bacula (Linux 数据备份)
1台 Nagios (Linux 系统监控)
2台 Linux routers
值得注意的是,其中购买微软的软件Licenses的支出为24.2万美金(约合人民币147万元).

只考虑软件License成本,应用PHP/Java等开源技术(LAMP/JavaEE),成本可以降低到0,而且能够提供高质量、高性能、高可靠的互联网服务.

购买微软的软件Licenses的支出为24.2万美金(约合人民币147万元).,穷人用不起.Net呀。

那些钱估计主要就花在SQL Server、Windows Server、Visual Studio上。

而且Windows Server有使用人数限制,SQL Server有CPU核心数限制。
顶部