Arch 类别下的文章

又读了一遍这个 PPT: Federation at Flickr: Doing Billions of Queries Per Day ,发现还是值得咀嚼一下,尽管这"甘蔗"已经被吃过了。

针对主机环境的实践参考

Flickr 数据库的硬件配置一般用 16G 内存,6块 15K 硬盘,RAID 10,在 EM64T 下跑 RHEL 4,运行在 Deadline I/O 调度器 模式 。回写 Cache 用控制器电池而不用磁盘的 Cache。Swappiness 设置为 0 . 。

大内存数据库服务器的 Swap 设置问题

上面提到了 Flickr 是把 Swappiness 设置为 0 ,简单的通过:

echo 0 > /proc/sys/vm/swappiness 

个别情况下这样也可能没起作用,因为实际上对 Swap 的调用是由如下的公式计算得到的:

swap_tendency = mapped_ratio/2 + distress + vm_swappiness; 

其中 vm_swappiness 默认值是 60.

这是个防御性的措施。Linux Kernel 2.6 (个别版本)有些诡异行为,当有大量物理内存空闲的时候,Linux 仍(或许)会傻乎乎的调用 Swap 空间,这导致有的时候系统性能很差。有人建议如果是 INNODB 的引擎的话,可以用 O_DIRECT 的方式强制直接调用物理内存。但似乎副作用很大(存疑)。

如果关闭 Swap (swapoff -a)的话,又会遇到 OOM 的问题。这是绝对不推荐的。

还有人用的方式是把 Swap 建立到 RAM 盘上。

Swap 的自动校正其实是个老问题,几年前可能超过 4g 的 Linux 服务器都不多,而现在动辄几十 G 的内存配置,应用场景发生了很大变化,Kernel 的算法思路肯定也要调整一些了吧(尽管几年来不断看到有小的 Patch 出来,可好像 RHEL 的 Kernel 还是老样子)。

我在这里抛砖引玉,大家实际应用中应该也遇到类似问题吧? 有什么建议? 还是干脆就不管? 默认情况下其实也能跑...

--EOF--

在上周六的 QClub 上,BASE 成为了一个热点话题,其实除了这个 BASE 之外,还有个 CAP 理论也是值得关注一下的。这个概念也来自 Inktomi 公司(被雅虎收购后已是明日黄花)的 Eric A. Brewer ,应该说他 10 年前的那篇 Lessons from Internet Services: ACID vs. BASE 是互联网技术最为重要的一篇文章了。

C: Consistency 一致性 
A: Availability 可用性
P: Tolerance of network Partition 分区容忍性(有翻译为耐受性的,个人觉得不妥)

CAP.png

熊掌与鱼不可兼得,三个目标不能同时满足。如果对"一致性"要求高,且必需要做到"分区",那么就要牺牲可用性;而对大型网站,可用性与分区容忍性优先级要高于数据一致性,一般会尽量朝着 A、P 的方向设计,然后通过其它手段保证对于一致性的商务需求。

CAP 不是什么高深的东西,应该说 CAP 只是一个经验理论,切不可钻牛角尖,号称自己做的东西能打破 CAP 理论,那只是无意义的事情罢了。

如果知道 ACID(酸) 、BASE(碱) 在词典中的含义,那么这个 CAP 的辞典含义也很有趣。

--EOF--

最后推荐阅读一下这篇:可伸缩性原则

本月 26 日,也就是明天,QClub:当SOA遭遇现实 将如期在支付宝举行。

除了报名参加的杭州本地的众多技术精英,阿里集团各家子公司也都有人参加,淘宝、阿里软件、阿里妈妈都会有资深架构师到现场来。相信这回是一场精彩的思维碰撞,期待。

特邀嘉宾:支付宝首席架构师 程立(花名:鲁肃)

程立,支付宝(中国)网络技术有限公司。2004年开始参与淘宝网与支付宝系统的建设,2005年起进入支付宝,一直从事于互联网电子支付系统的研发工作。现任支付宝首席架构师,专注于电子支付系统的分布式服务架构与开放架构。

