Cassandra1.1.2 Tuning Notes-

A data storage project that decides to use Cassandra as a data storage server, taking into account Cassandra's outstanding write performance.
Several http://www.aliyun.com/zixun/aggregation/14356.html "> Performance tests were performed before use: Write performance and read performance respectively.
Version: 1.1.2. Server cluster: Three servers, 8 cores, 8G RAM, same LAN.

Results：
Write performance test, replication factor (Replication_factor) = 2, successfully write a can, a total of 4 hours of testing, write more than 100 million records, an average of more than 6,400 per second.
Read the performance test, using the two-level index to find, a successful acquisition can be, on average, more than 900 records per second.

-------------------------------------the above results need to be further optimized------------------------------------

The main aspects of the record reduction:
1 table creation (using CQL), configure related parameters:

Among them, the compression can reduce the disk usage, has certain enhancement effect to the reading and writing efficiency; caching set to keys_only, only keyword caching, it should be noted that although set to all can cache row data, hit reduced two times lookup, but due to the large amount of data, Memory is limited, so queries are inefficient.
2 set two physical hard disk, the path corresponding to Data_file_directories and commitlog_directory
3) Cassandra.yaml Commitlog_directory set to 16.
4 concurrent_writes:64 (does not compare changes before and after write performance, uncertain optimization effect)
Cassandra.yaml, the remaining parameters are unchanged.

Problem：
1 when the Cassandra closed, memory footprint up to 5G, not clear specific reasons.
2 The use of primary key query, performance than the second key faster than the 1:30 point, the reason is still to be studied.

--------------------------------------------------------Follow-up Optimization-------------------------------------------------------

Connect:

Some adjustments have been made these days,

1) Modify JDK, use jdk7,64 bit instead.

2 table Creation (using CQL), configuration related parameters modified to:

Test results:

Write an average of more than 8,400 per second.
Read an average of more than 2000 records per second.

have certain promotion.

PS: For the first question above, I use the top command to view the following results:

I understand incorrectly, used does not mean how much to use, but the amount of memory currently controllable by the Linux kernel, which is different from windows.