There is no valid output when testing compact with db_bench tool.

[bytedance]

There is no valid output when testing compact with db_bench tool.

[ustcwelcome]

In fact compact benchmark has only one C

Thank you for your answer.
Is the ops/sec of the CompactRange operation too slow?

About Readrandom:
Thank you for your advice， I will try to find the anwer from the LOG file.

See db_bench_tool.cc line 1818 for its output, CompactRange is one opertation and this operation takes in a few seconds(it's normal because of high comsuming of compaction).
For "compact : 1445.000 micros/op 692 ops/sec;" is not correct , because you use terark-zip-table on fillrandom and compact on block-based-table, you may find from LOG like this: "error: Corruption: Bad table magic number: expected 9863518390377041911, found 1234605616436508552", so the actual compact would not happen and end quickly(that's why ops/sec is so large). We will fix this bug later.

[Layamon]

compact : 2878433.000 micros/op 0 ops/sec;
vs
compact : 1445.000 micros/op 692 ops/sec;

you think this two value is invalid, especially the first one is 0 ops/sec？Am I right?

[ustcwelcome]

0 ops/sec is right.
If you run "$$ ./db_bench --benchmarks=fillrandom --use_existing_db=0 --disable_auto_compactions=1 --sync=0 --db=/data4/liufl/terarkdb/db/ --wal_dir=/data4/liufl/terarkdb/wal/ --num=1000000000" , you should also run "
$$ ./output/db_bench --benchmarks=compact --use_existing_db=1 --db=/data4/liufl/rocksdb/_terarkdb/". Both of which use terark-zip-table.
If you want to run "$$ ./output/db_bench --benchmarks=compact --use_existing_db=1 --db=/data4/liufl/rocksdb/_terarkdb/ --use_terark_table=false" , you should add --use_terark_table=false to fillrandom benchmark also before run it.

In fact compact benchmark has only one CompactRange operation, so its ops/sec is <1.0 and its output is 0. If you run bench(fillrandom + compact) with "-use_terark_table=false" both, the same output will you find.

About Readrandom:
Maybe bulkload has some flush didn't accomplish, when you ran radrandom ,it kept on flushing so you found some write bandwidth. LOG file may anwser your question.

[yapple]

compact : 2878433.000 micros/op 0 ops/sec;
vs
compact : 1445.000 micros/op 692 ops/sec;

you think this two value is invalid, especially the first one is 0 ops/sec？Am I right?

in my opinion,
the first global compact is slow, so the first output is 0ops/sec.
the second global compact is fast because you have finished a global compact.

[FangleiLiu]

compact : 2878433.000 micros/op 0 ops/sec;
vs
compact : 1445.000 micros/op 692 ops/sec;

you think this two value is invalid, especially the first one is 0 ops/sec？Am I right?

Only the first one. Why is it so slow，no matter how much data is in the DB.

[FangleiLiu]

In fact compact benchmark has only one C

Thank you for your answer.
Is the ops/sec of the CompactRange operation too slow?

About Readrandom:
Thank you for your advice， I will try to find the anwer from the LOG file.

[FangleiLiu]

In fact compact benchmark has only one C

Thank you for your answer.
Is the ops/sec of the CompactRange operation too slow?
About Readrandom:
Thank you for your advice， I will try to find the anwer from the LOG file.

See db_bench_tool.cc line 1818 for its output, CompactRange is one opertation and this operation takes in a few seconds(it's normal because of high comsuming of compaction).
For "compact : 1445.000 micros/op 692 ops/sec;" is not correct , because you use terark-zip-table on fillrandom and compact on block-based-table, you may find from LOG like this: "error: Corruption: Bad table magic number: expected 9863518390377041911, found 1234605616436508552", so the actual compact would not happen and end quickly(that's why ops/sec is so large). We will fix this bug later.

Thanks for patiently answering my question.
Please forgive me for not knowing terarkdb/rocksdb well enough. Refer to your guidance, I will continue to read terarkdb/rocksdb code.