cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-1902) Migrate cached pages during compaction
Date Tue, 29 Mar 2011 15:16:06 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012517#comment-13012517
] 

Jonathan Ellis commented on CASSANDRA-1902:
-------------------------------------------

Okay, so we *are* adding a copy by using getByteArray.  I guess that takes care of the race
conditions but it baffles me that copy + wrap can be as fast as duplicate + set position.
 (duplicate != copy.)

All the order(nativeOrder) call does is set byte order for things like the get* methods, which
all look like this:

{code}
    private long getLong(long a) {
	if (unaligned) {
	    long x = unsafe.getLong(a);
	    return (nativeByteOrder ? x : Bits.swap(x));
	}
	return Bits.getLong(a, bigEndian);
    }
{code}

And here is where unaligned gets set:
{code}
    static boolean unaligned() {
	if (unalignedKnown)
	    return unaligned;
        PrivilegedAction pa
	    = new sun.security.action.GetPropertyAction("os.arch");
        String arch = (String)AccessController.doPrivileged(pa);
	unaligned = arch.equals("i386") || arch.equals("x86") || arch.equals("x86_64")
	    || arch.equals("amd64") || arch.equals("ppc"); // Mac OS X / PPC: see Radar #3253257
	unalignedKnown = true;
	return unaligned;
    }
{code}

... so byte ordering is basically a no-op on any architecture we are likely to run on.

> Migrate cached pages during compaction 
> ---------------------------------------
>
>                 Key: CASSANDRA-1902
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1902
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 0.7.1
>            Reporter: T Jake Luciani
>            Assignee: T Jake Luciani
>             Fix For: 0.7.5, 0.8
>
>         Attachments: 0001-CASSANDRA-1902-cache-migration-impl-with-config-option.txt,
1902-formatted.txt, 1902-per-column-migration-rebase2.txt, 1902-per-column-migration.txt,
CASSANDRA-1902-v3.patch, CASSANDRA-1902-v4.patch, CASSANDRA-1902-v5.patch
>
>   Original Estimate: 32h
>          Time Spent: 56h
>  Remaining Estimate: 0h
>
> Post CASSANDRA-1470 there is an opportunity to migrate cached pages from a pre-compacted
CF during the compaction process.  This is now important since CASSANDRA-1470 caches effectively
nothing.  
> For example an active CF being compacted hurts reads since nothing is cached in the new
SSTable. 
> The purpose of this ticket then is to make sure SOME data is cached from active CFs.
This can be done my monitoring which Old SSTables are in the page cache and caching active
rows in the New SStable.
> A simpler yet similar approach is described here: http://insights.oetiker.ch/linux/fadvise/

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message