一说起 SOA 可能很多人会觉得比较"空",这也是我们举办会议的目的之一,"来点实在的技术信息" 是这次活动的一个宗旨。

会议地点

文三路、万塘路交汇处,华星时代广场 5 楼。大厅届时会有人指路

友情提示

为便于交流,请尽量携带名片 :) 

--EOF--

一直以来,支付宝的技术人员都比较低调,这次总算利用网络侠客行大会的机会,促成了对支付宝首席架构师程立的采访。如果你对支付宝的架构和开发实践感兴趣,请不要错过 InfoQ 中文站 的这次专访:《程立谈架构、敏捷和SOA实践》

InfoQ 编辑在 介绍页面中引用程立的这段话我很欣赏:

老子说"道生一、一生二、二生三、三生万物"。在业务愿景的技术实现过程中,
假设"道"为愿景、一为方向、二为战略的话,三就应该是架构了,架构既出,万物化生可矣。

因为支付宝一直以为用户提供良好支付体验为目标,以致于有技术人员误认为简单的支付环节背后的支付宝后台技术也是非常简单的。其实想想看为将近 1 亿用户提供服务,每日交易额几个亿人民币,技术上没有独到之处怎么能做到?

和程立一起共事也有三年多了。我工作这么多年,很少遇到这么功力深厚、勤奋、敬业的技术人,感觉他就像一台自我修正的计算机,能一直朝着既定的目标前进,这一点值得很多技术人员学习。

如果觉得这次采访不过瘾,请关注接下来的 7月26日QClub杭州站-- 支付宝首席架构师程立与您分享"当SOA遭遇现实"的心得

--EOF--

在讨论 eBay 的Scalability最佳实践 的时候,结尾提到了 BASE 机制。现在越来越多的架构师更为关注 BASE 策略 (当然,我不是说 ACID 就不重要了)

BASE 策略是 Inktomi 公司(被雅虎收购后已是明日黄花)的 Eric A. Brewer 在 1988 年提出的。这几个缩写词如下定义:

  • Basically Available --基本可用
  • Soft-state --软状态/柔性事务
  • Eventual Consistency --最终一致性

"Soft state" (SS) 是与 "Hard state"(HS) 对应的。我几乎没找到很清晰的定义。不过用 RFC-1633 中的描述, "Soft state" 可以理解为"无连接"的, 而 "Hard state" 是"面向连接"的,这样就清晰多了。

最终一致性, 也是是 ACID 的最终目的。对于 eBay 这样的大架构,是通过强大的消息总线能力来保证的。

对于 eBay 这样的大架构,另请参考 eBay 的 Dan Pritchett 在 最近的技术的散文:BASE: An ACID Alternative,注意其中提到的的事件驱动(Event-Driven)的架构的说法。

相信在今后几年,BASE 将成为一个技术热词。ACID 当然没过时,只是各自需要合适的应用场景而已。随着互联网技术的开放性,更多的时候,一个架构师需要反复的衡量合适的应用场景。

BTW: "ACID" 英文里面有"酸"的意思,而 "BASE" 有"碱"的意思. 酸碱在一起才能中和啊,哈

--EOF--

Facebook 海量数据处理

对着眼前黑色支撑的天空 /  我突然只有沉默了
我驾着最后一班船离开 / 才发现所有的灯塔都消失了
这是如此触目惊心的 / 因为失去了方向我已停止了
就象一个半山腰的攀登者 / 凭着那一点勇气和激情来到这儿
如此上下都不着地地喘息着 / 闭上眼睛疼痛的感觉溶化了
--达达乐队《黄金时代》

好几个地方看到这个 Facebook - Needle in a Haystack: Efficient Storage of Billions of Photos,是 Facebook 的 Jason Sobel 做的一个 PPT,揭示了不少比较有参考价值的信息。【也别错过我过去的这篇Facebook 的PHP性能与扩展性

图片规模

作为世界上最大的 SNS 站点之一,Facebook 图片有多少? 65 亿张原始图片,每张图片存为 4-5 个不同尺寸,这样总计图片文件有 300 亿左右,总容量 540T,天! 峰值的时候每秒钟请求 47.5 万个图片 (当然多数通过 CDN) ,每周上传 1 亿张图片。

