Category: Linux

Python, SaltStack 편집을 위한 vim 세팅

서버를 다루다보면 Python, SaltStack 을 작성해야 하는데 이를 위해서 윈도우즈로 다운로드 받아서 편집기를 열어서 하기가 영 귀찮습니다. 터미널을 이용해기 때문에 vim 를 이용하면 아주 편한데, 이 문서는 Python, SaltStack 편집을 위한 vim 세팅 위한 것입니다.

환경

환경이 중요합니다. 이 문서의 환경은 다음과 같습니다.

  • OS Distro: Ubuntu 16.04
  • vim version: 7.4
  • Python Virtualenv: /home/systemv 계정에 Python 가상환경을 만들었으며 여기에 각종 Python 라이브러리가 설치되어 있다.

Vundle 플러그인 설치

Vundle 은 vim 플러그인 입니다. 이 플러그인은 vim 의 각종 플러그인을 아주 편하게 설치 및 관리를 해주는 플러그인 매니저 입니다.

다음과 같이 설치 해줍니다.

git 를 이용해서 Vundle 플러그인 매니저 파일을 vim 디렉토리에 다운로드 받습니다.

.vimrc 파일 작성

이제 vim 의 환경설정 파일을 다음과 같이 작성합니다.

위와같이 작성한 후에 vim 을 실행해 명령어 모드에서 다음과 같이 입력해줍니다.

Neosnippet 설치.

이 플러그인은 코드 스냅피를 지원해줍니다. vim 설정 파일에서 Vundle 블럭 사이에 다음을 추가해줍니다.

시스템 버퍼에 있는 키워드를 완성해 줍니다.

jedi-vim 설치.

awesome Python autocompletion with VIM

Python 을 위한 자동완성 플러그인 입니다. 이는 jedi 라는 파이썬 라이브리를 설치해줘야 합니다. Python 은 가상환경을 사용하기 때문에 가상환경를 이용해서 설치해줍니다.

이제 jedi-vim 를 설치해줍니다. 역시 Vundle 를 이용해서 설치 합니다.

Powerline status bar

vim 를 사용하면서 각종 필요한 정보를 화면 아래에 상태바로 보여 줍니다.

다음과 같이 vim 설정을 해줍니다.

Python 문법 체크

이제 Python 문법 체크를 위해서는 먼저 파이썬 문법체크 라이브러리를 설치해 줍니다. 역시 가상환경에서 설치 해줍니다.

pep8, pyflakes를 문법 체크를 위한 라이브러리이며 autopep8 은 vim 플러그인에서 사용하기 위한 의존성 패키지 입니다. 이는 잘못된 문법을 자동으로 고쳐줍니다.

이제 vim 플러그인을 설치해 줍니다.

그리고 vim 설정에 다음과 같이 입력해 줍니다.

Python 문법 체크를 위해서 Autopep8 을 사용하는데 이를 vim 에서 사용할 수 있도록 도와주는 플러그인을 설치합니다.

위와같이 하면 ftplugin 디렉토리에 python_autopep8.vim 파일이 생성 됩니다.

python 을 위한 설정으로 다음과 같이 python.vim 파일을 작성해 ftplugin 디렉토리에 넣어둡니다.

위 파일은 python 파일 타입에 한해서 vim 설정을 적용해 줍니다.

SaltStack 을 위한 vim 설정.

다음과 같이 아주 간단히 설정을 할수 있습니다.

최종 .vimrc 파일 내용

 

 

Python pip 를 일반계정에 설치하는 방법

시스템을 운영하다 보면 Python 을 많이 사용하게 되는데, 리눅스 시스템의 경우에 기본적으로 Python 이 설치되어 있다. 하지만 pip 는 기본적으로 설치되지 않는데 이것을 설처하기 위해서 리눅스 시스템의 슈퍼유저인 root 사용자 계정을 빌리거나 설치 요청을 하는 경우가 많다.

하지만 일반계정으로 pip 를 사용할 수 있는데 이에 대해 간단히 소개한다.

디렉토리 생성하기

일반계정일 경우에 홈디렉토리에 bin 디렉토리를 생성하고 PATH 쉘 변수를 설정하면 되는데 이럴경우 홈디렉토리에 노출되는데 이를 숨기기 위해서 숨김 디렉토리로 설정한다.

