Way back in December, keithbostic asked why log records are aligned on 128 byte boundaries. I think my thoughts back then originally writing the log code were that if we have a lot of consolidation on a slot, and many threads writing to pieces of a memory buffer on many cores at the same time, we may get worse performance if we have cache line invalidations, false sharing, etc.

Today I ran a simple test comparing the current 128 byte record alignment with 32 bytes. I ran log-append.wtperf with 20 populate threads on the HDD AWS instance (8 vCPUs). Using 32 bytes was a big performance gain. I saw 128 byte alignment run about 50% slower on that test than 32 byte alignment. I was surprised.

I'm going to run tests to compare 16, 32, 64 and 128. I'm still concerned about false sharing, but it appears to not be the case, at least for this test.