There’s one stage in InnoDB crash recovery where it reads log file, you know, this one:
InnoDB: Doing recovery: scanned up to log sequence number 354164119040 InnoDB: Doing recovery: scanned up to log sequence number 354169361920
On a machine with bigger logs it will start spending nearly 100% CPU somewhere in recv_scan_log_recs. Guess what it does…. -fno-inline builds to the rescue:
#0 mem_block_get_len at ./include/mem0mem.ic:86 #1 mem_heap_get_size at ./include/mem0mem.ic:591 #2 recv_scan_log_recs at log/log0recv.c:2727
And:
samples % symbol name 8467 72.9222 mem_heap_get_size 291 2.5062 recv_add_to_hash_table 95 0.8182 mem_block_get_len
To speak in layman’s terms, InnoDB does SUM(LENGTH(allocation)) on its relatively wide memory (tens, hundreds of thousands of entries) arena, FOR EVERY LOG SEGMENT, to make sure it didn’t run out of available 32GBs. Hehehe, lame.
As for now, I’ll just killed the check and have my recovery much much faster – finished in 3 minutes, what it wasn’t able to do in 30 before.
P.S. This is different from what I wrote before (and magic Yasufumi’s patch)
P.P.S. Now I got to learn to reuse LOG_DUMMY table during the recovery process, as it is next low hanging fruit there…
domas mituzas 