Xiang
Xiang
@djherbis https://github.com/ongardie/diskbenchmark maybe you can try this to bench the disk io. boltdb does two fdatasyncs per writes I think. So you can get the ideal rough number if everything...
@djherbis The result seems to be conflict with your experimental on RAM disk. If IO is an issue, why moving to RAM disk is even slower than a direct write?
> Because its not the disk speed that's the problem, Then why moving from disk to RAM disk does reduce the time from 5ms to 400us?
@tvmaly You can create a tx, and insert multiple kv pairs to batch updates. See https://github.com/boltdb/bolt/blob/master/cmd/bolt/main.go#L1042-L1065 for example.
@benbjohnson I have a related question about `batching`. I can put a WAL in front of blot to mitigate the append only B-tree write issue by reordering and batching. But...
> It can't do reordering since the order of operations in a batch may still matter to the application. It is also designed for multiple writers case. For the WAL...
@cep21 1.5 would set GOMAXPROCs to the number of your cores instead of 1. I guess that helped to "improve" the performance a lot.
@cep21 Have you tried to find the root cause?
@cep21 Please check https://github.com/boltdb/bolt/blob/master/db.go#L860-L868. You can give it a large mmap size. It won't grow on disk size, just use more virtual memory. It wont be a problem in general.
@cep21 Well... I cannot answer this question for you. It is your database, and you are the best person to guess the size. If you do not have an expectation...