Benchmark Insert 100%

[eric-haibin-lin]

Vacuum GC. No Logging is performing worse than Async Logging. (Why?)

[eric-haibin-lin]

[eric-haibin-lin]

[MattPerron]

How many backends is this?

[MattPerron]

Also, for setting the flush frequency, the parameter you are passing in is the number on the x-axis * 1000 right?

[eric-haibin-lin]

@MattPerron See the number of backend in the title of each figure. Ah, I didn't notice it's microsec, I'll re-run it.

[MattPerron]

@eric-haibin-lin Since we are using SSDs I think the appropriate flush time is probably 10s-100s of microseconds. Also, for synchronous we should be running with more backends or we won't see any performance improvement.

[MattPerron]

@eric-haibin-lin My best guess for why logging throughput is higher with logging enabled is that it is somehow reducing contention on a trashing lock (because it is calling our code)

[eric-haibin-lin]

[abhishekjoshi2]

This image is from benchmarking multiple loggers, and since has a lot of stuff, I'll summarize what I saw during these tests (all these values are for the value of "u" as 1.0, I'm not sure if that is Updates or Inserts):

• Increasing the number of loggers helps in the asynchronous logging case, because we can be I/O-bandwidth bound here
• Increasing the number of loggers does not help in the synchronous logging case, because we are not bandwidth bound there (the lines for 1, 2 and 3 loggers completely overlap each other)
• For the single logger, async case, I did not observe better performance than the no logging case (contrary to what Eric saw), but for multiple loggers, logging had better performance than no logging

[abhishekjoshi2]

100% inserts Scale factor = 1 Old ycsb 10 seconds