[ https://issues.apache.org/jira/browse/CASSANDRA-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815618#comment-13815618 ]
Vijay commented on CASSANDRA-3578: ---------------------------------- Hi Benedict, archiver.maybeArchive(segment.getPath(), segment.getName()) is a blocking call and will need to be a separate thread it might involve user defined archival. {quote} sync() would mark things as flushed to disk that weren't, which would result in log messages never being persisted {quote} My understand is that.... Calling force will sync the dirty pages and if we do a concurrent writes to the same page they will be marked as dirty and will be synched in the next call, how will we loose the log messages? I still like the original approach :) of creating files (it may be just me) because of simplicity and we can be aggressive in allocator threads similar to your patch (to create empty files and deleting them). > Multithreaded commitlog > ----------------------- > > Key: CASSANDRA-3578 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3578 > Project: Cassandra > Issue Type: Improvement > Reporter: Jonathan Ellis > Assignee: Vijay > Priority: Minor > Labels: performance > Attachments: 0001-CASSANDRA-3578.patch, ComitlogStress.java, > Current-CL.png, Multi-Threded-CL.png, parallel_commit_log_2.patch > > > Brian Aker pointed out a while ago that allowing multiple threads to modify > the commitlog simultaneously (reserving space for each with a CAS first, the > way we do in the SlabAllocator.Region.allocate) can improve performance, > since you're not bottlenecking on a single thread to do all the copying and > CRC computation. > Now that we use mmap'd CommitLog segments (CASSANDRA-3411) this becomes > doable. > (moved from CASSANDRA-622, which was getting a bit muddled.) -- This message was sent by Atlassian JIRA (v6.1#6144)