search

thustorage / pacman

Pacman: An Efficient Compaction Approach for Log-Structured Key-Value Store on Persistent Memory
https://www.usenix.org/conference/atc22/presentation/wang-jing
43 stars 11 forks source link

The segment error issues. #3

Closed EasyLuck closed 2 years ago

EasyLuck commented 2 years ago

There is a segment error when I run the viper_bench that running on threads of service / gc : 28 / 4. Message follows:

ViperFixture/bench/50/iterations:1/real_time/threads:27 1982863 us 47334528 us 27 CompactionCPUUsage=3.63577 CompactionThroughput=439.963k items_per_second=10.0864M/s threads of service / gc : 28 / 4 25700401152 4 pool size 24509 MB, num_allocated_blocks 522876 Segmentation fault

Also , when I run the poem_rockets DB there is an error when I run the viper_bench that running on threads of service / gc : 2/ 4. Message follows:

@server:~/coding/pacman/build/benchmarks/other$ sudo ./pmem_rocksdb_bench total keys: 200000000 NUM_OPS_PER_THREAD: 20000000 NUM_WARMUP_OPS_PER_THREAD: 0 benchmark: YCSB_A VALUE_SIZE: 48 distribution: Zipf 2022-06-12T03:32:16+00:00 Running ./pmem_rocksdb_bench Run on (32 X 3500 MHz CPU s) CPU Caches: L1 Data 48 KiB (x16) L1 Instruction 32 KiB (x16) L2 Unified 1280 KiB (x16) L3 Unified 24576 KiB (x1) Load Average: 0.08, 0.05, 0.10 WARNING CPU scaling is enabled, the benchmark real time measurements may be noisy and will incur extra overhead. new dcpmm env! enable ON_DCPMM threads of service / gc : 1 / 4 recycle pmem sst!

Benchmark Time CPU Iterations UserCounters...

PMEMRocksDBFixture/bench/iterations:1/real_time/threads:1 57606974 us 57598773 us 1 items_per_second=347.18k/s new dcpmm env! enable ON_DCPMM threads of service / gc : 2 / 4 Error(</home/lucky/coding/pacman/benchmarks/other/pmem_rocksdb_bench.cpp>:86 Put): put failed Error(</home/lucky/coding/pacman/benchmarks/other/pmem_rocksdb_bench.cpp>:86 Put): put failed Aborted

I do not known is it a bug in the code?

starkwj commented 2 years ago

Hi EasyLuck,

Sorry that I cannot figure out the cause from the message you provided. There were some bugs in index (FastFair, CCEH), Viper, and our code. We have fixed some of them but there must still exist some bugs. Since these bugs are not reproduced 100%, so they are difficult to debug. However, if you find some bugs that can be reproduced frequently, you can provide us with more specific details (the script or the configuration and commands you used) or debug by yourself.

For pmem-rocksdb, the failure is probably due to the limit on open files. As rocksdb will generate many files and exceed the default limit number of open files, you should increase the limit number (e.g., ulimit -n 8192 or larger).

Thanks.