According to link, LogData has a messageBlocks member, which will copy the StringRef messages from LogCommitRequest in a block (link), but as I read the code, this member seems to have nothing to do with durability, as it is handled by TLogQueueEntryRef, it’s used only for some statistics of the size of messages. Is this not a waste of memory to copy messages, while the only usage is to get the statistics of their sizes?
messageBlocks is used to send messages to storage servers quickly. In the steady state, tlogs keep two copies of data: one in memory and one on disk. This way reading is fast. It’s a bit like an in-memory database. The disk queue is only used to recover this data if the process restarts. If the tlog queue grows (usually due to some storage server failures and them therefore not popping) it will eventually start spilling and write an index for the queued data to disk.
@markus.pilman One more question, what’s the policy to erase the memoryBlocks? will fdb consider about storage server read speed? Like if storage server havent read those memoryBlocks the log server will keep them longer, or it just erase them after those blocks are durable on disk?
It only uses memory pressure. Usually storages don’t fall this far behind because they’re slow. The reason we spill is usually because a number of storage servers have failed and therefore don’t read from tlogs at all – but in theory it could be due to a very slow storage server.
It’s also not about durability: the data is written to disk immediately. The only thing we write when we spill is an index into the log file for faster from-disk reading.
but it seems that link, messageBlocks simply got erased in updateStorage method. I didnt find anything related to memory. @markus.pilman
1 Like
updateStorage is also called for spilling. Though I have to admit I am not familiar enough with that particular code to go into detail.