불라자드 베타 테스터 인증

와 와 불라자드 베타 테스터가 되었으니 이것은 가문의 영광이 아닌기...!!

YG new girl group, their official debut is confirmed next year January.

YG’s new girl group is confirmed their debut is January, next year.

One of the most big K-pop company YG’s Yang Hyun-Seok says to Star News their debut is January next year.

Yang Hyun-Seok says “G-Dragon is occupying all producing of their album but he is performing his solo album so it is little bit delayed” and “This month has Epic High and Lee Hai’s album release and next month is for 2NE1 and Tae-Yang. So new girl’s debut is next year”

Yang Hyun-Seok says “New girl is YG’s brand new so we start next year with this girls”.

Formerly YG has announed five member of new girl group in their high teens in their blog YG Life.

Last 2010, Super Star K2 6 finalist Kim Eun-bi born in 1993, Super Star K3’s US finalist Yuna Kim born in 1994, Kim Jeni who showed beautiful figure and one more mistery girl who showed her excellent dance technique and caucasian and Korean hybrid girl is the girls.

YG is not showing more detailed feature of the girls but it is after 2009’s 2NE1 debut so it is interested by many people.

And YG don’t talk about final member number and other things.

YG Mystery girl Kim Jenny, innocent beauty and powerful rap, reversal attraction is announced.

Kim Jenny as a member of new girl group in YG, she revealed her reversal attraction.

Kim Jenny appeared in YG official blog, YG Life. A video titled as 'YG Trainee Jenne Kim' showed mystery girl Kim Jenny's fast rap performance.

Kim Jenny viewed cute and powerful attraction as various her charm. In front of vivid color, she showed teenager's cheerful attraction. 

And she also showed G-Dragon's hair style. She showed available language as English and Japanese so she showed English rap.

Kim Jenny is heroine in G-Dragon's 'That XX' music video. YG Entertainment chose her because her style is going well with G-Dragon's music. The music is revealed on 1st of September.

And Kim Jenny's YG new girl group is debut on October. This girl group is 3 year difference from 2NE1 in YG. And contains Mnet Super Star's Kim Eunbim, Super Star 3's Yuna Kim and 1995 born 16 years old hybrid member.

Rap performance is revealed by Kim Jenny. Mystery girl is unveiled now.

Kim Jenny's rap capability is revealed.

YG entertainment announced 'YG Trainee Jenny Kim' video in official blog on 30th of August.

In the video pictures of Jenny and rap performances are contained. So far, no informations are revealed so Jenny Kim is known as mystery girl.

She unveiled cute and lovely girl's attractive forms in the beginning of video but she also revealed her rap performance in the end of video. She showed fancy style of shirts and beanie.

People also say about YG's Girl's generation new girl group's debut. Kim Jenny also appeared in G-Dragon's new single 'That XX' music video. YG's Gilr's generation also has Mnet super star's Kim Eunbi and MBC Great Born's Yuna Kim and it is 9 members.

Kim Jenny is also known for her 3 language skill.

덕의 직업을 가지다...

이제 YG에서 새 걸그룹이 나온다고 하니...
이에따라 덕을 키우기 위하여 이에 관련한 직업을 가지게 되었으니...

Blogger Admin, Designer Admin 이라는 이름으로 YG 새 걸그룹에 대한 기사를
영문으로 번역하여 블로그에 올려주는 일을 정식으로 하고 있습니다.

ygnewgirl.wordpress.com 을 주목해 주세요.

벌써 내 이름이 달린 기사가 나왔습니다.

Cassandra (11/12)

1. 퍼포먼스 튜닝

이 챕터에서 우리는 카산드라가 퍼포먼스를 낫게 하기 위해서 어떻게 튜닝하는지 살펴본다. 설정 파일에서 다양한 셋팅이 우리가 이것을 하게 돕는다. 우리는 하드웨어 선택과 설정에의 몇가지 포인트를 보여준다. 카산드라 설정 파일에서 몇 가지 독립된 설정이 있다. 그럼에도 디폴트가 종종 적당하다. 당신이 그 디폴트를 바꿔야 할 몇 가지 환경이 있을 수는 있다. 이 챕터에서 그것들중 몇가지를 살펴본다.
일반적인 법칙으로 클러스터에 단지 노드를 추가하는 것이 퍼포먼스를 더 나이지게 하지는 않는다는 것을 기억해야 한다. 당신은 클라이언트로부터 모든 노드로 트래픽을 보내야 한다. 그리고 데이터를 적당히 복사할 필요가 있다. 클라이언트의 요청을 재배분하지 않는다면 새로운 노드는 잠깐동안 멍하니 있게된다.

