存档

‘系统架构’ 分类的存档

阿姆达尔定律(Amdahl’s Law)

2016年5月6日 1,287 views 没有评论

阿姆达尔定律是一个计算机科学界的经验法则,因IBM公司计算机架构师吉恩·阿姆达尔而得名。吉恩·阿姆达尔在1967年发表的论文中提出了这个重要定律。

阿姆达尔定律主要用于发现仅仅系统的部分得到改进,整体系统可以得到的最大期望改进。它经常用于并行计算领域,用来预测适用多个处理器时理论上的最大加速比。在我们的性能调优领域,我们利用此定律有助于我们解决或者缓解性能瓶颈问题

阿姆达尔定律的模型阐释了我们现实生产中串行资源争用时候的现象。如下图模型,一个系统中,不可避免有一些资源必须串行访问,这限制了我们的加速比,即使我们增加了并发数(横轴),但取得效果并不理想,难以获得线性扩展能力(图中直线)。

 

1

以下介绍中、系统、算法、程序可以认为都是优化的对象,我不加以区分,它们都有串行的部分和可以并行的部分。

在并行计算中,使用多个处理器的程序的加速比受限制于程序串行部分的执行时间。例如,如果一个程序使用一个CPU核执行需要20小时,其中部分代码只能串行,需要执行1个小时,其他19小时的代码执行可以并行,那么,不考虑有多少CPU可用来并行执行程序,最小执[……]

Read more

许多人没有理解透彻的一些基础概念

2015年2月8日 1,963 views 没有评论

基础概念的交流和理解一致,才有助于意识的沟通一致。才有助于意识层面的交流。

资源(resource)物理服务器的功能组件,一些软件资源也可以被衡量,比如线程池、进程数等。系统的运行,需要各种资源,对于资源列表的确定,我们可以凭借对系统的了解确定,也可以通过绘制系统的功能块图的方式确定要衡量的资源。

常见的物理资源如下,

CPU(cpu sockets)、CPU核(cores)、硬件线程(虚拟线程)hardware threads( virtual threads)

内存

网络接口

存储设备

存储或者网络的控制器

内部高速互联

 

负载(load):有多少任务正在施加给系统,也就是系统的输入,要被处理的请求。对于数据库,那么负荷就包括了客户端段发送过来的命令和查询。

负载如果超过了设计能力,往往导致性能问题。应用程序可能因为软件应用的配置或者系统架构导致性能降低,比如,如果一个应用程序是单线程的,无疑它会受制于单线程架构,因为只能利用一个核,后续的请求都必须排队,不能利用其他核,但也可能仅仅是因为负载太多了。负[……]

Read more

运维架构的一些思考(4)

2012年6月20日 2,896 views 没有评论

凌晨2点有一个升级.睡不着. 写下这篇 文章. 不一定全面, 但可以给大家一个参考.

ssd盘发展,对于我们架构的影响.

1. 基于主机的高可用越来越成为趋势. 而不是传统的小机,高端存储的集中式的管理,这点可以参考网上炒作的”淘宝的去IOE”,部分反应了现实,说点题外话,我本人对于这种一刀切很反感,oracle是一个整体解决方案商,有它的价值所在,不是那么容易去的,不能为去而去. 一些公司有点跟风,而技术是最忌讳跟风的 ,在没有碰到瓶颈和真正的需要之前,去什么or不去什么差异不大,节省不了什么成本,仍然需要深刻理解应用,才能做出合适的规划;
2. cpu和带宽可能会出现瓶颈. 以前硬件cpu基本过剩. 但随着磁盘io能力的提升,单台主机可以部署多个实例, cpu和带宽可能会出现瓶颈 ,多个实例,需要留意NUMA架构优势,避免其负面影响;
3. 传统的raid作为一种成熟机制,仍然值得在ssd上做. (条带和数据库的block size仍然需要考量) .虽然我倾向于做raid1+0,但是为了节省成本,生产中一般是raid5和raid0,在故障率可接受的情况,不用太过ca[……]

Read more

