第一步：查看是否有死锁存在，查出有数据则代表有死锁 select p.spid,c.object_name,b.session_id,b.oracle_username,b.os_user_name from v$process p,v$session a,v$locked_object b,all_objects c where p.addr=a.paddr and a.process=b.process and c.object_id=b.object_id
新人讨论二- Percolator中的两阶段提交协议分析
2011年11月18日 由 晓楚 没有评论 »Percolator是Google使用的一款基于Bigtable的、支持事务的增量索引系统，以客户端库的形式提供给用户。使用Percolator后，从页面爬取到新数据到这些数据被用户可见之间的平均延迟被缩小100倍！从技术的角度看主要有两方面改进： 1. 能够增量地处理索引（Percolator之前Google使用MapReduce批量更新索引） 2. 在并发处理的过程中能够保持一些”不变性(invariants)”，如指向同一个页面的链接等。 Percolator基于Bigtable，在实现过程中充分利用了Bigtable的单行事务特性，在Bigtable提供的单行数据原子读写的基础上Percolator实现了跨行跨表的事务特性(ACID)。Percolator实现的事务具有如下特点： 1. 利用了Bigtable的单行事务。因为Bigtable基于GFS提供了可靠的存储和原子写特性，Bigtable被选作用于实现锁服务。 2. Percolator利用了Bigtable的timestamp维来提供snapshot isolation. snapshot isolation为每一个事务提供了一个一致的快照视图。 本文重点考察Percolator中如何实现两阶段提交协议。在Percolator的论文中用银行转账的经典案例来说明Percolator是如何实现两阶段提交的，如下图： 上面的例子展示了一次成功的事务，事务执行过程中没有冲突发生，也没出现worker宕机的情形。那么，在Percolator是如何处理各种异常情况的呢？下面从代码的角度来分析整个过程： class Transaction{ struct Write { Row row; Column col; string value; }; vector<Write> writes_; // 每一个事务都有一个start timestamp // 读事务只关心[0, start_ts_]时间区间之内数据逻辑是否一致 // 写事务则需要关心[0, infinate)时间区间之内数据逻辑是否一致 int start_ts_; // 初始化当前事务的timestamp，note: 此oracle非彼Oracle Transaction() : start_ts_(oracle.GetTimestamp()) { } void Set(Write w) { [...]
Linux下pipe使用注意事项
2011年11月16日 由 褚霸 没有评论 »Linux下的pipe使用非常广泛, shell本身就大量用pipe来粘合生产者和消费者的. 我们的服务器程序通常会用pipe来做线程间的ipc通讯. 由于unix下的任何东西都是文件,只要是文件,在读取的时候,,就会设置last access time, 所以pipe也不例外., 但是这个时间对我们没有意义 如果pipe使用的非常频繁的时候会碰到由于设置访问时间导致的性能问题. 这个开销远比pipe读写的本身开销大. 相比文件读写的开销, atime微不足道,但是对pipe来讲就不同了. 这个事情是上次和多隆同学在把玩他的网络框架的时候,无意发现的. 我们来分析下pipe的这部分代码: 我们可以看到在pipe读的时候要设置 file_accessed时间的,接着: 如果文件没设置 O_NOATIME就真正动手设置atime,接着: 我们可以看出上面的流程还是比较复杂的,开销也很大. 我们来演示下: 我们可以看到touch_atime的开销很大,远比pipe的读写大. 这次把这行注释去掉: fcntl(fds[0], F_SETFL, O_NOATIME); 指示pipe在读的时候不更新atime,看下效果: 这下看不到touch_atime了,开销省了,对于高性能服务器是很重要的. 小结: 细节很重要,记得开文件open的时候设置O_NOATIME或者用fcntl搞定它. 祝玩得开心!