우리는 또한 카산드라와 함께 발매되는 Python 스트레스 테스트 도구를 어떻게 사용하는지 볼것이며 카산드라에 적당한 로드를 수행해서 스트레스 테스트 수행 환경에서 어떻게 행동하는지 볼 것이다. 그리고 우리는 카산드라를 대략 튠하고 단계적인 환경에서 실행할 준비가 되었다고 확신할 수 있다.

1.1. 데이터 저장소

카산드라가 업데이트 동작을 다루는 부분동작으로서 쓰기를 하는 두 개의 파일 셋트가 있다. 그것은 commit log와 데이터 파일이다. 그것들의 설정을 하는동안 그것들을 어떻게 다루는지 이해하기 위해서 둘의 다른 목적이 고려되어야 한다.

Commit log는 일시적인 저장소처럼 생각되어질 수 있다. 카산드라가 업데이트를 받음에 따라 모든 쓰기 값은 commit log에 raw한 순차적인 파일에 덭붙여지는 것처럼 바로바로 씌어지게 된다. 당신이 데이터베이스를 셧다운하거나 뜻하지 않게 다운되어도 commit log는 데이터가 없어지지 않도록 보장한다. 그것은 당신이 노드를 시작하였을 때 commit log가 다시 불려지기 때문이다. 사실은 commit log가 읽혀지는 유일한 시간이다. 클라이언트는 그것을 읽지 않는다. 그러나 일반적인 commit log 로는 쓰기는 멈춘다. 그래서 그것은 클라이언트가 쓰기가 끝날 때까지 기다리도록 요청하여 퍼포먼스에 치명적인 영향을 준다.

데이터 파일은 Sorted String Tables (SSTables) 를 표현한다. Commit log와는 달리 데이터는 이 파일에 비동기적으로 씌어진다. SSTable 은 주된 압축 동안에 공간을 늘이기 위해서 주기적으로 합쳐진다. 이것을 하기 위하여 카산드라는 키를 합치고 컬럼을 융합하며 tombstone을 지운다.

읽기 동작은 메모리안의 캐쉬를 참조할 수 있으며 이 경우에는 직접적으로 디스크에있는 데이터 파일에 직접적으로 갈 필요가 없다. 당신이 만약 카산드라에게 몇 기가바이트의 메모리를 허락한다면 행 캐쉬와 키 캐쉬가 접근될 때 퍼포먼스를 매우 많이 향상할수 있다.

Commit log는 주기적으로 제거된다. 그것은 성공적인 flush가 추가된 데이터를 그에 할당된 데이터 파일에 flush 했을 때 따르는 일이다. 이런 이유로 commit log는 데이터 파일의 사이즈만큼 커지지 않는다. 그래서 디스크가 그만큼 클 필요가 없다. 이것은 하드웨어를 고를 때 고려되어 져야 할 일이다. 예를 들어, 만약 카산드라가 flush를 실행하면 당신은 서버로그에서 아래와 같은 것을 보게된다.

INFO 18:26:11,497 Enqueuing flush of Memtable-LocationInfo@26830618(52 bytes, 2

operations)

INFO 18:26:11,497 Writing Memtable-LocationInfo@26830618(52 bytes, 2 operations)

INFO 18:26:11,732 Completed flushing /var/lib/cassandra/data/system/

LocationInfo-2-Data.db

INFO 18:26:11,732 Discarding obsolete commit log:

CommitLogSegment(/var/lib/cassandra/commitlog/CommitLog-1278894011530.log)

그리고 당신이 commit log 디렉토리를 확인하면 그 파일은 지워졌다.

디폴트로 commit log와 데이터 파일은 아래의 위치에 저장되어 진다.

/var/lib/cassandra/commitlog

/var/lib/cassandra/data

당신은 이 값을 바꾸어서 데이터 파일과 commit log를 다른 위치에 저장할 수 있다. 당신은 당신이 원한다면 여러 개의 데이터 파일 디렉토리를 지정할 수 있다.

테스트를 위해서 이 위치를 바꿀 필요는 느끼지 못할 수도 있다. 그러나 데이터 파일과 commit log를 퍼포먼스를 위해서 하드 디스크의 다른 위치에 각각 저장하는 것을 추천한다. 카산드라는 다른 많은 데이터베이스처럼 특히 하드 디스크와 CPU의 속도에 영향을 받는다. 그래서 QA와 생산 환경에서 가장 빠른 디스크를 가지는 것을 확인하라. 그리고 적어도 두개를 두어 commit log와 데이터 파일이 IO를 위해 서로 경쟁하지는 않도록 하라. 한 개나 두개의 매우 빠른 프로세서를 가진것보다도 여러 개의 프로세싱 코어를 가지는 것이 더 중요하다.

