Poor performance is due the keys not being sorted. One million partially sorted keys on my 500MHz P4 takes 2 minutes. For random keys I only get one tenth the keys stored in that same time or 100k keys in 2 minutes 18. Extrapolating with my numbers it would take a minimum of 6 hours to store 17 million unsorted keys on my system; that's ignoring that larger BTrees take longer to access. Since most of the time is taken up sorting the keys I don't see where changes in parameters will have much effect. This is the price we pay for being able to do random access recall.
The best you could do is buy a faster processor. Nevertheless, things to try are: Verify that your page size is equal to your disk page size. Set your cache size as high as possible within limits of performance for the rest of the system. Are there other users on your system? If no turn of transactions. Are you running out of memory? Look at the output from top.
In reply to Re: Questions about BerkeleyDB
by starbolin
in thread Questions about BerkeleyDB
by lihao
For: | Use: | ||
& | & | ||
< | < | ||
> | > | ||
[ | [ | ||
] | ] |