运维架构的一些思考(3)

2012年5月29日 2,454 views 没有评论

关于监控.

关于监控的查看, 许多时候,不只是运维人员需要查看,研发同学也需要查看,产品同学可能也想看看. 用户希望的是单点登录获取所有有用信息,他需要从一个点就可以获取到所有的信息,而不是存在多个信息孤岛,所以有必要整合各种监控产品.让用户尽可能方便获取他要关注的一些指标.
如果研发同学也能实时查看到整个服务的一个性能变化趋势, 会有助于他们改进程序.
许多故障发现问题的时候,往往已经晚了,如果监控并没有及时发现, 那么是否有更实时的方式, 是否可以对关键的访问进行实时统计,实时在线记录各种性能数据呢?这样会投入一定开发成本, 但对于用户体验的改善更有针对性.
生产环境, 数据库往往在最后一环, 如果应用服务不能及时预警,那么一个小小的升级,都可能导致突然数据库流量大增, 导致数据库宕掉.  互联网公司许多服务为了快速上线,压力测试往往并没有做. 部分原因是认为开发成本高,想赶进度,部分原因是产品和研发同学自己都不清楚具体的数据, 许多人希望进行快速上线,快速迭代, 在运营中不断调整架构和改善程序,  如果要适应这样的模式, 更加需要服务的监控预警功能,有必要细化到许[……]

Read more

运维架构的一些思考(2)

2012年5月6日 1,859 views 没有评论
关于代理,负载均衡软硬件的稳定和服务隔离的重要性
由于技术限制和数据安全的考虑,一般数据库是单点的. 而之上的负载均衡设备, 代理, web服务器一般是能冗余故障处理的.
现实生产中,往往为了充分利用资源,会不断在一台主机上堆叠服务,之后为了提高可维护性,保障服务稳定,又会开始不断隔离,分离部署或者利用虚拟机技术.  许多中型公司都有几百甚至上千台服务器, 怎么避免服务之间的资源争用影响到服务的稳定呢? 不仅需要软件架构的松耦合,硬件部署也需要尽量隔离.   web服务如果不是很稳定,由于前面有F5负载均衡设备或者其他负载均衡软件,出现性能问题导致宕机的情况可以得到缓解,但如果web服务器和数据库服务器部署在一起,宕机或者负载很高往往会导致数据库的异常. 我们在部署数据库的时候,往往会进行一些容量规划,但内存往往是不能控制的.一个不稳定的web服务,可能导致内存急剧升高,最终导致触发OS的OOM机制,直接kill掉数据库.
关于负载均衡,LVS,Haproxy这些开源软件已经非常成熟,而且在许多大公司得到了大量应用,在很多情况下都可以代替硬件负载均衡设备,而且伸缩性也更强[……]

Read more

运维架构的一些思考(1)

2012年5月4日 2,177 views 没有评论

关于多集群部署,跨IDC同步数据.

多IDC部署主要是为了改善用户体验, 容灾,最主要的目的我想还是为了用户体验,   也有部分由于历史原因,应用的分布导致了跨IDC的访问.
可以理解为一种CDN加速方案.
首先,我想任何架构的部署,设计,都是要基于已经存在的一些历史访问性能数据或者监控数据. 而这些数据往往是可以通过各种方式收集也一般易于从应用程序侧收集的. 所以如果有需要改善用户体验,最好基于已经存在的用户访问的响应时间数据,以衡量是否采取就近部署节点加速用户响应的方案;
其次, 我们需要明确加速的是什么内容?往往数据库的流量只占据流量的很少一部分,那么我们是否有必要在许多集群都部署数据库从库, 能不能换一种思路,部署cache节点来加速响应? 使用cache节点有一个弱点,失效可能比较复杂, 但如果是海量访问的站点,往往cache才是成本最低的方案,可以支撑大得多的流量和并发, 数据库的主从很稳健,但其实是在网络稳定的情况,数据库下面还有一层网络层,如果网络层不可靠,那么数据库也可以认为是不可靠的.而生产中的实践已经证明了跨网复制一直存在不稳定情况;
可能许[……]