1.2. Reply Timeout

Reply timeout은 어떤 요청이 실패했다고 판단하기 전에 얼마나 오랫동안 노드가 다른 노드의 대답을 기다리는지 셋팅하는 것이다. 이것은 관계형 데이터베이스와 메시징 시스템에 공통적인 셋팅이다. 이 값은 RpcTimeoutInMillis 요소에 의해 셋팅이 된다. 디폴트로 5,000 즉 5초이다.

1.3. Commit Logs

당신은 commit log가 새로운 값을 더하는 것을 멈추거나 또는 또다른 파일을 만드는 것을 그만하기 전에 어느 정도 크기까지 계속 커질 수 있는지 설정할 수 있다. 이것은 Log4J에서 log rotation을 설정하는 것과 비슷하다.

이 값은 CommitLogRotationThresholdInMB 요소로 정해진다. 디폴트로 이 값은 128MB이다.

Commit log에 관련된 다른 셋팅은 동기화 동작이다. 이것은 commitlog_sync 요소에 의해서 표현된다. 이것을 위해서는 두가지 가능한 셋팅이 있는데, 그것은 periodic 과 batch 이다. Periodic은 디폴트 값이다. 그리고 서버가 지정된 인터벌을 가지고 쓰기를 한다는 것을 의미한다. 서버가 쓰기를 주기적으로 하도록 설정이 되었을 때 당신은 잠재적으로 데이터를 잊어버릴 수 있는데 그것은 쓰기 캐쉬에서 디스크로 싱크가 되지 않았기 때문이다.

당신의 카산드라 클러스터에 내구성을 보장하기 위해서 당신은 이 셋팅을 살펴보기 원할 수 있다.

당신이 만약 commit log 셋팅을 batch로 하면 그것은 쓰기가 디스크에 싱크가 될 때까지 멈추어 기다린다. 이것은 분명히 퍼포먼스에 부정적인 영향이 있다.

당신은 설정 어트리뷰트의 값을 periodic 에서 batch로 바꿀수 있다. 그러면 카산드라는 쓰기 동작을 알기전에 디스크에 flush를 할 것이다. 이 값을 바꾸는 것은 어느 정도의 트레이드 오프가 있어 퍼포먼스에 영향을 미친다. 카산드라에게 더 곧바로 쓰도록 시키는 것은 그것이 그 자원을 알아서 관리하는 것의 자유도를 조금 빼앗는다. 당신이 commitlog_sync를 batch로 셋팅하면 CommitLogSyncBatchWindowInMS 에 적당한 값을 주어야 한다. 여기서 MS는 각 sync 사이의 밀리세컨드 값이다. 거기에 더해 이것은 쓰기의 복사본을 사용할 때 일반적으로 여러 개의 노드가 있는 클러스터에 필요하지 않다. 그것은 복사본은 정의대로 쓰기는 다른 노드가 그것을 가질때까지 알려지지 않는다는 것을 의미하기 때문이다.

당신이 batch 모드를 사용하기로 결정하였다면 당신은 아마도 commit log를 분리하여 각 다른 디바이스에 두고 퍼포먼스 영향을 완화하기 원할수 있다. 당신이 그것을 실행하지는 않아도 SSTable 로부터 각 별개의 디스크에 분리하는 것은 좋은 아이디어이다.

1.4. Memtables

각 컬럼군은 관계된 한 개의 memtable을 가지고 있다. Memtable을 다루기 위해서 몇 개의 셋팅이 있다. SSTable 처럼 memtable이 디스크에 flush 되기 전에 어느 사이즈까지 커질 수 있는 가는 MemtableSizeInMB 요소에 의해 설정된다. 이 값은 memtable 자체의 메모리에서의 사이즈에 기반한다는 것을 기억하라. 그리고 컬럼 인덱싱과 관련된 오버헤드 때문에 더 커질 힙의 사용이 아니다.

당신은 이 셋팅을 MemtableObjectCountInMillions 와 균형을 맞추기 원할 것이다. 그것은 flush되기 전에 memtable에 저장이 될 컬럼의 숫자값의 threshold를 설정한다.

관련된 설정은 memtable_throughput_in_mb이다. 이것은 memtable이 SSTable과 같이 디스크에 flush 되기전에 한 개의 memtable에 저장이 되는 가장 큰 컬럼의 숫자를 참조한다. 디폴트 값은 0.3 이며 대략 333,000 컬럼이다.

당신은 또한 memtable이 디스크에 flush된 후에 얼마나 오랫동안 메모리에 보관하는지 설정할 수 있다. 이 값은 memtable_flush_after_mins 요소로 셋팅된다. Flush가 수행이 되었을 때 flush 버퍼에 쓰고 당신은 그 버퍼의 크기를 flush_data_buffer_size_in_mb 로 설정할 수 있다.