숨김 디렉토리를 생성한 후에 PATH 쉘 변수를 만들고 Bash 환경파일에 기록한 후에 적용해 준다.

get-pip.py 이용 설치

이제 일반계정으로 pip 설치를 위해 get-pip.py 를 다운받아 다음과 같이 설치 한다.

그리고 다음과 같이 설치한다.

핵심은 –user 옵션이다.

이렇게 하면 pip 관련된 파일들이 ~/.local/bin 디렉토리에 생성된다. 관련 라이브러리들도 ~/.local/lib 함께 생성된다.

pip 를 이용해 패키지를 설치할때도 역시 다음과 같이 –user 옵션을 이용한다.

 

Database 를 위한 공유 메모리, HugePages 계산하기

Database 시스템은 공유메모리 혹은 HugePages 에 매우 의존적입니다. 서버에서 데이터베이스가 가동되면 Database 가 사용하는 메모리는 Database만을 위해서 사용되어 집니다. 대부분의 큰 Database 시스템은 다른 서버 프로그램 없이 단독으로 설치되어 운영되어지기 때문에 얼마만큼 물리적 메모리를 Database 에 할당할지가 Database 시스템 전체에 큰 영향을 미칩니다.

이 글에서 Database 시스템을 위한 공유메모리, HugePages 등을 할당할때에 고려사항은 무엇이며 얼마나 할당하는 것이 좋은지를 살펴보겠습니다.

Oracle 11g or 12c

먼저 Oracle 은 물리적 메모리에 약 80% 를 Oracle 이 사용하도록 할당하도록 합니다. 여기서 대략 80% 라고 했는데, 만일 몇가지 프로그램을 함께 돌린다면 약 75% 가 적당합니다.

물리 메모리의 약 80% 할당

여기서 고려해야할 사항이 하나 있습니다. 80%를 할당하라고 해서 무조건 80%를 할당하게 되면 문제가 됩니다. 예를들어 16GB 의 물리 메모리로 운영하는 경우에 80%면 12.8GB 이고 서버에서 사용가능한 용량은 3.2GB 입니다. 요새 데스크탑 컴퓨터도 안되도 4GB 는 사용하는데 아무리 가벼운(?) 리눅스 서버라도 3.2GB 는 운영하는데 너무 적어 보입니다.

이럴때는 운영체제에서 사용할 최소 메모리를 남겨두고 나머지를 Oracle 에 할당하는게 현명하다고 할 수 있습니다.

또하나 중요하게 고려해야할 사항은 Oracle 에서 AMM을 쓰느냐 안쓰느냐 하는 문제 입니다. 이 둘의 차이는 다음과 같습니다.

AMM 을 사용할 경우: /dev/shm 장치를 이용한 공유메모리 모델 사용. HugePages 사용 불가

AMM을 사용하지 않을 경우: System V 공유 메모리 모델 사용. HugePages 사용 가능

 

Oracle 11g 버전으로 넘어오면서 전에 없던 기능이 하나 생겼는데, 그것은 바로 AMM(Aotomactic Memory Management) 입니다. AMM은 Oracle의 메모리 모델인 SGA와 PGA 를 통틀어서 메모리 관리를 자동으로 해준다는 개념입니다.

AMM 기능을 이용하면 대략적으로 SGA 영역은 Oracle 할당받은 메모리 영역에서 85%, PGA 는 약 15%로 나눠서 관리한다고 합니다.

또 한가지 AMM의 특징이 있는데, 공유메모리 모델중에서 /dev/shm 장치를 이용한 Posix 규격의 공유메모리 모델을 사용한다고 합니다. 이 메모리 모델은 메모리 가상 장치를 통해서 프로세스가 공유할 내용을 파일로 저장해서 공유하는 방법으로 오로지 용량에만 제약사항이 있습니다. 공유할 내용을 파일로 생성할때에 얼마만한 크기로 생성할지는 전적으로 서버 프로그램, 여기서는 Oracle, 에 의해서 결정됩니다. 최근의 모든 리눅스 서버는 /dev/shm 이 자동으로 마운트되어 있으며 기본적으로 전체 물리메모리의 50%를 사용합니다.

