제가 본 프로덕션 시스템에서 사람들이 올바르게 설정하는 것을 간과하는 것 같은 두 가지 간단한 Linux OS 수준 설정이 있습니다. 다른 곳에 문서화되어 있지만 계속 나오는 내용이라 여기서 간단히 살펴볼 필요가 있을 것 같습니다. 이 항목들이 무슨 대단한 비밀 설정이나 마법의 총알 성능을 반드시 고쳐주는 항목은 아니지만, 프로덕션 Couchbase DB에서는 아래와 같이 올바르게 설정하고 Couchbase에 사용하는 노드를 부트스트랩하는 데 사용하는 시스템/프로세스에 통합해야 하는 항목들입니다. 멤캐시 성능과 성능 재조정 및 경우에 따라 안정성 문제를 해결하는 데 도움이 됩니다.
프로덕션 환경으로 전환하기 전에 테스트 환경에서 먼저 테스트해 보시기 바랍니다.
스왑 기능은 꺼야 합니다.
리눅스 가상 메모리 시스템에 대해 알고 있다면 이 부분은 매우 간단합니다. 스왑 레벨은 가상 메모리 하위 시스템이 디스크에 얼마나 많은 스왑을 시도해야 하는지 알려줍니다. 문제는 시스템에 사용 가능한 RAM이 충분한 경우에도 시스템이 메모리의 항목을 스왑하려고 시도한다는 것입니다. OS 기본값은 일반적으로 60이며, 이는 약간 공격적인 IMO입니다. 다음 명령을 실행하여 시스템이 어떤 값으로 설정되어 있는지 확인할 수 있습니다:
카우치베이스는 가능한 한 메모리에서 실제로 작동하도록 튜닝되어 있기 때문입니다. 스왑 값을 0으로 변경하는 것만으로도 성능을 향상시키거나 최소한 성능 저하를 방지할 수 있습니다. 비기술적인 용어로 설명하자면, 이는 OS의 가상 메모리 서브시스템에 정말 필요한 경우가 아니면 RAM에서 디스크로 항목을 스왑하지 않도록 지시하는 것입니다. 노드 크기를 올바르게 조정하기로 설정하면 스왑이 필요하지 않습니다. 이를 설정하려면 sudo를 사용하여 다음 프로세스를 수행하거나 야생에서 라이딩하는 경우 그냥 루트가 되세요.
sudo sh -c 'echo 0 > /proc/sys/vm/swappiness'
# 백업 sysctl.conf
sudo cp -p /etc/sysctl.conf /etc/sysctl.conf.date +%Y%m%d-%H:%M
# 재부팅 후에도 이 값이 유지되도록 /etc/sysctl.conf에서 값을 설정합니다.
sudo sh -c 'echo "" >> /etc/sysctl.conf'
sudo sh -c 'echo "1TP5 스왑을 피하려면 스왑을 0으로 설정하세요." >> /etc/sysctl.conf'
sudo sh -c 'echo "vm.swappiness = 0" >> /etc/sysctl.conf'
이를 위해 OS를 빌드하는 프로세스를 보유하거나 수정해야 합니다. 이는 새 인스턴스를 쉽게 불러올 수 있는 퍼블릭/프라이빗 클라우드의 경우 특히 중요합니다. Couchbase 노드에 대한 빌드 프로세스에서 이 부분을 만들어야 합니다.
투명 대형 페이지(THP) 비활성화하기
Red Hat Enterprise Linux(RHEL) 버전 6부터 CentOS 6 및 7에서도 대용량 페이지를 관리하는 새로운 기본 방법이 OS에 구현되었습니다. 우분투도 12.02 버전부터 이 설정이 적용되므로 이 설정도 변경해야 합니다. THP는 실행 중인 프로세스 모르게 작은 메모리 페이지를 거대한 페이지로 결합합니다. 이 아이디어의 목적은 TLB에 필요한 조회 횟수를 줄여 성능을 향상시키는 것입니다. 기본적으로 거대한 페이지의 자동화 및 관리를 위한 추상화를 가져옵니다. 카우치베이스 엔지니어링은 몇 가지 조건에서 이를 확인했습니다, THP가 활성화된 경우 심각한 페이지 할당 지연으로 인해 Couchbase Server에 부정적인 영향을 미칠 수 있습니다.. 따라서 모든 Couchbase Server 노드에서 THP를 비활성화하는 것이 좋습니다.
OS 설정을 비활성화해야 하는지 확인합니다.
다음 명령을 실행하여 THP의 상태를 확인합니다:
cat /sys/커널/mm/transparent_hugepage/defrag
일부 Red Hat 또는 Red Hat 변형에서는 이 작업을 수행해야 할 수도 있습니다:
cat /sys/커널/mm/redhat_transparent_hugepage/defrag
하나 또는 두 파일 모두에서 출력이 다음과 같이 표시되는 경우 아래 절차가 필요합니다:
초기화 스크립트 복사
초기화 스크립트는 재부팅 시 Couchbase가 로드되는 동시에 변경 사항이 적용되도록 설계되었습니다.
### 시작 초기화 정보
# 제공: disable-thp
# 필수-시작: $local_fs
# 필수-정지:
# 기본 시작: 2 3 4 5
# 기본-정지: 0 1 6
# 간단한 설명: THP 비활성화
# 설명: 부팅 시 투명 거대 페이지(THP)를 비활성화합니다.
### END INIT 정보
시작)
if [ -d /sys/kernel/mm/transparent_hugepage ]; then
echo 'never' > /sys/kernel/mm/transparent_hugepage/enabled
echo 'never' > /sys/kernel/mm/transparent_hugepage/defrag
elif [ -d /sys/kernel/mm/redhat_transparent_hugepage ]; then
echo 'never' > /sys/kernel/mm/redhat_transparent_hugepage/enabled
echo 'never' > /sys/kernel/mm/redhat_transparent_hugepage/defrag
else
반환 0
fi
;;
esac
OS에 코드를 등록하는 방법
다음을 수행합니다:
위의 코드로 파일을 만듭니다.
파일을 실행 파일로 변경합니다.
지금 바로 적용되도록 실행하세요.
부팅 시 초기화 스크립트가 시작되는지 확인합니다.
Red Hat 변형:
우분투:
프로세스 테스트
다음 명령을 실행하여 THP의 상태를 확인합니다:
cat /sys/커널/mm/transparent_hugepage/defrag
일부 Red Hat 또는 Red Hat 변형에서는 이 작업을 대신 수행해야 할 수도 있습니다:
cat /sys/커널/mm/redhat_transparent_hugepage/defrag
두 파일 모두 출력은 다음과 같아야 합니다:
참고: 이 작업을 수행하는 다른 방법은 다른 곳에서 찾을 수 있으며 /etc/grub.conf를 편집합니다. 이 방법은 앞으로 커널이 업데이트될 때마다 문제가 생길 수 있다는 점이 문제입니다. 제가 제안하는 방법은 장기적으로 관리하기 쉽고 노드를 부팅할 때 Puppet 모듈이나 Chef 레시피 같은 것에 넣어 rc.local 끝에 추가하기 쉽습니다.
THP는 일부 기능에는 유용하지만 Couchbase와 같은 애플리케이션에서는 문제를 일으킵니다. 이 문제는 비단 이것뿐만이 아닙니다. 인터넷에서 투명한 거대한 페이지를 검색하면 다른 DB 및 애플리케이션 공급업체에서 이와 관련된 여러 문서화된 문제가 있습니다. 이 문제를 해결할 수 있는 방법이 발견될 때까지는 THP를 끄는 것이 가장 좋습니다.
\"sudo echo > file\"은 생각하시는 대로 작동하지 않습니다.
\"sudo sh -c \'echo > file\'\"(또는 echo | sudo tee file)을 입력합니다.
잘 잡았습니다. 수정했습니다. 고마워요!
스왑 가능성이 낮아야 한다는 데 동의하지만, 2.6.32 커널로 몇 가지 테스트를 실행해 볼 수 있습니다. vm.swappiness=0의 동작 방식이 수정되었으며, 일부 RAM이 여전히 파일 캐시에 사용되고 있는 경우에도 커널이 OOM으로 인해 MySQL과 같은 서비스를 죽인다는 보고가 있었습니다. 저는 0이 아닌 1로 실행하는데, 이는 커널이 정말 필요한 경우가 아니면 스왑하지 않아야 하지만 스왑해야 하는 경우 프로세스를 죽이는 대신 스왑할 수 있음을 의미합니다.
멋지네요. 살펴볼게요. 혹시 2.6.32의 변경 사항에 대한 링크가 있으신가요? 없더라도 걱정하지 마세요. 제가 찾아보겠습니다.
여전히 필요한지 확실하지 않지만, 수정 사항과 그에 따른 동작 변화를 요약한 블로그 게시물을 찾았습니다: https://www.percona.com/blog/20...
해당 게시물이 언젠가 사라질 경우를 대비하여 게시물의 일부 정보를 알려드립니다:
커널 코드 커밋 정보:
commit fe35004fbf9eaf67482b074a2e032abb9c89b1dd
저자 저자: 모리야 사토루
Date: Tue May 29 15:06:47 2012 -0700
MM: 스왑으로 교체하지 않기==0
RHEL 변경 로그 정보:
* 2012년 8월 27일 월 자로드 윌슨 [2.6.32-303.el6]
...
- [mm] 스왑으로 교체하지 않기==0 (모리야 사토루) [787885]
내부적으로 확인해 본 결과 이에 대한 논쟁이 있는 것 같습니다. 제가 들은 바로는 스왑을 0으로 설정하는 것이 좋지만, 1로 설정한 고객도 있습니다. 좀 더 자세히 알아보고 테스트를 더 해보겠습니다.
네, 알겠습니다.
대부분 "어떻게 실패하고 얼마나 빨리 실패하기를 원하십니까?"라는 유형의 질문이며 사람들이 자주 접해야하는 상황은 아닙니다. 커널이 카우치베이스를 교체하거나 종료해야 하는 상황에 직면하기 훨씬 전에 RAM 사용량 관련 알람이 울리는 사람이 있었으면 좋겠네요 :)
안녕하세요,
귀하의 조언에 따라 제 rc.local 파일은 다음과 같이 생겼습니다:
————————————————————–
#!/bin/sh -e
#
# rc.local
#
# 이 스크립트는 각 멀티유저 런레벨이 끝날 때마다 실행됩니다.
# 스크립트가 성공 시 \"종료 0\", 오류 시 다른# 값으로 종료되는지 확인합니다.
#
# 이 스크립트를 활성화 또는 비활성화하려면 실행을 변경하기만 하면 됩니다.
# 비트.
#
# 기본적으로 이 스크립트는 아무 작업도 수행하지 않습니다.
[ -x /sbin/initctl ] && initctl emit -no-wait google-rc-local-has-run || true
출구 0
if test -f /sys/kernel/mm/transparent_hugepage/enabled; then
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
fi
if test -f /sys/kernel/mm/transparent_hugepage/defrag; then
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/defrag
fi
——————————————————————————-
이제 저는 리눅스에 정말 익숙하지만 종료 0은 transparent_hugepage 테스트에 도달하지 못한다는 것을 의미하지 않나요? 이 문제를 이해 / 수정하도록 도와주세요.
감사합니다,
David
[...] 종종 간과되는 Linux 조정 [...]