Memtable을 튜닝하는 다른 요소는 memtable_flush_writers 이다. 이 셋팅은 디폴트값은 1이고 필요할 때 memtable을 쓰는 쓰레드의 숫자를 나타낸다. 당신이 만약 매우 큰 힙을 가진다면 이 카운트를 높게하여 퍼포먼스를 향상시킬수있다. 이 쓰레드는 디스크 I/O 시에 막혀져있다.

1.5. Concurrency

카산드라는 읽기 퍼포먼스보다 쓰기 퍼포먼스가 좋다는 점에서 많은 데이터 저장소와는 다르다. 얼마나 많은 쓰레드가 읽기와 쓰기 동작을 수행하는지 관련된 두가지 설정이 있다. Concurrent_reads 와 concurrent_writes 이다. 일반적으로 카산드라에의해서 디폴트로 주어지는 값은 매우 좋다. 그러나 당신이 서버를 시작하기 전에 concurrent_reads 값을 업데이트 하기를 원할 수 있다. 그것은 concurrent_reads 셋팅이 프로세서 하나에 두개의 쓰레드를 실행하는데 최적화 되어 있기 때문이다. 디폴트로 이 셋팅은 8이다. 그것은 4 코어가 있는 박스를 가정하고 있다. 당신이 그렇게 가지고 있다면 적당하다. 만약 당신이 8 코어 박스를 가지고 있다면 그 값을 16으로 맞춘다.

Concurrent_writes 셋팅은 조금 다르게 행동한다. 이것은 서버에 동시적으로 쓸수 있는 클라이언트의 수와 맞아야 한다. 만약 카산드라가 웹 애플리케이션 서버를 지원하고 있다면 이 셋팅을 디폴트 32에서 애플리케이션 서버가 카산드라에 연결할 수 있는 쓰레드의 숫자에 맞도록 해야한다. WebLogic과 같은 자바 애플리케이션 서버가 데이터 베이스 커넥션 풀을 20이나 30보다 작게 잡는 것이 일반적이지만 당신이 여러 개의 애플리케이션 서버를 클러스터안에서 사용한다면 그것도 조절을 해야한다.

1.6. Caching

카산드라에도 그리고 오퍼레이팅 시스템 레벨에도 캐싱에 관련한 셋팅이 몇 가지 있다. 캐쉬는 상당한 양의 메모리를 사용한다. 그리고 당신이 당신의 사용 패턴을 이해한 후에는 캐쉬를 잘 조심해서 튜닝하는 것이 좋은 생각이다.

카산드라에는 두가지 주된 캐쉬가 있다. 행 캐쉬와 키 캐쉬이다. 행 캐쉬는 완전한 행을 캐쉬한다. 그래서 키 캐쉬의 superset 이다. 당신이 주어진 컬럼군에 행 캐쉬를 사용한다면 당신은 그것에 키 캐쉬를 사용할 필요가 없다.

당신의 캐슁 전략은 따라서 몇가지 사항에 따라 튜닝되어야 한다.

l 당신의 쿼리를 고려하고 당신의 쿼리에 가장 잘 맞는 캐쉬 타입을 사용한다.

l 힙 사이즈와 캐쉬 사이즈의 비율을 고려한다. 그리고 캐쉬가 당신의 힙사이즈를 넘어가지 않게 한다.

l 당신의 키의 사이즈와 당신의 행의 사이즈를 고려한다. 일반적으로 키는 전체 행보다는 훨씬 작다.

Keys_cached셋팅은 키 위치의 숫자를 나타낸다. 키 값이 아니다. 그것은 메모리에 저장된다. 이것은 분수의 값으로 표현이 되거나 정수이다. 당신이 만약 분수를 사용한다면 키의 캐쉬에 대한 퍼센트값을 나타낸다. 정수값은 위치가 캐쉬되는 키의 절대 숫자를 나타낸다.

이 셋팅은 상당한 양의 메모리를 소비한다. 그러나 당신의 위치가 이미 hot하지 않다면 좋은 트레이드 오프가 될 수 있다.

Disk_access_mode의 목적은 오퍼레이팅 시스템이 읽기를 캐쉬할 수 있도록 메모리 맵 파일을 활성화하는 것이다. 그래서 카산드라 내부 캐쉬의 로드를 줄이는 것이다. 이것은 매우 좋게 들린다. 그러나 실제로는 disk_access_mode는 실용적이지는 않은 셋팅이다. 그리고 이 시점에서 원래 보여진 대로 정확하게 일하지는 않는다. 이것은 미래에 나아질 수도 있지만 셋팅이 없어질 수 있다. 그것의 주위에서 자유롭게 작동해보라 그러나 많은 다른점을 볼 수 는 없을 수 있다.

