百万级运维经验四:服务器的选择和部署

标签: 百万 运维 经验 | 发表时间:2014-05-26 22:24 | 作者:reallypride
出处:http://blog.csdn.net

对服务器的选择,我曾经盲目过。流量大了服务器顶不住怎么办,我那时候的想法就是加配置,4核变8核,8核变16核,内存也加,4GB变8GB变16GB,为什么不加服务器呢,麻烦嘛,觉得提高服务器配置的效果也是一样的。后来我才明白,这种想法是错误的,还是停留在个人电脑的思维。

我发现,增加了服务器配置并不能给我带来相应的性能提升,我对服务器和操作系统没有特别深的了解,我个人觉得原因如下:

首先,大部分软件没有针对多核CPU进行优化,即便有优化,也无法百分百的利用CPU的资源,软件或系统对多核CPU资源的调度应该没有特别完善。

第二,我猜测,CPU跟内存,CPU跟硬盘之间的总线带宽应该是固定的,就好比房间很大,但房门很小,还是需要一个个排队进来。

第三,一般网站程序对CPU要求不高,网站的主要性能瓶颈在于硬盘的IO,由于硬盘IO速度是固定的,增加CPU并不能提高硬盘的IO性能。

我的看法是,把一台8核8GB内存的服务器换成两台4核4GB的服务器会好很多,也就是1+1>2,根据木桶原理,硬盘IO就是那块短板。

为什么呢,因为两台服务器就相当于得到了两倍的CPU总线,两倍的硬盘IO,就好比一个房间开了两个门,客人进入房间的速度就会快很多,CPU和内存的资源也能得到充分的利用。

两台服务器,可以做负载均衡,也可以把网站分成两个应用分别放在不同的服务器上。通常我会这样分,一般的网站都会分为PC版和手机版,那么我就把PC版放在一台服务器,手机版放在另一台服务器,两边代码互不影响,然后通过nginx两台服务器互相反向代理,再加上负载均衡,不管哪台服务器出问题,都能快速定位到。

我对网站架构的设计思想是,把大网站打散,分成各个独立的应用,比如:用户中心、注册登录、PC端、手机端等等,实际情况实际分析,然后把不同的应用放在不同的服务器上,其它应用就通过反向代理链接到对应的服务器上,形成一个网,不管访问哪一台服务器,都能通过这台服务器访问到其它的服务器。

作者:reallypride 发表于2014-5-26 14:24:03 原文链接
阅读:65 评论:0 查看评论

相关 [百万 运维 经验] 推荐:

百万级运维经验二:Redis和Memcached的选择

- - CSDN博客系统运维推荐文章
看到很多人推荐使用Redis代替Memcached,我觉得这两个是不一样的东西,它们的关系应该是共存而不是替代. Memcached是个纯内存型的缓存系统,支持数据类型单一,单个缓存数据有限制,支持分布式,我觉得这是个很理想的缓存系统. Redis是个简单的NOSQL数据库,支持几种简单的数据类型,支持主从复制,支持持久化,可以看作是个内存型数据库.

百万级运维经验五:服务器内核优化集锦

- - CSDN博客系统运维推荐文章
编辑文件 /etc/security/limits.conf ,添加两行参数:. 这两行参数设置linux系统最大可打开文件数. 编辑文件/etc/sysctl.conf,添加以下参数:. 如果服务器装有Redis,这个参数一定要加,不然Redis有很大的可能无法同步数据到磁盘. 把所有带backlog的参数的值调大,如:.

百万级运维经验四:大流量如何保存文章阅读数

- - CSDN博客系统运维推荐文章
网站文章通常都会有个阅读数,最简单的方法就是每访问一次就加一,这看起来很简单,update一下就可以了. 如果网站访问量很大呢,每天有几十万次的访问呢,一秒钟就要update几次服务器,效率就很低了. 而且,数据库update的时候会锁表,还会影响到读操作,看来只能用缓存了. Memcached是会丢失数据的,不合适;Redis是内存型数据库,可以持久化,就用它了.