용량을 바꾸기 위해서는 다음과 같이 해줍니다. CentOS 6과 CentOS 7 배포판 별로 차이가 조금 있습니다.

 

만일 AMM을 사용하지 않을 경우에는 SystemV 의 공유메모리 설정을 따르게 됩니다. 이때에 HugePages 도 함께 사용할 수 있습니다. 이 설정들은 커널 파라메터로 조정하며 그 설정 변수는 다음과 같습니다.

shmmax: 단일 프로세스가 공유메모리를 호출하기 위한 최대 값. 단위 Bytes

shmall: 시스템을 통틀어 사용가능한 공유 메모리 Page 량. 단위 Page

nr_hugepages: Huge 페이지 개수.

 

여기서 중요한 것이 만일 HugePages 를 사용한다면 shmall 은 사용되지 않습니다. shmall 은 리눅스 메모리의 기본단위인 4096bytes(4k) 를 기반으로 계산되어 지는데, HugPages 는 이보다 더 큰 2048k(2MB) 를 기반으로 페이지를 나누기 때문입니다.

어찌됐든 이런 모든 상황을 고려해서 사용가능한 메모리를 구한다면 다음과 같은 공식으로 구할 수 있습니다.

보시면 아시겠지만 다른분이 만들어놓은 것으로 최소 500MB 용량을 넘는 것으로해서 shmmax, shmall, hugepages 를 모두 계산하고 있습니다.

MySQL 5.x

MySQL 의 경우에, InnoDB 엔진만을 사용한다는 전제하에, 전체 메모리의 80%를 MySQL이 할당해서 사용하도록 설정합니다.

물리 메모리의 약 80%를 MySQL에 할당(InnoDB만 사용)

MySQL 은 오로지 SystemV 의 공유메모리 모델을 따릅니다. 따라서 HugePages 를 사용할 수 있는데, 이를 위해서는 다음과 같이 my.cnf 에 설정을 해줘야 합니다.

그리고 shmmax,shmall,nr_hugepages 는 앞에 스크립트를 이용해서 구합니다.

Linux 설정

SystemV 공유 메모리 모델의 경우에 몇가지를 더 해줘야 합니다.

첫째로 Transparent Huge Pages (THP) 설정을 꺼야 합니다. 성능저하가 발생한다고 하네요. 다음과 같이 간단히 처리 할 수 있습니다.

매번 부팅시마다 자동으로 설정하고 싶다면 부팅 파라메터를 수정해 줍니다.

Ubuntu 의 경우에는 다음과 같이 해줍니다.

CentOS 의 경우에는 다음과 같이 해줍니다.

확인도 가능한데, 다음과 같이 AnonHugePages 값이 0Kb 명 THP 가 비활성화 된 것입니다.

마지막으로 커널이 HugePage 를 사용할 그룹이 누군지를 지정해 줍니다.

위와같이 리눅스 시스템 사용자의 그룹ID 를 알아내도록 명령어를 입력할 수도 있고 아니면 그냥 그룹ID를 찾아서 적어줘도 됩니다.

x86_64 시스템에서 4MB 크기 HugePageSize 변경 불가.

HugePage 는 Linux 의 기본 메모리 페이지 크기인 4K(4096) 가 아닌 더 큰 페이지를 사용하도록함으로서 잦은 메모리 액세스를 줄여 자원 소모를 줄이게 해준다.

최신의 Linux 는 전부 이것을 지원하며 다음과 같이 확인 할 수 있다.

기본 메모리 페이지는 Hugepagesize 인 2MB(2048kb) 임을 확인할 수 있다.

그런데, 이 메모리 페이지 크기를 바꿀 수 있지 않을까? 결론부터 말하면 불가능하다.

이 Hugepagesize 는 CPU 지원에 의존한다.

  • 2MB – cpu에 ‘pse’ 가 지원되면 된다.
  • 1G – cpu 가 ‘pdpe1gb’ 가 지원되면 된다.

최신의 CPU 는 위 두가지 ‘pse’, ‘pdpe1gb’ 를 모두 지원한다. 1GB 의 메모리 페이지를 지원한다. 하지만 4MB 의 메모리 페이지를 지원하지 않는다. 그렇다면 왜 이 글을 쓰는가? 이유는 MySQL 문서 때문이다.