당신은 서버가 시작할 때 행 캐쉬를 덧붙일수 있다. 이것을 하기 위해서는 preload_row_cache 요소를 사용한다. 이를 위한 디폴트 셋팅은 false이다. 그러나 당신은 퍼포먼스를 향상 시키기 위해 true로 설정하고 싶을 수 있다. 그 댓가는 프리로드하기 위한 컬럼군에 상당한 양의 데이터가 있다면 bootstrapping 이 더 오래 걸린다는 것이다.

Row_cached 설정은 캐쉬될 행의 숫자를 나타낸다. 디폴트로 그 값은 0으로 되어있다. 아무런 행도 캐쉬되지 않는다는 것을 의미한다. 그래서 이것을 키는 것이 좋은 아이디어이다.

당신이 만약 분수를 사용한다면 당신은 모든것의 캐쉬에 대한 퍼센티지를 나타내는 것이다. 그리고 정수값은 그 위치가 캐쉬될 행의 절대 수를 나타내는 것이다. 당신은 이 셋팅을 조심스럽게 사용하기를 원할 것이다. 그러나 이것은 쉽게 우리 손을 벗어난다. 만약 당신의 컬럼군이 쓰기보다 읽기를 훨씬 많이 한다면 이 값을 높게 셋팅한다면 필요없이 상당한 서버의 자원을 소모할 것이다. 만약 당신의 컬럼군이 낮은 읽기와 쓰기의 비율을 가진다면 하지만 데이터가 많은 행을 가진다면 이 숫자를 매우 높게 설정하기 전에 좀 수학을 해야할 필요가 있다. 그리고 당신이 매우 많이 hit를 하는 행을 가지고 있지 않다면 그리고 다른 것들은 매우 조금 hit를 한다면 당신은 여기서 많은 boost를 보게 되지는 않는다.

1.7. 버퍼 사이즈

버퍼 사이즈는 어떤 동작을 수행할 때 메모리 할당을 보여준다. 다음은 이 셋팅들에 대한 대략적인 오버뷰이다.

Flush_data_buffer_size_in_mb

디폴트로 이것은 32 메가바이트로 되어있고 memtable이 디스크로 flush 될 때 사용할 버퍼의 사이즈를 나타낸다.

Flush_index_buffer_size_in_mb

디폴트로 이것은 8 메가바이트로 되어있다. 만약 각 키가 단지 몇 개의 컬럼을 정의한다면 인덱스 버퍼 사이즈를 늘리는 것은 좋은 아이디어이다. 만약 당신의 행이 많은 컬럼을 가진다면 당신은 버퍼의 사이즈를 줄이기 원할 것이다.

Sliced_buffer_size_in_kb

당신의 쿼리가 얼마나 변동하는지에 따라 이 셋팅은 매우 유용하지는 않을 수 있다. 인접한 컬럼의 구획을 수행할 때 사용할 버퍼의 사이즈를 킬로바이트로 정해줄 수 있게 한다. 만약 다른 것보다 많이 수행하는 어떤 쿼리가 있다면 아니면 당신의 데이터가 군당 비교적 일정한 수의 컬럼과 배치되어 있다면 이 셋팅은 적절히 읽기 동작에 도움이 된다. 그러나 이 셋팅은 글로벌하게 정의되었다는 것을 기억하자.

1.8. Python의 스트레스 테스트를 사용하기

카산드라는 py_stress 라는 유명한 유틸리티와 함께 온다. 이것으로 당신은 카산드라 클러스터에 스트레스 테스트를 할 수 있다. Py_stress를 수행하기 위해서 /contrib 디렉토리로 이동한다. 당신은 README.txt 파일을 확인하기 원할수 있다. 그것은 도구를 실행하기 위한 의존성의 리스트를 가지고 있다.

우리가 그 도구를 실행하기 전에 지나쳐야 할 몇가지 과정이 있다. 첫째, 당신이 아직 당신의 설정에서 디폴트 키스페이스를 가지고 있고 그것을 로드했는지 확인한다. 도구는 디폴트 컬럼군 정의에 반하여 동작하기 때문이다.

그리고 당신은 Python Thrift 인테페이스를 빌드해야 한다. 그것은 아마도 몇 가지 과정을 요구할 수 있다.

1.8.1. Python Thrift 인터페이스를 생성하기