图片存储

前一段时间说 Facebook 服务器超过 10000 台,现在打开不止了吧,Facebook 融到的大把银子都用来买硬件了。图片是存储在 Netapp NAS上的,采用 NFS 方式。

图片写入

Facebook_write.png

尽管这么大的量,似乎图片写入并不是问题。如上图,是直接通过 NFS 写的。

图片读取

Facebook.png

CDN 和 Cachr 承担了大部分访问压力。尽管 Netapp 设备不便宜,但基本上不承担多大的访问压力,否则吃不消。CDN 针对 Profile 图象的命中率有 99.8%,普通图片也有 92% 的命中率。命中丢失的部分采由 Netapp 承担。

图中的 Cachr 这个组件,应该是用来消息通知(基于调整过的 evhttp的嘛),Memcached 作为后端存储。Web 图片服务器是 Lighttpd,用于 FHC (文件处理 Cache),后端也是 Memcached。Facebook 的 Memcached 服务器数量差不多世界上最大了,人家连 MYSQL 服务器还有两千台呢。

Haystacks --大海捞针

这么大的数据量如何进行索引? 如何快速定位文件? 这是通过 Haystacks 来做到的。Haystacks 是用户层抽象机制,简单的说就是把图片元数据的进行有效的存储管理。传统的方式可能是通过 DB 来做,Facebook 是通过文件系统来完成的。通过 GET / POST 进行读/写操作,应该说,这倒也是个比较有趣的思路,如果感兴趣的话,看一下 GET / POST 请求的方法或许能给我们点启发。

Facebook2.png

总体来看,Facebook 的图片处理还是采用成本偏高的方法来做的。技术含量貌似并不大。不清楚是否对图片作 Tweak,比如不影响图片质量的情况下减小图片尺寸。

--EOF--

几乎每个接触类 Unix 操作系统的工程师都知道如何查看系统负载。但这东西的工作机理到底是怎样的,可能没有多少能说清楚。对比了一些相关信息,加上自己的理解,做一下笔记。

什么是 Load ? 什么是 Load Average ?

Load 就是对计算机干活多少的度量(WikiPedia: the system load is a measure of the amount of work that a computer system is doing)。也有简单的说是进程队列的长度. Load Average 就是一段时间 (1 分钟、5分钟、15分钟) 内平均 Load 。【最好的参考文章:UNIX® Load Average Part 1: How It Works

下面是一个 uptime 命令输出:

$ uptime
18:57:48 up 423 days, 3:55, 2 users, load average: 1.16, 1.12, 1.20

尽管各种信息来源的定义都不太确定。能确定的一件事情是,你不能精确获取当前时间的 Load . 最小的计算粒度是 5 秒钟(CALC_LOAD 每 5HZ 计算一次, 5HZ 为 5秒钟,这里的 HZ 是系统定义的变量). 参见 Linux Kernel 这段代码:

 869        count -= ticks;
 870        if (unlikely(count < 0)) {
 871                active_tasks = count_active_tasks();
 872                do {
 873                        CALC_LOAD(avenrun[0], EXP_1, active_tasks); 
874 CALC_LOAD(avenrun[1], EXP_5, active_tasks);
875 CALC_LOAD(avenrun[2], EXP_15, active_tasks);
876 count += LOAD_FREQ; 877 } while (count < 0); 878 } 879}

如何判断系统是否已经 Over Load ?

对一般的系统来说,根据 CPU 数量去判断,如上面的例子, 如果平均负载始终在 1.2 以下,而你是 2 颗 CPU 的机器。那么基本不会出现 CPU 不够用的情况。也就是 Load 平均要小于 CPU 的数量。

这是 Solaris 性能与工具(Solaris Performance Tools ) 一书推荐的评估方法。【在这里要推荐一下这本书,尽管在 Load 这个地方没有达到我期望的那么细致。但全书揭示了非常多的性能信息。每个 DBA、架构师 的必须书。】

