NinGoo's blog

linux上大量tcp端口处于TIME_WAIT的问题

最近发现几个监控用的脚本在连接监控数据库的时候偶尔会连不上，报错：

 Couldn't connect to host:3306/tcp: IO::Socket::INET: connect: Cannot assign requested address

查看了一下发现系统中存在大量处于TIME_WAIT状态的tcp端口

$netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
TIME_WAIT 50013
ESTABLISHED 27
SYN_RECV 1

由于要监控的主机太多，监控的agent可能在短时间内创建大量连接到监控数据库(MySQL)并释放造成的。在网上查阅了一些tcp参数的相关资料，最后通过修改了几个系统内核的tcp参数缓解了该问题：

#vi /etc/sysctl.conf

net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1

#sysctl -p

其中：
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

修改完成并生效后，系统中处于TIME_WAIT状态的tcp端口数量迅速下降到100左右：

$netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
TIME_WAIT 82
ESTABLISHED 36

简单记录于此，备忘。

数据库技术大会PPT：构建高可用数据库监控系统

这两天在北京参加IT168组织的2010数据库技术大会，应该说这次大会非常的成功，场场爆满。见到了很多老朋友，认识了更多的新朋友，不亦乐乎。

今天下午第一场，我分享了一个关于数据库监控系统的topic，开场时话筒出现了些小插曲，加上发现PPT不是我后来提交给大会的最新版本，当时就有点发懵，汗就开始往外冒了。看来以后要多多练习提高演讲的水平和临场的应变控制能力了。希望我结巴的话语不至于让大家感到门票白买了。就数据库监控这个话题本身而言，我相信大部分DBA应该都是有兴趣，并且也是有自己的一些心得的，因此，我带来这个主题，一个重要的目的，是希望能起到抛砖引玉的作用，希望能有更多的DBA能去关注这方面，并且一起交流分享如何把数据库监控做到极致。如果有对数据库监控感兴趣，有想法的朋友，也非常的欢迎来杭州，和我们一起来把这个产品做得更好，或许真有一天能做成产品开源出来也是可能的。

下面是新版本的PPT，和大会上大家看到的可能有一点区别，大家如果对数据库监控有什么建议，欢迎指教。

Cassandra Commitlog

上一篇blog中，大致介绍了一下Cassandra的存储机制，通过将最新的写操作放在内存中的Memtable，然后定期刷新到磁盘持久化为SSTable，Cassandra将随机写操作转换成了顺序写操作，这可以提升IO性能。

最新写入的脏数据是在内存Memtable表中，因此必须有机制来确保异常情况下，能够将内存中的数据恢复出来。和关系型数据库系统一样，Cassandra也是采用的先写日志再写数据的方式，其日志称之为Commitlog。

和Memtable/SSTable不一样的是，Commitlog是server级别的，不是Column Family级别的。每个Commitlog文件的大小是固定的，称之为一个Commitlog Segment，目前版本(0.5.1)中，这个大小是128MB，这是硬编码在代码(src\java\org\apache\cassandra\db\Commitlog.java)中的。当一个Commitlog文件写满以后，会新建一个的文件。当旧的Commitlog文件不再需要时，会自动清除。

每个Commitlog文件(Segment)都有一个固定大小（大小根据Column Family的数目而定）的CommitlogHeader结构，其中有两个重要的数组，每一个Column Family在这两个数组中都存在一个对应的元素。其中一个是位图数组(BitSet dirty)，如果Column Family对应的Memtable中有脏数据，则置为1，否则为0，这在恢复的时候可以指出哪些Column Family是需要利用Commitlog进行恢复的。另外一个是整数数组(int[] lastFlushedAt)，保存的是Column Family在上一次Flush时日志的偏移位置，恢复时则可以从这个位置读取Commitlog记录。通过这两个数组结构，Cassandra可以在异常重启服务的时候根据持久化的SSTable和Commitlog重构内存中Memtable的内容，也就是类似Oracle等关系型数据库的实例恢复。