Read more

关于性能测试/压力测试

2012年5月3日 923 views 评论已被关闭

叙述下性能/压力测试的一些注意事项:

1. 需要明白,干扰是必然存在的。 性能测试所处的环境可能不是干净的,即使较为干净了,但仍然可能有你所不知道的因素影响你的测试结果。干扰的来源可能不那么清晰,如果你需要仔细研究系统性能,你就需要确定它。对于一些云上的环境,由于你和其他用户共享资源,其他用户的活动可能影响到你,而你在一个客户环境内,很难知道物理系统的资源竞争。

2. 现在的应用环境,往往包含多个组件,如负载均衡软硬件设备、WEB服务器、数据库服务器、存储系统。有一够真实的模拟环境,可以及早发现干扰的源头。各个组件对照物理环境独立部署,不互相影响,可以更好确保测试结果的可靠。

3. 性能/压力测试,往往需要时间,见过许多测试报告,可能为了速度(大家时间都很紧张),往往没有测试足够多的时间。实际上,我们是需要足够的时间的,有足够的时间,数据才可能更符合生产情况,比如有”碎片“,N多性能测试,就是load数据,然后开始开测,但实际上,你应该尽量采取一些操作,让数据变得不那么“整齐”,比如在insert/update/delete数据的时候按随机的key顺序操作。 有“碎片[……]

Read more

数据库大会感想(五)

2012年4月24日 1,876 views 没有评论

数据库领域, 技术可以正常得到,但是架构的意识,成本的意识, 把握趋势的能力却是很难练就的.  当然,很多情况,技术人员可能也决策不了, 所以在错误的道路上一错再错.

 

#以后补.

数据库大会感想(四)

2012年4月22日 2,052 views 没有评论

说说Nosql

——————

我对 腾讯的一个分布式key-value内存系统(带持久化) 做了一些摘要 . 腾讯的哥们演讲比较朴实,和百度的同学风格不一样,讲得也很到位.

~~~~~~

—————–

目前在腾讯 snsgame和开放平台中使用

4千台机器  ,2个人运维,2000+业务 ,50T数据, 50+集群

09年底开始做分布式的key-value系统 . 是一个分布式内存系统, 有持久化机制.

有一个强大的管理平台. 很强的统计分析,监控报警功能.

目前许多操作:资源扩容,资源使用不均的调度, 还需要运维人员手动操作.

未来cmem是希望能根据信息报警,资源利用情况 自动调度资源

 

要注意的是:

全内存操作

— 带宽可能成为瓶颈

— 成本高 ,  如果不是很高并发,高性能的应用,接入进来是有些浪费资源的.

 

 

一些关注的特点: 平滑扩容 ,定点回档.

平滑扩容的意思是: 随着业务[……]

Read more

云计算和性能优化

2012年4月21日 937 views 评论已被关闭

云计算和虚拟化技术应用越来越广泛,相关的工具/平台也越来越成熟。亚马逊的云服务,要考虑试用下。

使用云,意味着思维的变化,构建的程序将更有扩展性,要使用一种能够很好的水平扩展到架构,可以不断的增加小的单元来增长服务能力。这样,我们可以不用做到很精细的容量规划,因为很快就可以增加服务能力了。性能分析的效果也往往立竿见影,因为性能优化后,我们可以马上减少子系统,成本马上下降。而在传统行业内,往往需要购置昂贵的设备,签订长达1年甚至几年的服务合同,成本很难降下来。

云计算和虚拟化也带来了其他挑战。如。

1. 资源隔离,由于许多租户共享资源,可能互相影响,比如IO隔离如果做得不好,可能一个高IO应用导致磁盘饱和会影响到构建于物理系统之上的许多应用,特别是对于本来就不够充裕的资源,资源隔离/虚拟化 将更困难。

2. 物理系统的可观察性,用户可能很难以知道真实的物理主机性能,从而难以针对性的进行调优。

云上的数据库的性能调优值得研究下。