./pmemkv_bench --db=/mnt/pmem/kvstore --db_size_in_gb=1 --num=100000 --reads=100000 --key_size=5 --value_size=5 --benchmarks=readseq --threads=1
Multiple threads: 1.4 microsec/op
./pmemkv_bench --db=/mnt/pmem/kvstore --db_size_in_gb=1 --num=100000 --reads=100000 --key_size=5 --value_size=5 --benchmarks=readseq --threads=5
Thanks in advance!
--
You received this message because you are subscribed to the Google Groups "pmem" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pmem+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pmem/974a2aaa-b3c7-4aad-b081-ba0d0ee41aafn%40googlegroups.com.
Okay, that makes sense.
When I created the fsdax namespace (/dev/pmem0), I saw that /mnt/pmem was already mounted so I did not have to mount it explicitly.Is this the right way to mount it using the -o dax flag?
mount /dev/pmem0 /mnt/pmem -o daxThanks!
On Wed, Dec 8, 2021 at 1:49 AM Igor <chori...@gmail.com> wrote:
Hi,
no, it should not be so slow - at least on pmem. Can you verify if /mnt/pmem is mount with -o dax flag?
If it's not, then pmemkv will use msync to ensure data consistency which is very costly.
Best regards,
Igor
./pmemkv_basic_script --file /mnt/pmem/kvstore --threads 10
./pmemkv_bench --db=/mnt/pmem/kvstore --db_size_in_gb=10 --num=10000000 --key_size=8 --value_size=64 --engine=cmap --threads=1 --benchmarks=readseq
Note that both are using the same underlying kvstore and issuing 10M read operations.
Thanks!
./pmemkv_fill_cpp /mnt/pmem/kvstore 25 cmap 16 100
Number of elements: 66956026
Closing database
To view this discussion on the web visit https://groups.google.com/d/msgid/pmem/8e4d5c17-eec2-4849-aa8c-d45376740e1cn%40googlegroups.com.