Tokyocabinet数据存放探秘

弄了一段时间的tokyocabinet btree结构数据库。
存储的时候发现，tokyocabinet sync同步时，先让数据存放在内存，然后对比同步文件和内存的数据，使数据达到一直。
sync()这个tc方法易用，但不好控制。
稍有不慎就会使持久化文件容量以几何级数递增。

之前自己用mina框架做了一个btree的网络链接端口，起初内存一直飙升。弄了很久都不明白。
开始以为是mina造成的，而且cpu占用率居高不下。

后来拆分测试。发现单独mina的数据传输，内存并不高，非常低。
但是tc的单独测试发现，写文件的cpu占用率特高，多线程写入的情况下，会有明显阻塞。
初步了解了jvm gc的算法，如果cpu占用率搞，gc回收内存的能力会明显下降。
为了解决这一点，修改了一下网络端口的框架结构。

把数据接受端跟数据处理端分开：
1.接受端可以接受多个socket多线程传输，而数据处理端锁定只接受从接收端的一个或不超过5个scoket传输数据。
对tc的操作，单线程写入，感觉上比多线程处理流畅，特别在同步优化文件那一刻。
优化文件，需要的cpu和内存都比较厉害。
2.tc接受数据以后，不要马上写文本。等接受一批（100-10000）数据后，再使用同步方法。
3.参照第2条，定期优化文件，这样不至于文件过大。但是数据量增大，文件虽然优化了，写入速度不会怎么改变。
4.优化同步文件后，特别在数据量在不断增大的情况下。不要以为没有回收内存，其实gc已经很努力回收(长时间观察jprofiler的统计数据证明了这一点)当你向tc取数据的时候，你会发现，内存会逐级递减。


经过一番调整，用jprofiler测试，自己搭建的网络框架，内存锁定在250m左右。
可能到实际运行的时候，内存占用量会增加，但是只会达到一个相当的稳定值。
现用于公司的队列系统，内存总量不超过600m，偶尔超过是由于同步文件造成的，等数据稳定后，内存会回到稳定值。以后再作优化，希望能把内存压制200m左右。

初学nio，以此为记。