这么说实际上带来另外两个疑问:

1 如果是多核 CPU / 超线程的机器怎么判断? 对这样的机器,我的建议是看操作系统怎么识别的 CPU,根据系统识别出来的逻辑 CPU 数量来判断。如果要考虑性能系数,建议参考一下 Oracle 针对不同架构下多核 CPU 的收费标准。

2 如果应用是面向线程的怎么判断? 这实际上和 M:N 线程模型有关。你的系统是怎样的? 把这个问题考虑进去即可了。

多数情况下,Load 过高都未必和 CPU 有关。或许倒是有一个例外的,就是应用场景的问题。比如用单 CPU 的机器去做高并发 Web 服务器,麻烦就来了

Load 与容量规划(Capacity Planning)

任何一个相对成熟的站点都会利用 Cacti(基于RRDTool) 等工具进行容量规划工作。抓取的 Load 会传 1、5、15 分钟列值过去,这三个度量采用哪个呢? 15 分钟为首选【参见Gunther 的 PPT】。

Load 与系统预警

很多对可用性要求比较高的环境都建立了 邮件或SMS 报警机制。关于 Load 报警阈值的制定也有看到不太合理的时候。这里建议 Critical 值(如果用 Nagios 之类的工具你明白这是什么)上限为 物理 CPU 的个数(当然你可以设置比这个低)。但比这个值高的话,意义就不大了。比如,数据库服务器有 4 颗 CPU,那么 Load 高于 4 就应该报警出来,设置比 4 高可能意义不大,因为接到报警还有个人为响应时间...

误解 一:系统 Load 高一定是性能有问题。

真相:系统 Load 高也或许是因为在进行 CPU 密集型的计算(比如编译)

误解 二:系统 Load 高一定是 CPU 能力问题或数量不够。

真相:Load 高只是代表需要运行的队列累积过多了。但队列中的任务实际可能是耗 CPU的,也可能是耗 I/O 乃至其它因素的。

误解 三:系统长期 Load 高,首选增加 CPU。

真相:Load 只是表象,不是实质。增加 CPU 个别时候会临时看到系统 Load 下降,但治标不治本。

小小一个 Load 讲究其实不少。英文信息其实比较全的,尽量保证加入一点新信息到这篇文章里。入看到有写的不合理的地方或者有异议,请指正或告知。

--EOF--


FAQ 1:数据库服务器突然 CPU 100% 繁忙,咋办?


A :一般情况下,这是由糟糕的 SQL 引起。建议抓取 Slow Query Log ,针对 I/O 开销比较大(重点看全表扫描)的 SQL 进行优化。根据经验值,每个 CPU Core 一秒钟能处理 100-400MB 数据量。如果是大量的并发 I/O 操作,尽管存储的吞吐可能还没那么大,也可能会把 CPU "塞满"。

前微软头号 Blogger Robert Scoble 采访 Twitter 的几个家伙。谈及 Twitter 的一些比较严重的问题。

谁来拯救大兵 Twitter ? 前几天看到新闻说他们请了 Pivotal 实验室来解决当前存在的问题。从这几天观察来看,好像并没有什么明显进展。也或许并非一时半刻就能完成吧。今年用的最多的 Web 2.0 服务就是 Twitter 了,没有了这东西还真的有些不习惯。

Twitter 的初期设计对消息采用了 Single Instance Storage (SIS),这直接导致了消息持久化产生了数据库单点问题(?) . 每一种设计思路应该都有其理由。旁观者清也只是没介入到那个环境吧。接下来 Twitter 会做什么? Sharding ?

这个视频更像是 Twitter 不服气外界质疑而进行的宣传。其实 Twitter 的一些扩展性问题对 Web 2.0 站点来说是个绝佳的案例,有正面的成长参考,也有为错误买单的痛苦。或许这才是主要吸引我们关注它的地方。

--EOF--

1 2 3 4 5 6 7 8 9 10 11 12

关于归档

本页包含 Arch 类别下的所有文章.

Database 为下一类别.

回到 首页 查看最近发表的文章或者查看所有 归档文章.