分类归档: Tech.Memo

AIX 6 新特性关注点

IBM 为配合 Power 6 CPU 而推出的 AIX 6 即将正式发布。在 AIX 5 的基础上学习 AIX 6，最好的入手点就是 IBM AIX Version 6.1 Differences Guide（PDF) 了。匆匆看了一下，记录几个比较感兴趣的点。

JFS2 的新特性

关掉 JFS2 的 Log: mount 的时候 log=NULL 可以关掉 JFS2 的日志。在一些特定的场合(如：恢复)会比较有用。另外一个特性是内部快照(internal snapshot)，即可以在同一文件系统上创建快照。

限制每进程的线程数

在以前的版本中这是做不到的，AIX 6 可以通过静态或者动态的方式修改每个进程的线程数量。属性由RLIMIT_THREADS 与 RLIMIT_NPROC 值控制. ulimit -a 可以查看值。

线程环境变量 pthread 1:1

pthread 也就是 POSIX Threads，AIX 6 对 “contention scope” 的 m:n 做了调整。

AIX 5 上跑 Oracle RDBMS, Oracle 建议 export AIXTHREAD_SCOPE=S. 看来以后不用这么费事了。

补充一下这个 M:N ，一共有三种:

M:1 (Library) 模型：M:1 (库模型）,每个进程都有一个核心线程。竞争范围：process(本地)
1:1 (Kernel) 模型：每个用户线程都有自己的核心线程。竞争范围：system (全局)
M:N (Hybrid) 模型：M 个用户线程对应 N 个 Kernel 线程。默认是 8:1(AIXTHREAD_MNRATIO) 。竞争范围：以上两种方式混合)

这个变化多少了反映了 IBM 在计算模式变化的方向上的倾斜。

动态虚拟内存 Page Size

AIX 6 支持四种值，4k、64K、16M、64GB. 一个新的需要知道的缩写：Dynamic variable page size support (VPSS)。VMM 可以动态修改 Page size ; 大的 page size 对应用是透明的(是不是会触发Bug，鬼才知道); 硬件支持(Power 6)的情况下 VPSS 是激活的。

”限制性可调“的核心参数

AIX 6 对一些比较关键的参数划了个类别：”限制性可调“(restriccted tunables) ，调整的时候会警告用户, 建议在厂商指导下进行:)

其他

安装程序更新了，现在是……图形化安装了

–EOF–

Amazon 的 Dynamo 架构

我在 DBAnotes.net 上记录过不少比较大的网站架构分析(eg: eBay [1], eBay [2]) ，Amazon 一直找不到太多的资料。国庆期间读到了一篇关于 Amazon Dynamo 的论文，非常精彩。Amazon Dynamo 这个高可用、可扩展存储体系支撑了Amazon 不少核心服务.

先看一个示意图:

从上图可以看出，Amazon 的架构是完全的分布式，去中心化。存储层也做到了分布式。

Dynamo 概述

Dynamo 的可扩展性和可用性采用的都比较成熟的技术，数据分区并用改进的一致性哈希(consistent hashing)方式进行复制，利用数据对象的版本化实现一致性。复制时因为更新产生的一致性问题的维护采取类似 quorum 的机制以及去中心化的复制同步协议。 Dynamo 是完全去中心化的系统，人工管理工作很小。

强调一下 Dynamo 的”额外”特点：
1) 总是可写
2) 可以根据应用类型优化

关键词

Key: Key 唯一代表一个数据对象，对该数据对象的读写操通过 Key 来完成.
节点(node)：通常是一台自带硬盘的主机。每个节点有三个 Java 写的组件：请求协调器(request coordination)、成员与失败检测、本地持久引擎(local persistence engine)
实例(instance)；每个实例由一组节点组成，从应用的角度看，实例提供 IO 能力。一个实例上的节点可能位于不同的数据中心内, 这样一个数据中心出问题也不会导致数据丢失。

