2016년 9월 30일 금요일

Couchbase ( 설치 및 설정 가이드 )

Couchbase 설치 및 설정 가이드

Linux 커널 파라미터 조정

Swappiness 조정
1. vi /etc/sysctl.conf 파일에 아래 값을 등록 후 저장 합니다. ( 영구적 저장 )
  
  vm.swappiness = 0
2. sysctl 명령어로 현재 Dynamic 환경 설정
  
  sysctl -w vm.swappiness = 0

Disable Transparent Huge Pages ( THP )

Setting 확인
cat /sys/kernel/mm/*transparent_hugepage/enabled

cat /sys/kernel/mm/*transparent_hugepage/defrag
-> 위 두 파라미터의 결과값이 Never 이여야 Page 할당에 따른 성능저하를 방지할 수 있습니다.

Setting 변경

vi /etc/rc.local 에 아래 값을 등록 후 저장 `for i in /sys/kernel/mm/transparent_hugepage/enabled; do echo never > $i; done for i in /sys/kernel/mm/transparent_hugepage/defrag; do echo never > $i; done`

현재값 변경

echo "never" > /sys/kernel/mm/*transparent_hugepage/enabled

echo "never" > /sys/kernel/mm/*transparent_hugepage/defrag

사용자 리소스 제한값 ulimit 수정
1. 확인
  
  ulimit -a
2. 수정 (최소 8192 개로 설정 필요)
  
  ulimit -n 10240

다운로드
1. Couchbase Download Website 에서 RPM Package Download
  1. http://www.couchbase.com/nosql-databases/downloads
  2. Community Edition Tab 에서 3.0.1 Version 을 Download
설치
1. Root 권한으로 Rpm 설치를 할 경우 RPM 에서 자동으로 Couchbase 유저를 생성하여 설치를 하게 되므로, RPM Package Download 후에 RPM 으로 설치를 수행합니다.
  
  root> rpm -ivh couchbase-server-community-3.0.1-centos6.x86_64.rpm
2. RPM 으로 설치 이후에 Couchbase 가 기동 되며, Service 에 자동으로 등록되어 Couchbase 의 시작과 중지는 다음과 같이 수행할 수 있습니다.
  
  시작 : sudo service couchbase-server start
  중지 : sudo service couchbase-server stop
Server 설정
1. Couchbase 는 Admin 및 Monitoring 을 위한 Web Console 을 제공하고 있으며, 최초 설정은 Web 으로 설정하는 것이 보다 편리 합니다.
2. Web Browser 에서 http://<host>:8091/index.html 을 입력하여 Admin Console 에 접속 합니다.
3. 위 Setup Click 하여 최초 설정을 진행합니다.
4. 개발 서버로 사용할 경우 Setup 이후 Default 설정을 따라 진행하나, Game 성능 QA 또는 상용 서버로 사용될 경우 아래 상세 설정을 참고 하여 Setting 을 진행 할 것을 권장합니다.
상세 설정 ( Configure Server )
1. Disk 설정
  1. Database Path 와 Indices Path 는 Disk I/O 성능 병목을 방지하기 위해 물리적으로 분할하여 지정 합니다.
2. Hostname 설정
  1. Hostname 은 실서버의 IP 를 지정합니다. ( 노드 간 Clustering 을 위해 사용되므로, IP 를 지정합니다. )
3. Cluster 설정
  1. Cluster 설정은 최초로 설정되는 서버의 경우에는 Start a new Cluster 로 Cluster 를 구성해야 하며, 최초 구성 이후 Scale-Out 으로 사용될 Second 이후 서버는 Join a Cluster Now 로 진행합니다.
4. RAM Quota 설정
  1. 서버당 Ram Quota 는 Couchbase 에서 사용될 Server 당 가용 메모리 Max Limit 설정이며, OS 가 사용할 Kernel 및 Cache 등의 Memory 영역 2~4GB 를 제외하고 설정하는 것을 권장합니다.
    (Physical Memory 16GB 서버의 경우 3GB~4GB 여유 메모리를 제외하고 12GB ~13GB 를 Server RAM Quota 로 설정 )
  2. RAM Quota 는 Online 상에서 변경 가능합니다.
5. 설정 UI
6. Next 를 Click 하여 다음 Setting 화면으로 넘어가면 , Test 를 위한 Sample Bucket Setting 을 할 수 있으며 선택하지 않고 계속 진행하도록 합니다.
상세 설정 ( Create Default Bucket )
1. Default Bucket 설정
  1. Default Bucket 은 사용자가 User Bucket 을 생성하기 전에 만들어지는 Default Bucket 이며, 모든 Setting 을 완료한 이후 삭제 할 수 있으므로 Bucket Type 은 Couchbase Bucket 로 설정하고
    Bucket RAM Quota 는 최소 Size 인 100M를 설정합니다.
  2. Cache Metadata 는 Value Eviction 으로 설정합니다.
    1. Value Eviction 은 Couchbase 가 Memory 확보 시에 Key 와 Meta 정보는 Memory 상에 두고, Value Data 만 축출하는 옵션이며, Full Eviction 은 Key 와 Metadata, Value 모두를 축출하게 됩니다.
    2. Full Eviction 은 Memory Overhead 를 줄일 수 있으나 성능저하에 원인이 될 수 있으므로 충분한 Memory 를 확보하고 Value Eviction 모드를 사용하는 것을 권장 합니다.
2. Replicas 설정
  1. Replica 는 최소한 1개 Copies 를 설정합니다. Memory Quota 산정 시 Memory 가 충분할 경우 안정성 확보를 위해 Replica 를 2로 설정할 수 있습니다.
3. Disk I/O Optimization
  1. Disk I/O priority 는 Low 로 설정 합니다. Data durability 확보를 위해 High 를 선택 할 경우 성능 지연 현상이 발생하므로, Disk I/O 우선 순위는 Low 로 설정합니다.
4. Flush
  1. Flush 를 활성화하면 Flush 명령어로 Bucket 의 데이터를 모두 삭제 할 수 있으나, 실제 서비스에는 비 활성화를 권장하므로, Enable 을 체크하지 않고 진행한다.
5. 설정 UI
6. Next 를 Click 한 이후 Notifications TAB 에서는 Update 알림을 Disable 하고 Next 를 Click 합니다.
상세 설정 (Configure Server)
1. 계정 설정
  1. 각 서버의 계정을 설정하도록 합니다. 추가 노드가 Cluster 에 Join 할 때 해당 계정 및 Password 가 사용되며, Password 는 문자 및 특수문자가 포함된 8자 이상의 문자열로 설정하도록 합니다.
  2. 위 설정까지 완료 되면 최초 가용 노드의 설정이 완료 됩니다.
추가 노드 Join Cluster
1. 4번 항목의 Server 설정 및 5번 항목의 상세 설정 ( Configure Server ) 을 참조 하여 서버를 동일하게 설정합니다.
2. 해당 노드는 Cluster 에 Join 되야 하는 추가 노드이므로, Join Cluster 를 선택하여 최초에 설정한 Server 의 IP 및 Username/Password 를 입력하여 연결하도록 합니다.
3. Join a cluster 가 완료 되고 나면, Cluster Meta 정보에 등록만 되고 바로 사용 할 수는 없습니다. 추가 노드를 Cluster 의 노드로 사용하려면 Bucket 데이터의 Rebalance 작업이 필요합니다.
4. 노드를 추가 한 이후 Server Nodes -> Pending Rebalance 정보 Tab 을 확인 하면 추가 된 노드를 확인 할 수 있으며 , Rebalace 를 Click 하면 Data 및 Meta 정보를 Rebalace 후 비로소 Cluster 에 참여하게 됩니다.
추가 튜닝 설정
1. Auto-Compaction
  1. Couchbase 서버의 스토리지 엔진은 파일을 계속 붙여나가는 방식으로 확장 됩니다. (기존 Page 부분을 Update 방식이 아닌, 추가 적으로 ADD 하고 Flag 로 구분하는 방식 )
    이에 따라 파일의 오래된 정보들을 제거함으로서 스토리지 용량을 관리하게 되며, 이 기능이 Auto-Compaction 기능입니다.
  2. Auto compaction 이 서비스 Peak Time 에 빈번하게 발생하면 전반적인 성능 저하가발생할 수 있으므로, Time Interval 을 설정하여, 서비스 부하가 가장 낮은 시간대에 수행될 수 있도록
    설정하는 것을 권장 합니다.
  3. 설정 UI
2. Auto-Failover 설정
  1. 특정 노드 서버 장애 시 지속적인 서비스 제공을 위해 Auto-Failover 를 설정 합니다. Timeout 시간은 120초로 설정합니다.
Default Bucket 삭제
1. 상용 서비스 용으로 설정 시 Memory 의 확보를 위해 최초 설정 시 Setting 되었던 Default Bucket 은 삭제 하도록 합니다.
2. Bucket 정보에서 Edit 를 Click 하여 Bucket 을 삭제 할 수 있습니다.

Couchbase ( 시스템 산정 가이드 )

목적
1. Couchbase 초기 세팅 시 플랫폼을 산정하기 위한 검토자료로 사용합니다.
CPU
1. Couchbase 는 각 코어의 Clock Speed 보다 Multi Core 환경에 더 유용합니다. ( Multi-threaded Process 환경)
2. 물리적으로 노드 당 최소 CPU 4~8 Core 를 권고하며, 추가 확장 필요 시 Scale-Out 방식으로 노드를 추가한 후 Rebalancing 하는 것을 권고 합니다.
3. 기본 최소 4 Core 에
  Bucket 하나를 추가 할 경우 + CPU Core 1개 추가,
  Design Document 추가 시 + CPU Core 1개 추가 권장합니다.
  1. 3개 Bucket 과 1 Design Document 를 사용시 ( 4 Core + 3 Core(3Buket) + 1 Core(1 Design Document) ) = 8 Core 권장
4. 원격 복제 XDCR 와 Views 를 사용할 경우 최소 CPU 6 Core 이상을 권장합니다.

메모리 산정

Memory Quota 산정
- 목적 : Memory Quota 산정을 통해 필요 Node 개수를 확보하기 위함입니다.

산정 대상 Variable

Variable	Description
Documents Count	Working Set 으로 예상되는 Document 의 총 수
ID Size	Documents ID 의 평균 Size ( Key )
Value Size	Value 의 평균 Size
Number of Replicas	복제(Replica) 의 수
Working Set Percentage	Memory 에 상주하여 Data 를 사용할 percnetage
Ram Quota Per Node	노드당 Couchbase 를 위해 할당할 Ram Quota OS 와 특정 APP 가 사용할 최소 2GB 의 RAM 이상의 여유분을 제외하고 Quota 를 잡는 것을 권고
MetaData Per Document	MetaData 는 Document 당 60 Byte 고정 (반드시 메모리에 상주)
Headroom	일종의 Metadata 를 위한 보정치 SSD 를 사용하면 Memory 의 25% , Hard Disk 사용 시 Memory 의 30%
High Water Mark	Couchbase 에서 설정하는 RAM 의 High Water Mark Default 로 Node의 RAM 에 85% 로 설정

산정 공식

Variable	Description	Detail
No_of_copies	1 + Replica 의 수	원본 노드와 Replica 의 수
Total_metadata	(Documents Count) * ( Metadata per Document + ID Size ) * (No_of_copies)	Document Count 는 최대 증가 예상 수를 추측
Total_Dataset	(Documents Count) * ( Value Size ) * ( No_of_copies )	Document Count 는 최대 증가 예상 수를 추측
Working_Set	Total_dataset * ( Working_set_percentage )	메모리에 상주시킬 평균 Working Set 크기
Cluster RAM quota Required	(Total_metadata + Working_set ) * ( 1 + headroom) / ( high water mark)	Cluster 에서 사용될 총 RAM 필요 크기
Number of Nodes	Cluster RAM quota required / RAM quota per node	Cluster 구성에 필요한 노드 수 RAM quota per node 는 Physical Memory - 2GB 권고

산정 공식 예시 (Input Variable)

Input Variable	Sample Value
Document Count	1,000,000 Row
ID Size	100 Byte
Value Size	10,000 Bye
Number of Replicas	1
Working Set Percentage	20 %
Type Of Storage -- Overhead Percentage	IF(HDD)THEN 30%
Metadata Per Document	60 Byte
High Water Mark	85 %
RAM quota per node	6 GB ( Physical Mem 8GB 시)

산정 공식 대입 예시(Calculation)

variable	Calculation	Detail
No_of_copies	1 + 1	원본 노드와 Replica 수의 합
Total_metaData	1,000,000 * ( 60 + 100) * (2) = 320,000,000 Byte	1,000,000 Row 에 필요한 MetaData 크기 (반드시 RAM 에 상주)
Total_Dataset	1,000,000 * (10,000) * (2) = 20,000,000,000 Byte	Key 를 제외한 총 Data 의 크기
Working_Set	20,000,000,000 * (0.2) = 4,000,000,000 Byte	Working Set 으로 활용될 Memory 의 크기
Cluster RAM Quota Required	( 320,000,000 +4,000,000,000) * ( 1+ 0.30 ) / (0.8) = 7,020,000,000 Byte ( 6.6 GB)	총 필요한 RAM 의 크기
Number of Nodes	6.6 GB / 6GB = 1.1 Node Or 2 Node	Cluster 구성에 필요한 노드의 수는 ( Cluster RAM Quota Required /노드당 Quota )

Disk Throughput and sizing
1. Size
  - Key-Value Data Only : Disk 의 사이즈는 Key-value data 만을 유지하는 기준으로 저장될 모든 Dataset 의 size 의 2~3배를 권고합니다.
  - View 사용 : View 가 사용될 경우 View 는 실제 데이터를 저장하여 Indexing 으로 사용하기 때문에 View 의 개수에 따라 적절히 추가 산정해야 합니다.
2. Throughpu
  1. Couchbase 는 데이터 영속성을 위해 Disk 에 Key-value 를 저장하게 되므로, Disk I/O 도 중요합니다.
  2. Couchbase Server 의 Install 영역과 Data, Index(View) 영역을 물리적인 Disk 분할 함으로서 I/O 분산 효과로 성능이 향상됩니다.
    
    분류
    
    물리적 분할
    
    Mount
    
    Engine
    
    /dev/sda1
    
    /opt/couchbase
    
    Data
    
    /dev/sdb
    
    /data
    
    Index
    
    /dev/sdc
    
    /index
  3. RAID 구성은 필요조건은 아니나 RAID 0 or 10 을 권장합니다.
Network Bandwidth
1. 최소 1 Gig Bit 대역의 Network 으로 구성하는 것이 좋으며, Low latency 가 중요한 환경일 경우 10 Gig Bit 대역도 성능 향상에 도움이 됩니다.
Couchbase Version
1. 현재 Community Edition의 최신 버전을 사용할 것을 권장

권장 SPEC 요약

항목	권장 SPEC
CPU	8 Core
RAM(Physical)	최소 16GB ~ 32GB ( 추가 확장 필요시 Scale-Out 으로 확장)
Disk	HDD Disk ( Data/Index 물리적 분활) , 예상 저장 DataSet 의 3배 권장
Network	1 Gig Bit Bandwidth
Couchbase Version	Community Edition 최신 버전

리눅스 튜닝 ( Swapiness 커널 파라미터 튜닝)

왜 Linux 시스템에서 Free Memory 가 있는데도 Swap 을 사용하게 되는 것인가 ?
1. Linux가 메모리가 많음에도 불구하고 스왑공간을 사용하는 이유는 스왑 사용여부를 결정하는 값의 계산식에서 비롯된다.
2. 아래의 계산 식에 따라 Linux 는 Swapping 을 결정하게 된다.
  swap_tendency = mapped_ratio / 2 + distress + swappiness;
3. 여기서 mapped_ratio 는 현재 Physical 메모리 대비 구동중인 Process 메모리들의 공간 비율이다. 즉 전체 메모리 16G 에서 Process 가 12G 사용하면 mapped_ratio 는 75 로 산정된다.
4. distress 는 메모리 확보가 얼마나 어려운 상태인지를 체크 하는 값이다. 내부 알고리즘이며, 대략 메모리 회수 한번 했는데 실패할 경우 다음번에는 더많은 페이지를 회수하기 위해
  메모리 페이지를 회수하게 되는데( 계속 늘어나니까) 이때 우선 순위를 높여가며 , 메모리 회수를 위해 적극 동작하게 되는 것이다.
  이 때 아래와 같이 distress 값도 변동 되며, 일반적으로 priority 는 12가 가장 일반적이며, 시스템에서 메모리를 잘 회수하지 못하고 문제가 있을 수록 priority 가 0 으로 낮아진다.
  distress = 100 / (2 ^ priority)
  
  priority
  
  12~7
  
  6
  
  5
  
  4
  
  3
  
  2
  
  1
  
  0
  
  distress
  
  0
  
  1
  
  3
  
  6
  
  12
  
  25
  
  50
  
  100
5. 그리고 마지막으로 우리가 조절할 수 있는 swappiness 는 커널 파라미터로 지정되며 default 로 60이 잡혀있다.
6. 예를 들어 일반적인 경우에 distress는 0이고 swappiness는 60이며, 4GB 메모리를 가진 시스템에서 3GB 만 사용한다고 가정해서 위 식에 대입하면 아래와 같다.
  swap_tendency = (3GB / 4GB * 100) / 2 + 0 + 60 = 97.5
  중요한 것은 이 swap_tendency 가 100 을 넘지 않으면 Swap 은 발생하지 않으나 100 을 넘으면 Swap 을 쓸 수 있게 된다는 뜻이다.
  
  즉 Process 의 메모리 사용량의 총합과 distress 는 조절 할 수 없지만 swappiness 값을 조정하므로서 Swap 이 발생하지 않도록 사용자가 제어 할 수 있다는 것이다.
7. 현재 각 서버에서 Swappiness 의 설정 값을 보려면 아래의 명령어를 사용하면 된다.
  
  $> sysctl -a | grep vm.swappiness
진짜 Free 메모리가 있는데 Swap 이 사용 되나 ???

1. 진짜 Free 메모리가 있는데 Swap 이 사용되는지 넷마블 내부의 모 운영서버를 한번 확인해 봤다.
2. 위에서 보면 mysql 서버가 47.4% 의 메모리를 점유하고 있는데 Swap 사용량이 706M 인것 을 확인 할 수 있다.
3. 이는 Mysql 의 데이터 버퍼캐쉬 중 일부가 이미 Swap 을 쓰고 있다는 사실에 놀라울 뿐이다.

3. 어떻게 해야 하나?

Swappiness 값을 조절해서 Swap 발생을 최소화 할 수 있다.

`vm.swappiness = 0`	(커널 버전 3.5 이상) 스와핑 끄기
`vm.swappiness = 1`	(커널 버전 3.5 이상) 스와핑 최소화
`vm.swappiness = 10`	메모리가 충분할 때 성능향상을 위해 권장되는 경우가 있음
`vm.swappiness = 60`	기본값
`vm.swappiness = 100`	적극적으로 스왑 사용

위 표는 1번에서 설명한 계산 식에 따라서 보면 될 것 같다.
Distress 값이 시스템 상태에 따라 변동 되며 ( 메모리 회수에 몇번 실패할 경우) swap_tendency 값이 변동 되어 결국 100 을 넘어 가면
swap 을 쓸 수 있으므로 적절한 swappiness 조절 값이 필요하다.
내부에서 Cache 로 사용되는 서버들 ( 예를 들면, redis 나 couchbase) 는 swappiness 를 0 또는 1로 사용하는 것이 개인적으로 권한다.
위 값에 대한 근거는 redis 와 couchbase 에서 제공되는 문서를 기반으로 하며 관련 Link 는 다음과 값다.

종류

Link

redis LAB https://redislabs.com/blog/5-tips-for-running-redis-over-aws#.Vvu-h-IS-Uk

couchbase
manual http://docs.couchbase.com/admin/admin/Concepts/swap-space.html
Mysql 서버는 10 으로 설정하고 모니터링을 충분히 하는 것을 권한다.
(일반적으로 메인서버이므로... ) 다만 Oracle vendor 사와 MariaDB 에서는 0 을 권고하고 있다.

종류

Link

Maria DB https://mariadb.com/kb/en/mariadb/configuring-swappiness/

Oracle 사 문서 http://www.oracle.com/us/technologies/linux/linux-and-mysql-optimizations-wp-2332321.pdf

종류	Link
redis LAB	https://redislabs.com/blog/5-tips-for-running-redis-over-aws#.Vvu-h-IS-Uk
couchbase manual	http://docs.couchbase.com/admin/admin/Concepts/swap-space.html

종류	Link
Maria DB	https://mariadb.com/kb/en/mariadb/configuring-swappiness/
Oracle 사 문서	http://www.oracle.com/us/technologies/linux/linux-and-mysql-optimizations-wp-2332321.pdf

4. 어떻게 바꾸나?

1. 아래의 명령어는 Dynamic 변수로 서버에 바로 적용된다.
  sysctl -w vm.swappiness=0
2. 영구적 적용 하려면 /etc/sysctl.conf 에 등록
  vi /etc/sysctl.conf
  
  vm.swappiness = 0

5. 그래서 결론은?

1. CacheServer 들은 swappiness 를 0 또는 1로 설정하고 사용하자. Vendor 들 권고 값은 0 이다.
2. Mysql 은 1 또는 10으로 설정하고 운영하고 충분한 내부 검증이 되면 0으로 설정하자. Mysql 역시 Vendor 권고값은 0 이다.

여기서 중요한 것은 Swappiness 를 설정한다고 해서 Swap 을 못사용한다는게 아니다!!! Free Memory 가 있는데도 Swaping 을 할꺼냐를 판단하는 것이다. 오해하지 말자 !

OS 튜닝 ( 게임 서버 CPU 튜닝하기 )

* 최근에 DB 서버가 아닌 게임서버도 튜닝할 일이 있었다. 게임서버가 TCP 서버이며 1 프로세스 Mulit Threading 방식인데, CPU 사용율이 많아 OS 상에서 커널파라미터를 수정하여 튜닝한 사례 이다.

1. 조절한 커널 파라미터

# A. SWAP 사용 빈도
  vm.swappiness = 1 
* 리눅스가 Free 영유 메모리가 있는데도, Swap 을 쓸경우가 빈번합니다. 이 프로퍼티는 Free Memory  여유가 넘치는데도
  Swap 을 쓰는 빈도를 최소화하는것입니다. 이프로퍼티로 인해 Swap 자체를 안쓰진 않고, 최소화합니다.

#B. THP Disable  
  echo never > /sys/kernel/mm/transparent_hugepage/enabled
  echo never > /sys/kernel/mm/transparent_hugepage/defrag
 
* 리눅스가 Memory Page 할당시 큰 메모리 페이지를 자동으로 한번에 할당할 수 있는 방식을 사용합니다. 이는 한번에 큰 메모리를 할당할 경우
성능 저하 및 시스템Hang 같은 현상이 발생하기 쉽기 때문에, 금지하는 것이 좋습니다. 이는 메모리 조각화도 발생시킬수있습니다. 
따라서 HUGE 페이지를 사용하지 않도록 Never 로 변경합니다.

#C. NUMA Disable (수정후 서버 재기동 필요)
 
vi /boot/grub/grub.conf 
kernel /vmlinuz-2.6.32-504.el6.x86_64 ro root=UUID=d55dc716-2f4c-425e-b657-c0a614f27003 
rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet numa=off
 
 
기본적으로 NUMA 의 개념은 1개 서버를 논리적으로 나눠, CPU/Memory 를 논리적으로 프로세스가 나눠 각각 affinity 하게 쓸수 있게 
하겠다는 개념에서 출발합니다. 
여러개 프로세스를 구동하는 시스템의 경우 서로 자원 경합을 줄일 수 있기 때문에 효율적일수 있으나 현재 게임서버와 같이
1개의 프로세스가 아주 활동이 빈번하고, 응답이 빨라야 할 경우 NUMA 가 불필요하게 논리적으로 연산발생 및 NUMA 노드 Miss 가 발생하여 
성능이 줄어 들 가능성이 있고 CPU 를 많이 소모하게 될 경우가 발생합니다.

튜닝 전 CPU 사용율 ( 약 43~45% )

튜닝 후 CPU 사용율( 약 30~32% )

3. 추가 설명

DB에는 많은 커널이 튜닝되고 바뀌나 , 게임서버는 효과가 크고 안정성이 높은 커널프로퍼티만 적용했습니다. 제가 관리하는 DB 서버도 아니라 위 부분 정도만 튜닝하고 적용합니다.

2016년 9월 26일 월요일

리눅스 튜닝 ( 네트워크 Buffer overrun, drop 발생시 네트워크 튜닝 케이스 )

## -----------------------------------------------------------------------

## 0) THP 비활성화 

## -----------------------------------------------------------------------

echo "

for i in /sys/kernel/mm/*transparent_hugepage/enabled; do

     echo never > $i;

done

for i in /sys/kernel/mm/*transparent_hugepage/defrag; do

     echo never > $i;

done " >> /etc/rc.local

## -----------------------------------------------------------------------

## 1) ethernet queue (1000 -> 2000 증가)

## -----------------------------------------------------------------------

echo "ifconfig em1 txqueuelen 2000" >> /etc/rc.local

echo "ifconfig em2 txqueuelen 2000" >> /etc/rc.local

echo "ifconfig em3 txqueuelen 2000" >> /etc/rc.local

echo "ifconfig em4 txqueuelen 2000" >> /etc/rc.local

echo "ifconfig bond0 txqueuelen 8000" >> /etc/rc.local

## -----------------------------------------------------------------------

## 2) ringbuffer 를 최대치

## 확인 명령어 : ethtool --show-ring em2

## -----------------------------------------------------------------------

echo "ethtool -G em1 rx 2040" >> /etc/rc.local

echo "ethtool -G em2 rx 2040" >> /etc/rc.local

echo "ethtool -G em3 rx 2040" >> /etc/rc.local

echo "ethtool -G em4 rx 2040" >> /etc/rc.local

## 소켓단에서 패킷을 더쌓을수있게 receive queue

echo "net.core.netdev_max_backlog=250000" >> /etc/sysctl.conf

echo "net.core.netdev_budget=600" >> /etc/sysctl.conf

## -----------------------------------------------------------------------

## 3) SOFTIRQ 분산

## -----------------------------------------------------------------------

/sbin/chkconfig --add irqbalance

/sbin/chkconfig --level 345  irqbalance on

/sbin/service irqbalance start

## -----------------------------------------------------------------------

## 4) 네트워크 사용량 보기

## -----------------------------------------------------------------------

cd /home/

./nicstat -M -i p4p1 1

## -----------------------------------------------------------------------

## 5) audit 몇가지 보안 정책을 주석 처리 (cpu 5% 사용량 감소)

## service auditd restart

## -----------------------------------------------------------------------

vi /etc/audit/audit.rules

분류	물리적 분할	Mount
Engine	/dev/sda1	/opt/couchbase
Data	/dev/sdb	/data
Index	/dev/sdc	/index

priority	12~7	6	5	4	3	2	1	0
distress	0	1	3	6	12	25	50	100

2016년 9월 30일 금요일

Couchbase ( 설치 및 설정 가이드 )

Couchbase 설치 및 설정 가이드

Linux 커널 파라미터 조정

다운로드

설치

Server 설정

상세 설정 ( Configure Server )

상세 설정 ( Create Default Bucket )

상세 설정 (Configure Server)

추가 노드 Join Cluster

추가 튜닝 설정

Default Bucket 삭제

Couchbase ( 시스템 산정 가이드 )

목적

CPU

메모리 산정

Disk Throughput and sizing

Network Bandwidth

Couchbase Version