当Memtable flush到磁盘的SStable时，会将所有Commitlog文件的dirty数组对应的位清零，而在Commitlog达到大小限制创建新的文件时，dirty数组会从上一个文件中继承过来。如果一个Commitlog文件的dirty数组全部被清零，则表示这个Commitlog在恢复的时候不再需要，可以被清除。因此，在恢复的时候，所有的磁盘上存在的Commitlog文件都是需要的。

参考文章：
[1].http://wiki.apache.org/cassandra/ArchitectureCommitLog

Cassandra存储机制

在2009年兴起的NoSQL运动中，Cassandra是其中重要的一个分布式key-value数据库产品，由Facebook在2008年开源，目前是Apache的顶级项目。最近twitter的一篇声明，表示将从MySQL迁移到Cassandra，更让其声名大振。Cassandra是结合了Google Bigtable的数据模型和Amazon Dynamo高可用框架的一个产品。其数据模型可以参考张瑞的blog。

值得说一下的是Cassandra的存储机制，也是借鉴了Bigtable的设计，采用Memtable和SSTable的方式。和关系数据库一样，Cassandra在写数据之前，也需要先记录日志，称之为commitlog，然后数据才会写入到Column Family对应的Memtable中，并且Memtable中的内容是按照key排序好的。Memtable是一种内存结构，满足一定条件后批量刷新到磁盘上，存储为SSTable。这种机制，相当于缓存写回机制(Write-back Cache)，优势在于将随机IO写变成顺序IO写，降低大量的写操作对于存储系统的压力。SSTable一旦完成写入，就不可变更，只能读取。下一次Memtable需要刷新到一个新的SSTable文件中。所以对于Cassandra来说，可以认为只有顺序写，没有随机写操作。

因为SSTable数据不可更新，可能导致同一个Column Family的数据存储在多个SSTable中，这时查询数据时，需要去合并读取Column Family所有的SSTable和Memtable，这样到一个Column Family的数量很大的时候，可能导致查询效率严重下降。因此需要有一种机制能快速定位查询的Key落在哪些SSTable中，而不需要去读取合并所有的SSTable。Cassandra采用的是Bloom Filter算法，通过多个hash函数将key映射到一个位图中，来快速判断这个key属于哪个SSTable。关于Bloom Filter，有兴趣的可以去看看参考文章4,5和6。

为了避免大量SSTable带来的性能影响，Cassandra也提供一种定期将多个SSTable合并成一个新的SSTable的机制，因为每个SSTable中的key都是已经排序好的，因此只需要做一次合并排序就可以完成该任务，代价还是可以接受的。所以在Cassandra的数据存储目录中，可以看到三种类型的文件，格式类似于：

• Column Family Name-序号-Data.db
• Column Family Name-序号-Filter.db
• Column Family Name-序号-index.db

其中Data.db文件是SSTable数据文件，SSTable是Sorted Strings Table的缩写，按照key排序后存储key/value键值字符串。index.db是索引文件，保存的是每个key在数据文件中的偏移位置，而Filter.db则是Bloom Filter算法生产的映射文件。

参考文章：
[1].http://wiki.apache.org/cassandra/ArchitectureOverview
[2].http://wiki.apache.org/cassandra/MemtableSSTable
[3].http://wiki.apache.org/cassandra/ArchitectureSSTable
[4].http://blog.csdn.net/jiaomeng/archive/2007/01/27/1495500.aspx
[5].http://www.hellodba.net/2009/04/bloom_filter.html
[6].http://www.googlechinablog.com/2007/07/bloom-filter.html
[7].http://labs.google.com/papers/bigtable.html

常用标签： oracle life MySQL Oracle11g blog dba 新特性 oow2009 oow linux

最新评论 | Recent comments

订阅更新 | Subscribe

最近文章 | Recent posts

站点信息 | Statistics