우리가 스트레스 도구를 사용하기 전에 우리는 그것에 가용한 Python을 위한 Thrift 인터페이스를 가지고 있다는 것을 확인해야 할 필요가 있다. 이 과정을 아직 하지 않았다는 것을 알게된다. 아니면 그것을 잘못 했거나 이다. 만약 당신이 수행을 해봐서 아래와 같은 에러를 보게 된다면 이다.

No module named thrift.transport

당신의 시스템에 Python이 설치된 것을 확인하라. 이것을 하기 위해서 터미널을 열고 $python을 타이핑한다. 아래와 비슷한 출력을 보게 된다.

eben@morpheus$ python

Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)

[GCC 4.4.3] on linux2

Type "help", "copyright", "credits" or "license" for more information

Python 2.6 이나 그 이상 버전을 설치해서 가장 최근의 멀티 쓰레드 능력을 사용할 수 있는지 확인한다. 그것은 스트레스 테스트에 편리하다.

1.8.2. Thrift를 갖기

Thrift를 갖기 위해서 http://incubator.apache.org/thrift 에서 다운로드한다. 이것은 당신에게 thrift-0.2.0-incubating.tar.gz 와 같은 파일을 줄것이고 당신은 압축을 푼다. 그리고 압축을 푼 디렉토리에서 리눅스의 아래 명령을 의존성을 만들기 위해서 실행한다.

$ sudo apt-get install -y libboost-dev libevent-dev python-dev automake pkg-config

libtool flex bison

Thrift는 당신이 당신의 시스템에 C++ Boost 라이브러리를 적당히 인스톨하지 않았다면 동작하지 않을 것이다. http://www.boost.org 에서 부스트를 가져오라. 그리고 부스트의 홈 디렉토리에서 이 명령을 실행한다.

$ ./bootstrap.sh

$ ./bjam

이것은 부스트를 컴파일하고 인스톨한다. 이제 Thrift를 빌드하기 위해서 Thrift 홈 디렉토리에서 root 로서 몇 가지의 명령을 시행한다.

$ ./bootstrap.sh

$ ./configure

$ ./make

$ ./make install

$ cd lib/py

$ ./make

이제 $which thrift 명령을 수행한다. 이것은 Thrift가 어디 인스톨 되었는지 말해준다. 나의 시스템에서 이것은 /usr/local/bin/thrift 이다.

만약 Thrift가 적절히 인스톨 되었다면 당신은 Thrift를 실행할 수 있고 도움을 출력으로 볼 수 있을 것이다.

$ thrift -version

Thrift version 0.2.0-exported

당신의 site-packages 디렉토리를 Python 패스에 둔다.

$ export PYTHONPATH=/usr/lib/python2.6/site-packages/

이제 당신은 디렉토리로 이동할 수 있다. Python을 위한 Thrift 인터페이스를 생성하기 위해 아래의 명령을 수행한다.

$ ant gen-thrift-py

당신은 성공적인 빌드 메시지를 보게 된다. 이제 당신은 /interfaces/thrift/gen-py 에 생성된 Python을 위한 Thrift 인터페이스를 가지게 되었다. 이 디렉토리를 /contrib/py_stress 로 복사한다. 이제 당신의 카산드라 서버가 시작이 되고 Python 스트레스 테스트를 수행할 준비가 된 것을 확인한다.

1.8.3. Python 스트레스 테스트 수행하기

이제 우리는 모두 셋팅되었다. 우리는 스트레스 테스트를 실행할 수 있다. /contrib./py_stress 디렉토리로 이동한다. 터미널에서 stress.py를 타이핑한다. 그래서 local host에 대해서 테스트를 수행한다.

당신이 만약 스트레스 테스트가 localhost:9160에 연결하지 못한다는 메시지를 보게되면 몇 가지 옵션이 있다. 첫째, 당신의 카산드라 서버가 시작이 되었고 그 주소와 포트를 귀기울이고 있는지 확인한다. 만약 당신의 설정에서 localhost 대신에 당신의 IP 주소를 듣게 하고 있다면 당신은 스크립트를 당신의 서버가 있는 곳에 설정할 수 있다. 당신의 설정에서 localhost를 듣도록 바꾸고 아마도 가장 좋은 것은 스크립트에 –d 옵션을 전달하여 어떤 노드를 당신이 연결하기 원하는지 나타낸다. 여기와 같다.

$ stress.py -d 192.168.1.5

테스트는 1만개의 값을 입력할 때까지 계속 된다. 그리고는 멈춘다. 나는 이 테스트를 한 개한 일반적인 워크스테이션 , Intel I7 프로세서와 4GB 램에 했다. 여기에 출력이 있다.

eben@morpheus$ ./stress.py -d 192.168.1.5 -o insert

total,interval_op_rate,avg_latency,elapsed_time