shell> cat /proc/meminfo | grep -i huge
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 4096 kB

https://dev.mysql.com/doc/refman/5.7/en/large-page-support.html

MySQL 문서를 보면 위와 같이 4096Kb 라고 나온다. 하지만 x86_64 시스템에서는 절대로 4096kb 가 될수가 없다. 2MB 아니면 1GB 만 가능하다.

혹시나 해서 이것을 바꾸기 위해서 다음과 같이 부팅 파라메터를 주고 재부팅을 해뒀다.

하지만 부팅 메시지에 다음과 같이 나온다.

지원하지 않는다는 메시지를 보여준다.

결론은 Hugepagesize 는 CPU 에서 지원해줘야 하는 것이며 최신의 x86_64 의 경우 2MB, 1GB 두가지만 지원한다.

Linux PAGE_SIZE 그리고 HugePage

 

다음의 글이 도움이 될 듯 싶다.

Kernel hugepages does not alter the calculation of SHMMAX, which you need to set large enough to fit your largest Oracle SGA. SHMMAX applies to SYS V shared memory, which can be hugepages or use conventional 4K memory pages. SHMMAX is not relevant when you use /dev/shm POSIX shared memory (Oracle AMM).

The Oracle database requires shared memory for the SGA. This can be Sys V (IPC) or POSIX /dev/shm.

Shared memory and semaphores, and the SHM kernel parameters, belong to System V IPC, which can be monitored using the ipcs command. Sys V shared memory can be configured to be 2 MB kernel hugepages, or use the default 4 KB memory pages. Kernel hugepages can drastically reduce the memory requirements for managing required memory pages and make better use of the TLB buffer.

The SHMMAX parameter is used to define the maximum size (in bytes) for a shared memory segment and should be set large enough for the largest SGA size. If the SHMMAX is set incorrectly, for example too low, you may receive the following error: ORA-27123: unable to attach to shared memory segment.

SHMMAX for a server that runs Oracle database is typically set to 4 TB or whatever the platform being x86 or x64 theoretically supports. The parameter is a safeguard parameter. A process cannot use more shared memory than available. Obviously this is not considered a risk when using a dedicated server for running Oracle database.

POSIX shared memory maps shared memory to files using a virtual shared memory filesystem in RAM. It uses /dev/shm and applies when configuring the Oracle database to use Automatic Memory Management (AMM). An Oracle instance can use either Sys V shared memory including kernel hugepages or /dev/shm for SGA, but not both at the same time. You can however use different shared memory concepts for different Oracle instances on the same server. For example, running an +ASM instance using AMM and another Oracle database instance using ASMM.

https://community.oracle.com/thread/3828422

XFS 마운트 옵션.

XFS 파일 시스템은 요즘에 들어서 많이 사용되는 파일 시스템입니다. SGI 회사에서 개발한 것으로 대용량 파일 시스템으로 특화되어 있습니다. 최근들어 Big Data 가 대두되면서 스토리지 용량이 대용량화 되면서 XFS 가 떠오르는데, CentOS 7 배포판은 기본 파일시스템으로 XFS 가 되었습니다.

XFS 는 옵션들이 많이 있는데, 보통 대용량으로 많이 사용할 경우에 다음과 같은 옵션을 주로 많이 사용합니다.

 

Apache 2.4 에서 RemoteIPInternalProxy 의미

Apache 2.4 에서 RemoteIPInternalProxy 는 다음과 같이 사용합니다.

이 문법을 X-Forwared-For 와 함께 사용하면 다음과 같다.

X-Forwarded-For 는 원격지 주소를 192.0.2.1 이 된다. 그런데 RemoteIPInternalProxy 의 영향으로 인해서 192.0.2.1 은 내부 Proxy 로 지정되었기 때문에 X-Forwarded-For 의 원격지 주소는 198.51.100.2 가 된다.

ps, X-Forwarded-For 는 여러개의 IP를 기록할 수 있다. 만일 여러개를 기록할 경우에 맨 오른쪽에 IP가 최종 원격지 IP 주소가 된다.