上面提到的本地持久引擎支持不同的存储引擎。Dynamo 上最主要的引擎是 Berkeley Database Transactional Data Store(存储处理数百K的对象更为适合），其他还有 BDB Java Edition、MySQL 以及一致性内存 Cache 等等。

三个关键参数 (N,R,W)

第一个关键参数是 N，这个 N 指的是数据对象将被复制到 N 台主机上，N 在 Dynamo 实例级别配置，协调器将负责把数据复制到 N-1 个节点上。N 的典型值设置为 3.

复制中的一致性，采用类似于 Quorum 系统的一致性协议实现。这个协议有两个关键值：R 与 W。R 代表一次成功的读取操作中最小参与节点数量，W 代表一次成功的写操作中最小参与节点数量。R + W>N ，则会产生类似 quorum 的效果。该模型中的读(写)延迟由最慢的 R(W)复制决定，为得到比较小的延迟，R 和 W 有的时候的和又设置比 N 小。

(N,R,W) 的值典型设置为 (3, 2 ,2),兼顾性能与可用性。R 和 W 直接影响性能、扩展性、一致性，如果 W 设置为 1，则一个实例中只要有一个节点可用，也不会影响写操作，如果 R 设置为 1 ，只要有一个节点可用，也不会影响读请求，R 和 W 值过小则影响一致性，过大也不好，这两个值要平衡。对于这套系统的典型的 SLA 要求 99.9% 的读写操作在 300ms 内完成。

–待续–

更多阅读：Dynamo学习 — http://donghao.org/2008/10/dynamoni.html

如何确保 Shell 脚本只有一个实例运行

在做维护的时候，经常要写一些脚本定期检查一些状态信息，而比较糟的时候可能该脚本在执行周期内没完成，接着第二个脚本又开始跑了。如何确保 Shell 脚本只有一个实例运行就成了一个比较有意思的话题。

必需要承认，要做到 100% 的完美可能需要长篇大论才可以做到。如果对于粒度要求不高，这里总结两个粗糙的方法。

一个是在脚本执行的时候判断某个文件的存在，如果不存在，则 touch 创建该文件(该文件看作一个”占座”文件)，脚本执行完毕的时候删掉。第二个进程如果启动，判断有该文件存在，则退出或者是 sleep 几秒钟重新判断。这个方法的关键是在删掉”占座”文件的处理方式上。必需要考虑到程序异常、被 Kill 等多个情况。根据需要 trap 搞一下。

trap 和 kill 命令的 -l 参数能够列出你想要的内容

第二个方法是过滤脚本的名字(当然最好把脚本起个独特一点容易过滤的名字)，计数，如果存在一个或者多个 instance , 则退出或者 sleep 等待。否则执行脚本。这个方法最简单，但是移植性似乎要差一点，需要考虑不同平台或 Shell 上的表现。

这两个方法都太粗糙了，经不起考究，但是对于 99% 的系统可能都足够用了。反过来说，如果一个系统对于脚本运行的粒度要求非常高，需要考虑到操作的原子性，那么 Shell 或许并不适合完成这个任务。

解决问题就好，过分炫技不可取。

–EOF–

FeedLounge 使用 PostgreSQL 的经验

这是我唯一看到的 Web 2.0 公司使用 PostgreSQL 的，可惜还失败了。

FeedLounge 是一个提供在线 RSS Reader 的站点。已经在今年 6 月 1 日黯然宣布失败。这里不去讨论他们失败的各种原因，只说说从他们 Blog 上看来的关于他们选择数据库的经验。

FeedLounge 在数据库的使用上路线是这样的：

MySQL(MyISAM) --> MySQL(InnoDB) --> PostgreSQL

最初是 MyISAM 方式，迁移到 InnoDB ，数据库从大约 1G 膨胀超出了 10G，而且发现引发了新的性能问题，经过尝试发现不能解决后，迁移到 PostgreSQL，总存储从 InnoDB 方式的 34G 缩小到 9.6G,而且，恢复时间也只是原来的大约 1/5 (导出用 Mysqldump,载入用 psql ). 此外，关于内存利用方式上也有一些差异, MySQL : innodb_buffer_pool 6GB + O_DIRECT flush, PostgreSQL 设置上限 2G，只用了 1.2 G。遗憾的是，看不到切换前后性能数据更为详细的对比。

FeedLounge 当时每天要处理的事务量：每天超过 400 万次查询，超过 200 万次的更新/插入操作，高峰期每秒钟有 2000 个更新/插入操作(这应该是批处理阶段)。硬件如何呢? 数据库服务器的硬件：两路 Opteron CPU，8 GB 内存， 6 SATA 7200RPM 16MB 硬盘， RAID 5 ，控制器有 128M. 可以看出来了吧， 7200 转的硬盘 + RAID 5 根本不适合这样的应用。从这一点上说，数据库类型切换其实解决不了本质的问题。

另外看到的有趣参考信息：

FeedDigest 在当时每天有超过 400 万次的查询，超过 200 万次插入，机器硬件只用了双奔四 CPU(2.8GHz) ，1G内存

–EOF–