196499,19649,0.0024959407711,10

370589,17409,0.00282591440216,20

510076,13948,0.00295883878841,30

640813,13073,0.00438663874102,40

798070,15725,0.00312562838215,50

950489,15241,0.0029109908417,60

1000000,4951,0.00444872583334,70

이것을 좀 풀어보자. 우리가 한 것은 일만개의 값을 완전히 튜닝되지 않은 한 개 노드의 카산드라 서버에 70 초 동안 생성하고 입력한 것이다. 당신은 처음 10초 동안에 우리가 196,499 개의 랜덤하게 생성된 값을 넣었다는 것을 볼 수 있다. 각 동작당 평균 latency는 0.0025 초이고 그것은 2.5 밀리세컨드이다. 그러나 이것은 디폴트를 사용하여 카산드라 서버가 이미 1 GB의 데이터를 데이터베이스에 가지고 테스트를 하기전에 관리해야 했다. 테스트에게 더 쓰레드를 주어 좀 더 나은 퍼포먼스를 짜낼수 있는지 보도록 하자.

eben@morpheus$ ./stress.py -d 192.168.1.5 -o insert -t 10

total,interval_op_rate,avg_latency,elapsed_time

219217,21921,0.000410911544945,10

427199,20798,0.000430060066223,20

629062,20186,0.000443717396772,30

832964,20390,0.000437958271074,40

1000000,16703,0.000463042383339,50

우리가 여기서 한 것은 10 쓰레드를 사용하기 위해서 –t 플래그를 사용하였다. 이것은 50초에 1,000,000 기록을 썼다는 것을 의미한다. 2밀리세컨드의 latency가 쓰기 당 있었고, 이미 1.5GB의 데이터를 관리하고 있는 튜닝되지 않은 데이터 베이스이다.

당신은 테스트를 여러 번 시행하여 주어진 하드웨어 셋팅에서 적당한 쓰레드의 개수를 찾아내야 한다. 당신 시스템에서의 코어의 개수에 따라서 당신이 쓰레드의 개수를 많이 높게 했다면 더 안좋은 퍼포먼스를 보게될 것이다. 그것은 프로세서가 일하기 보다는 쓰레드를 관리하는데 더 시간을 쓰기 때문이다. 당신은 일리있는 테스트를 하기 위해서 쓰레드의 개수와 코어의 개수 사이에 대략 맞는 값을 갖기 원한다.

이제 이 데이터의 모든 것을 데이터 베이스에서 가지고 있으니 조금의 값을 읽기 위해 테스트를 또한 사용해보자.

$ ./stress.py -d 192.168.1.5 -o read

total,interval_op_rate,avg_latency,elapsed_time

103960,10396,0.00478858081549,10

225999,12203,0.00406984714627,20

355129,12913,0.00384438665076,30

485728,13059,0.00379976526221,40

617036,13130,0.00378045491559,50

749154,13211,0.00375620621777,60

880605,13145,0.00377542658007,70

1000000,11939,0.00374060139004,80

당신이 볼 수 있듯이 카산드라는 쓰는 것처럼 빨리 읽지는 못한다. 백만개의 값을 읽기 위해서 약 80초가 소요된다. 하지만 기억하라 이것은 튜닝되지 않은 싱글 쓰레드의 일반적인 위크스테이션에 다른 프로그램을 돌리고 데이터 베이스의 사이즈는 2GB이다. 그럼에도 이 것은 당신이 당신 환경을 위해서 퍼포먼스 튜닝을 하고 당신의 클러스터에서 어떤 것들을 예상하는지 숫자들을 얻어내는데 좋은 도구이다.

1.9. 시작하기와 JVM 설정

카산드라는 서버가 어떻게 시작하고 얼마나 많은 자바 메모리가 할당이 되어야 하는 등을 위한 다양한 옵션을 설정하도록 해준다. 이 섹션에서는 시작할 때 어떻게 튜닝을 하는지 살펴본다.

당신이 윈도우즈를 사용하고 있다면 시작 스크립트는 Cassandra.bat 라고 불린다. 그리고 리눅스에서는 Cassandra.sh 이다. 당신은 단지 이 파일들을 실행함으로써 서버를 시작할 수 있다. 그것은 몇 개의 디폴트를 사용할 것이다. 그러나 bin 디렉토리에 다른 파일이 있어서 당신이 어떻게 카산드라가 시작하는지에 관계된 다양한 셋팅을 설정 할 수 있게 해준다. 이 파일은 Cassandra.in.sh 라고 하며 어떤 옵션을 분리한다. 그것은 다른 파일에의 업데이트를 쉽게 해주는 JVM 셋팅 등이다.

