没落的dbm?
今天才第一次使用gdbm,发现在往里面放数据时,进程的内存几乎没有变化,而在取数据时,内存才慢慢变大。虽然数据文件有整整180MB,但遍历完数据后内存也才35MB。看来gdbm是直接把数据写往硬盘了,取的时候又用了一个缓存。
虽然gdbm和mdbm用的都是Per-Ake Larson的动态哈希算法,但mdbm是在共享内存里hash,而gdbm直接hash到硬盘上了,且缓存也不是共享的。这造成gdbm比mdbm读写慢很多,而且如果启动多个进程,gdbm会白白浪费内存空间。
在内存充足的情况下,当然选用mdbm,即使内存不足,也可以选用BerkeleyDB,因为bdb的缓存大小可调而且是共享的。那gdbm用在哪里呢?只能用在需要存取少量数据而对存取性能要求又很低的场合了,有这种场合吗?做为老牌存取库dbm的GNU版本,gdbm面对的是过去内存紧缺的老unix系统,而且那时候共享内存机制还不成熟,所以它就用了一个现在看来如此“弱”的存储策略。
如今大内存的机器比比皆是,在服务器领域dbm估计就此退出舞台了。
虽然gdbm和mdbm用的都是Per-Ake Larson的动态哈希算法,但mdbm是在共享内存里hash,而gdbm直接hash到硬盘上了,且缓存也不是共享的。这造成gdbm比mdbm读写慢很多,而且如果启动多个进程,gdbm会白白浪费内存空间。
在内存充足的情况下,当然选用mdbm,即使内存不足,也可以选用BerkeleyDB,因为bdb的缓存大小可调而且是共享的。那gdbm用在哪里呢?只能用在需要存取少量数据而对存取性能要求又很低的场合了,有这种场合吗?做为老牌存取库dbm的GNU版本,gdbm面对的是过去内存紧缺的老unix系统,而且那时候共享内存机制还不成熟,所以它就用了一个现在看来如此“弱”的存储策略。
如今大内存的机器比比皆是,在服务器领域dbm估计就此退出舞台了。
相关文章
- BerkeleyDB删除数据时的“内存泄漏”问题 - 04 08, 2009
- fedora 9 小集 - 01 05, 2009
- 多线程调试 - 12 17, 2008
留言: