Lmdb

[hyc]

Two tweaks - populate was extremely slow because it's fsyncing after every transaction, changed it to use Nosync.

ReadRandomLmdb seemed to be bottlenecked, changed to a reusable Read txn.

[hyc]

Results with valsz 128

WROTE 10008000 KEYS
        Command being timed: "./populate --kv badger --dir /mnt/data/b1 --valsz 128"
        User time (seconds): 170.90 
        System time (seconds): 6.27 
        Percent of CPU this job got: 154%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 1:54.64
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 2485640 
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 293290
        Voluntary context switches: 436303 
        Involuntary context switches: 28971
        Swaps: 0 
        File system inputs: 112
        File system outputs: 4552640
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

WROTE 10008000 KEYS
        Command being timed: "./populate --kv rocksdb --dir /mnt/data/b1 --valsz 128"
        User time (seconds): 92.97
        System time (seconds): 13.65
        Percent of CPU this job got: 156%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 1:08.12
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 268184  
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 2
        Minor (reclaiming a frame) page faults: 96926
        Voluntary context switches: 265754 
        Involuntary context switches: 124529
        Swaps: 0 
        File system inputs: 856
        File system outputs: 8229312
        Socket messages sent: 0
        Socket messages received: 0 
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

WROTE 10008000 KEYS
        Command being timed: "./populate --kv lmdb --dir /mnt/data/b1 --valsz 128"
        User time (seconds): 75.97
        System time (seconds): 64.76
        Percent of CPU this job got: 111%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 2:06.59
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 1531344
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 1
        Minor (reclaiming a frame) page faults: 36378
        Voluntary context switches: 363953
        Involuntary context switches: 21009
        Swaps: 0
        File system inputs: 0
        File system outputs: 24816312
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

[hyc]

go test --bench BenchmarkReadRandomRocks --valsz 128 --dir /mnt/data/b1 --timeout 10m --benchtime 3m
BenchmarkReadRandomRocks/read-random-rocks-4             5000000             45952 ns/op
PASS
ok      github.com/dgraph-io/badger-bench       278.383s

go test --bench BenchmarkReadRandomBadger --valsz 128 --dir /mnt/data/b1 --timeout 10m --benchtime 3m
/mnt/data/b1/badger
BenchmarkReadRandomBadger/read-random-badger-4          100000000             3991 ns/op
PASS
ok      github.com/dgraph-io/badger-bench       403.743s

go test --bench BenchmarkReadRandomLmdb --valsz 128 --dir /mnt/data/b1 --timeout 10m --benchtime 3m
BenchmarkReadRandomLmdb/read-random-lmdb-4              200000000             1614 ns/op
PASS
ok      github.com/dgraph-io/badger-bench       482.850s

[manishrjain]

Thanks, @hyc . Merged.

[deepakjois]

Hi @hyc

I have cherry-picked these commits onto master branch now as 8b9bed8 and 2b66ab3.

I realise that we were not reusing the txn for the read, and your change modified the code to do that. However, I thought it would be cleaner to keep the invocation to lmdb.View() and run the reads within it. I have modified the code to look like below, and I believe it is doing the same thing your code did.

err := lmdbEnv.View(func(txn *lmdb.Txn) error {
	txn.RawRead = true
	for pb.Next() {
		key := newKey()
		v, err := txn.Get(lmdbDBI, key)
		if lmdb.IsNotFound(err) {
			c.notFound++
			continue
		} else if err != nil {
			c.errored++
			continue
		}
		y.AssertTruef(len(v) == *flagValueSize, "Assertion failed. value size is %d, expected %d", len(v), *flagValueSize)
		c.found++
	}
	return nil
})
if err != nil {
	y.Check(err)
}

[hyc]

No, it's not the same, but it's not clear what your test's intent really is.

If you use a single transaction like this, then all of your reads are using that same snapshot. Any writes that happened after the transaction began will be invisible. Using Reset/Renew as my patch did means you're always getting the latest view of the DB, so you'd be seeing the effects of concurrent writers.

[deepakjois]

Yes, you are right that your patch would make the read see the effects of concurrent writers. I missed that.

However, this specific benchmark is meant to run against a database that has been pre-populated. So we don’t really need to worry about the effects of concurrent writes. It should be fine reading from the same snapshot.

[hyc]

Ok, that's cool.