자바 옵션	셋팅 가이드라인
MaxTenuring Threshold	모든 자바 오브젝트는 그 헤더에 나이 필드를 가지고 있다. 그것은 얼마나 많이 젊은 세대의 공간에서 복사가 되었는지 나타낸다. 그것들은 젊은 세대의 가비지 콜렉션에서 살아남으면 복사된다. 그리고 이 복사는 대가가 있다. 오래 살아남은 오브젝트들은 여러 번 카피가 되었을 것이기 때문에 이 값을 튜닝하면 퍼포먼스가 좋아질 수 있다. 디폴트로 카산드라는 이 값을 1로 가지고 있다. 젊은 세대의 콜렉션을 살아남은 오브젝트를 종신의 세대로 옮기기 위해서는 이 값을 0으로 셋팅한다.
UseConcMarkSweepGC	이것은 JVM이 어떤 가비지 콜렉션 전략을 사용할지 지도한다. 특별히 그것은 ConcurrentMarkSweep 알고리즘을 활성화한다. 이 셋팅은 더 많은 RAM을 사용한다. 그리고 GC에 소요되는 멈추는 시간을 최소화하기 위해서 애플리케이션이 동작되는 동안에도 잦은 가비지 컬렉션을 수행하여 더 많은 CPU 파워를 사용한다. 이 전략을 사용할 때 힙의 최소와 최대값을 같은 값으로 설정하는 것이 중요하다. 이것은 JVM이 힙을 크게하기 위해 시간을 소요하는 것을 방지한다. 이것을 –XX:+UseParallelGC로 튠하는 것이 가능하다. 그것은 멀티 프로세서 기기에서 장점을 발휘한다. 이것은 높은 애플리케이션 퍼포먼스를 주지만 때때로 멈춘다. 카산드라와 함께 연속적인 GC를 사용하지 말라.

포함된 설정파일의 대부분의 옵션은 자바 셋팅을 둘러싼다. 예를 들어 자바 힙 메모리 사용의 디폴트 맥시멈 사이즈는 1GB이다. 만약 더 사용할 수 있는 기기에 있다면 당신은 이 셋팅을 튜닝하고 싶어 할 수 있다. 자바가 힙의 성장을 관리해야 하지 않도록 –Xmx 와 –Xms 옵션을 같은 값으로 설정하도록 노력한다.

이 옵션을 튜닝하는 것은 스트레스 테스트의 실행을 좋게 한다. 예를 들어 디폴트보다 다음과 같은 셋팅을 적용했을 때 나는 15%의 퍼포먼스 향상을 보았다.

JVM_OPTS=" \

-da \

-Xms1024M \

-Xmx1024M \

-XX:+UseParallelGC \

-XX:+CMSParallelRemarkEnabled \

-XX:SurvivorRatio=4 \

-XX:MaxTenuringThreshold=0

퍼포먼스 튜닝시에 처음에는 다른 것은 하지 않고 힙의 최소와 최대값을 셋팅하는 것은 좋은 아이디어이다. 오직 실제 세계에서의 당신의 환경에서 그리고 힙 분석 도구의 도움과 당신의 특정한 애플리케이션의 행동을 관찰함으로 퍼포먼스 벤치마킹을 한 이후에야 당신은 더 발전된 JVM 셋팅의 튜닝을 할 수 있다. 당신이 당신 JVM 옵션을 튜닝하고 로드 테스팅 도구의 사용이나 contrib 에서의 Python 스트레스 테스트 같은 것에서 성공을 보았다면 너무 좋아서 흥분하지는 말아라. 당신은 진짜 세계의 환경 컨디션에서 테스트할 필요가 있다. 그냥 이 셋팅들을 복사하지는 말아라.

일반적으로 당신은 아마 힙이 아웃 오브 메모리 에러를 내었다면 힙이 그 상태를 덤프하도록 하였음을 확인하고 싶을 것이다. 이것은 당신이 아웃 오브 메모리에서는 좋은 연습이 될 것이다. 당신은 또한 힙이 가비지 콜렉션 자세한 사항을 프린트하도록 할 수 있다. 또한 당신이 카산드라에 많은 데이터를 가지고 있다면 그리고 가비지 콜렉션이 한참 동안 멈춰 있는 것을 안다면 당신은 가비지 콜렉션을 초기화하도록 쓰레쉬홀드값을 갖도록 하는 것 보다는 가비지 콜렉션이 힙이 적은 메모리를 꽉 채우도록 실행하도록 시도할 수 있다. 이 모든 파라미터는 여기에 보여진다.

-XX:CMSInitiatingOccupancyFraction=88 \

-XX:+HeapDumpOnOutOfMemoryError \

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -verbose:gc \