百万级运维经验四:服务器的选择和部署

- - CSDN博客系统运维推荐文章
对服务器的选择,我曾经盲目过. 流量大了服务器顶不住怎么办,我那时候的想法就是加配置,4核变8核,8核变16核,内存也加,4GB变8GB变16GB,为什么不加服务器呢,麻烦嘛,觉得提高服务器配置的效果也是一样的. 后来我才明白,这种想法是错误的,还是停留在个人电脑的思维. 我发现,增加了服务器配置并不能给我带来相应的性能提升,我对服务器和操作系统没有特别深的了解,我个人觉得原因如下:.

ZooKeeper运维经验

- - Juven Xu
ZooKeeper 是分布式环境下非常重要的一个中间件,可以完成动态配置推送、分布式 Leader 选举、分布式锁等功能. 在运维 AliExpress ZooKeeper 服务的一年多来,积累如下经验:. 3台起,如果是虚拟机,必须分散在不同的宿主机上,以实现容灾的目的. 如果长远来看(如2-3年)需求会持续增长,可以直接部署5台.

百万级运维经验一:Mongodb和Redis数据不能放在同一个服务器

- - CSDN博客系统运维推荐文章
一开始时,为了省服务器,把Mongodb和Redis放在一个服务器上. 网站每到高峰期都特别卡,还经常出现502. 找了很久的原因,发现硬盘的写数据很大,IOPS也很高,排查了很多原因都没找到. 然后再仔细研究监控,发现写硬盘的操作很有规律,每隔几分钟就有一次频繁的写硬盘,联想到Redis同步数据到硬盘的间隔就是几分钟,所以开始怀疑是Redis引起的.

来自Facebook的一些MySQL运维经验

- - 运维派
每台机器都使用多实例的模型. 每个机器放多个实例,每个实例放多个DB. 一些信息可以参考: https://www.youtube.com/watch?v=UBHcmP2TSvk. 多实例之间没有进行资源隔离,这么做是让每个实例都能发挥最大性能. 目前大部分核心业务已切换成MyRocks引擎,在机器硬件配置不变的情况,约可节省一半机器.

从百万到十亿PV:Reddit的25条宝贵经验

- - IT经理网
自2005年至今,知名社交新闻网站Reddit的月页面浏览量完成了百万到十亿的转变,流量每15月翻一番,而Reddit的员工数量仍不满30,平均每位员工负责2400万PV. Reddit的高效率运营有两个支点:数以万计的志愿者以及失败中不断积累的宝贵经验. 前不久,Reddit前雇员Jeremy Edberg在RAMP会议上通过主题为“Scaling Reddit from 1 Million to 1 Billion–Pitfalls and Lessons”的演讲与人们分享了Reddit的宝贵经验.

每秒百万级流式日志处理架构的开发运维调优笔记 | Cloud

- -
荣幸之至,我们团队在实时日志分析、搜索项目中曾经应对过百万级的挑战,在这方面有长足的进步. 本文以笔记和问答的形式记录了我们曾经遇到过的实际问题及解决方案,而非小白式的大数据科普文章. 相信只有真正做过每秒近百万以上的实时日志处理业务,遇到过棘手问题,才能深刻感受我们当时越不过高坎的窘境与解决问题后的狂喜.

Java应用运维

- - BlueDavy之技术blog
对于互联网产品或长期运行的产品而言,运维工作非常重要,尤其是在产品复杂了以后,在这篇blog中就来说下Java应用的运维工作(ps:虽然看起来各种语言做的系统的运维工作都差不多,但细节上还是会有很多不同,so本文还是只讲Java的). 苦逼的码农按照需求开发好了一个全新的Java Web应用,该发布上线给用户用了,要把一个Java Web应用发布上线,首先需要搭建运行的环境,运行的环境需要有JDK、APPServer,在已经装好了os的机器上装上JDK和APPServer,开发好的Java Web应用可以用maven直接打成war或ear,将这个打好的包scp或其他方式到目标机器上,准备妥当,就差启动了.