PostgreSQL 성능을 향상시키기 위한 Linux 조정. 일리아 코스모데먀스키

Ilya Kosmodemyansky의 2015년 보고서 녹취록 "PostgreSQL 성능을 향상시키기 위한 Linux 튜닝"

면책 조항: 이 보고서의 날짜는 2015년 4월입니다. 9.4년 이상이 흘렀고 많은 시간이 흘렀습니다. 보고서에서 논의된 버전 4는 더 이상 지원되지 않습니다. 지난 5년 동안 15개의 새로운 PostgreSQL 릴리스가 출시되었고 XNUMX개의 Linux 커널 버전이 출시되었습니다. 이 구절을 다시 쓰면 결국 다른 보고서가 나올 것입니다. 그러나 여기서는 오늘날에도 여전히 관련이 있는 PostgreSQL에 대한 기본적인 Linux 조정을 고려합니다.

내 이름은 Ilya Kosmodemyansky입니다. 저는 PostgreSQL-Consulting에서 일하고 있습니다. 이제 일반적인 데이터베이스, 특히 PostgreSQL과 관련하여 Linux로 수행할 작업에 대해 조금 이야기하겠습니다. 원칙이 매우 유사하기 때문입니다.

우리는 무엇에 대해 이야기할까요? PostgreSQL과 통신하려면 어느 정도 UNIX 관리자여야 합니다. 무슨 뜻이에요? Oracle과 PostgreSQL을 비교한다면 Oracle에서는 DBA 데이터베이스 관리자가 80%, Linux 관리자가 20%여야 합니다.

PostgreSQL을 사용하면 조금 더 복잡해집니다. PostgreSQL을 사용하려면 Linux 작동 방식을 훨씬 더 잘 이해해야 합니다. 그리고 동시에 기관차를 조금 따라 달려보세요. 최근에는 모든 것이 아주 훌륭하게 업데이트되었기 때문입니다. 그리고 새로운 커널이 출시되고, 새로운 기능이 나타나고, 성능이 향상됩니다.

우리가 리눅스에 대해 이야기하는 이유는 무엇입니까? 우리가 Linux 컨퍼런스 Peter에 참석했기 때문이 아니라 현대 상황에서 일반적으로 데이터베이스, 특히 PostgreSQL을 사용하는 데 가장 정당한 운영 체제 중 하나가 Linux이기 때문입니다. 불행히도 FreeBSD는 매우 이상한 방향으로 발전하고 있기 때문입니다. 그리고 성능과 다른 많은 것들 모두에 문제가 있을 것입니다. Windows에서 PostgreSQL의 성능은 일반적으로 Windows가 UNIX와 동일한 공유 메모리를 갖지 않는 반면 PostgreSQL은 다중 프로세스 시스템이기 때문에 모두 이와 관련되어 있다는 사실을 기반으로 하는 별도의 심각한 문제입니다.

그리고 다들 솔라리스 같은 외래종에는 관심이 덜한 것 같아서 가보죠.

최신 Linux 배포판에는 커널 빌드 방법에 따라 1개가 넘는 syctl 옵션이 있습니다. 동시에, 다른 견과류를 살펴보면 여러 가지 방법으로 무언가를 조정할 수 있습니다. 마운트 방법에 대한 파일 시스템 매개변수가 있습니다. 시작 방법에 대해 질문이 있는 경우: BIOS에서 활성화할 항목, 하드웨어 구성 방법 등

이것은 하나의 짧은 보고서가 아니라 며칠에 걸쳐 논의할 수 있는 매우 큰 볼륨입니다. 그러나 이제는 중요한 사항, 즉 Linux에서 데이터베이스를 제대로 사용하지 못하게 하는 레이크를 피하는 방법에 중점을 둘 것입니다. 수정하지 마십시오. 그리고 동시에 중요한 점은 데이터베이스에 맞는 설정에 많은 기본 매개변수가 포함되어 있지 않다는 것입니다. 즉, 기본적으로 제대로 작동하지 않거나 전혀 작동하지 않습니다.

Linux에는 어떤 전통적인 튜닝 대상이 있습니까? 여러분 모두 Linux 관리를 다루고 있으므로 대상이 무엇인지 특별히 설명할 필요는 없다고 생각합니다.

다음을 조정할 수 있습니다.

• CPU.
• 기억.
• 저장.
• 다른. 이에 대해서는 마지막에 간식으로 이야기하겠습니다. 예를 들어, 에너지 절약 정책과 같은 매개변수도 매우 예측할 수 없고 가장 기분 좋은 방식이 아닌 방식으로 성능에 영향을 미칠 수 있습니다.

PostgreSQL과 데이터베이스의 일반적인 특징은 무엇입니까? 문제는 개별 너트를 조정할 수 없으며 성능이 크게 향상되었음을 확인할 수 없다는 것입니다.

예, 그러한 장치가 있지만 데이터베이스는 복잡한 것입니다. 서버가 가지고 있고 최대한 상호 작용하기를 선호하는 모든 리소스와 상호 작용합니다. 호스트 OS 사용 방법에 대한 Oracle의 현재 권장 사항을 살펴보면 몽골 우주 비행사에 대한 농담과 같을 것입니다. 개에게 먹이를주고 아무것도 만지지 마십시오. 데이터베이스에 모든 리소스를 제공하면 데이터베이스 자체가 모든 것을 정렬합니다.

원칙적으로 상황은 PostgreSQL과 어느 정도 동일합니다. 차이점은 데이터베이스가 아직 모든 리소스를 자체적으로 사용할 수 없다는 것입니다. 즉, Linux 수준 어딘가에서 모든 리소스를 직접 정렬해야 합니다.

주요 아이디어는 메모리, CPU 등과 같은 단일 대상을 선택하고 튜닝을 시작하는 것이 아니라 작업 부하를 분석하고 가능한 한 처리량을 향상시켜 좋은 프로그래머가 만든 부하가 발생하도록 노력하는 것입니다. 사용자를 포함한 우리를 위해.

이것이 무엇인지 설명하기 위한 사진이 있습니다. Linux OS 버퍼가 있고, 공유 메모리가 있고, PostgreSQL 공유 버퍼가 있습니다. Oracle과 달리 PostgreSQL은 커널 버퍼를 통해서만 직접 작동합니다. 즉, 디스크의 페이지가 공유 메모리에 들어가려면 커널 버퍼를 통과하고 다시 돌아가야 합니다. 즉, 똑같은 상황입니다.

디스크는 이 시스템 아래에 있습니다. 저는 이것을 디스크로 그렸습니다. 실제로 RAID 컨트롤러 등이 있을 수 있습니다.

그리고 이 입출력은 어떤 방식으로든 이 문제를 통해 발생합니다.

PostgreSQL은 클래식 데이터베이스입니다. 안에 페이지가 있어요. 그리고 모든 입력과 출력은 페이지를 사용하여 발생합니다. 우리는 페이지를 사용하여 블록을 메모리에 생성하고 있습니다. 아무 일도 일어나지 않으면 그냥 읽은 다음 점차적으로 이 캐시와 공유 버퍼에서 사라져 디스크에 다시 저장됩니다.

어딘가에서 무언가를 교체하면 전체 페이지가 더티로 표시됩니다. 여기 파란색으로 표시했어요. 그리고 이는 이 페이지가 블록 스토리지와 동기화되어야 함을 의미합니다. 즉, 우리가 더러워졌을 때 WAL에 항목을 만든 것입니다. 그리고 어느 순간, 체크포인트라는 현상이 찾아왔습니다. 그리고 이 일지에 그가 도착했다는 정보가 기록되었습니다. 이는 그 순간 공유 버퍼에 있던 모든 더티 페이지가 커널 버퍼를 통해 fsync를 사용하여 스토리지 디스크와 동기화되었음을 의미합니다.

이 작업이 수행되는 이유는 무엇입니까? 전압이 손실되면 모든 데이터가 손실되는 상황이 발생하지 않습니다. 모두가 우리에게 말한 영구 메모리는 지금까지 데이터베이스 이론에 속합니다. 이것은 물론 우리가 노력하고 좋아하는 밝은 미래이지만 지금은 영하 20년 안에 살고 있습니다. 물론 이 모든 것을 모니터링해야 합니다.

처리량을 최대화하는 작업은 모든 단계를 미세 조정하여 모든 단계가 빠르게 앞뒤로 이동하도록 하는 것입니다. 공유 메모리는 기본적으로 페이지 캐시입니다. PostgreSQL에서는 선택 쿼리 등을 보냈고 디스크에서 이 데이터를 검색했습니다. 그들은 결국 공유 버퍼에 들어갔습니다. 따라서 이것이 더 잘 작동하려면 많은 메모리가 있어야 합니다.

이 모든 것이 원활하고 빠르게 작동하려면 모든 단계에서 운영 체제를 올바르게 구성해야 합니다. 그리고 균형 잡힌 하드웨어를 선택하십시오. 왜냐하면 어떤 부분에 불균형이 있으면 많은 메모리를 만들 수 있지만 충분한 속도로 서비스되지 않기 때문입니다.

그리고 이러한 각 사항을 살펴보겠습니다.

이러한 페이지를 더 빠르게 앞뒤로 이동하려면 다음을 달성해야 합니다.

• 첫째, 메모리를 사용하여 보다 효율적으로 작업해야 합니다.
• 둘째, 메모리에서 디스크로 페이지가 이동하는 전환이 더 효율적이어야 합니다.
• 셋째, 좋은 디스크가 있어야 합니다.

서버에 512GB의 RAM이 있고 모든 RAM이 캐시 없이 SATA 하드 드라이브에 저장된다면 전체 데이터베이스 서버는 단순한 호박이 아니라 SATA 인터페이스를 갖춘 호박으로 변합니다. 당신은 직접적으로 그것에 직면하게 될 것입니다. 그리고 아무것도 당신을 구할 수 없습니다.

기억과 관련된 첫 번째 점과 관련하여, 삶을 매우 어렵게 만드는 세 가지가 있습니다.

그 중 첫 번째는 NUMA입니다. NUMA는 성능 향상을 위해 만들어진 것입니다. 작업량에 따라 다양한 것을 최적화할 수 있습니다. 그리고 새로운 현재 형태에서는 페이지 캐시 공유 버퍼를 집중적으로 사용하는 데이터베이스와 같은 애플리케이션에는 그다지 좋지 않습니다.

간단히 말해서. NUMA에 문제가 있는지 어떻게 알 수 있나요? 불쾌한 노크가 발생하여 갑자기 일부 CPU에 과부하가 발생합니다. 동시에 PostgreSQL의 쿼리를 분석하고 유사한 것이 없음을 확인합니다. 이러한 쿼리는 CPU를 너무 많이 사용해서는 안 됩니다. 오랫동안 잡을 수 있습니다. PostgreSQL용 NUMA를 구성하는 방법은 처음부터 올바른 권장 사항을 사용하는 것이 더 쉽습니다.

정말 무슨 일이 일어나고 있는 걸까요? NUMA는 비균일 메모리 액세스(Non-Uniform Memory Access)를 나타냅니다. 점은 무엇인가? CPU가 있고 그 옆에는 로컬 메모리가 있습니다. 그리고 이 메모리 상호 연결은 다른 CPU에서 메모리를 끌어올 수 있습니다.

당신이 실행하는 경우 numactl --hardware, 그러면 그렇게 큰 시트를 얻게 될 것입니다. 무엇보다도 거리 필드가 있습니다. 10-20과 같은 숫자가 있습니다. 이 숫자는 이 원격 메모리를 선택하고 로컬에서 사용하기 위한 홉 수에 지나지 않습니다. 원칙적으로는 좋은 생각입니다. 이를 통해 다양한 워크로드에서 성능 속도가 크게 향상됩니다.

이제 하나의 CPU가 먼저 로컬 메모리를 사용하려고 시도한 다음 인터커넥트를 통해 다른 메모리를 가져오려고 한다고 상상해 보십시오. 그리고 이 CPU는 전체 PostgreSQL 페이지 캐시를 가져옵니다. 즉, 몇 기가바이트에 해당합니다. CPU에는 일반적으로 해당 모듈 자체에 메모리가 거의 없기 때문에 항상 최악의 경우가 발생합니다. 그리고 서비스되는 모든 메모리는 이러한 상호 연결을 통과합니다. 느리고 슬픈 것으로 밝혀졌습니다. 그리고 이 노드를 서비스하는 프로세서는 지속적으로 과부하됩니다. 그리고 이 메모리의 액세스 시간이 나쁘고 느립니다. 데이터베이스에 이것을 사용하는 경우 원하지 않는 상황입니다.

따라서 데이터베이스에 대한 더 정확한 옵션은 Linux 운영 체제가 거기에서 무슨 일이 일어나고 있는지 전혀 모르는 것입니다. 그래서 그것은 그대로 메모리에 액세스합니다.

왜 그런 겁니까? 그 반대가되어야 할 것 같습니다. 이는 한 가지 간단한 이유 때문에 발생합니다. 페이지 캐시를 위해 수십, 수백 기가바이트의 많은 메모리가 필요합니다.

그리고 이 모든 것을 할당하고 거기에 데이터를 캐시하면 캐시를 사용하여 얻을 수 있는 이득은 메모리에 대한 까다로운 액세스로 얻을 수 있는 이득보다 훨씬 더 클 것입니다. 따라서 우리는 NUMA를 사용하여 메모리에 더 효율적으로 액세스할 수 있다는 사실과 비교할 수 없는 이점을 얻게 될 것입니다.

따라서 밝은 미래가 도래할 때까지 현재 여기에는 두 가지 접근 방식이 있으며, 데이터베이스 자체는 어떤 CPU에서 실행 중이고 어디에서 무언가를 가져와야 하는지 파악할 수 없습니다.

따라서 올바른 접근 방식은 NUMA를 완전히 비활성화하는 것입니다., 예를 들어 재부팅할 때. 대부분의 경우 상금은 어느 것이 더 나은지에 대한 질문이 전혀 발생하지 않을 정도의 규모입니다.

또 다른 옵션이 있습니다. 우리는 클라이언트가 지원을 위해 우리에게 올 때 서버를 재부팅하는 것이 그에게 큰 일이기 때문에 첫 번째 것보다 더 자주 사용합니다. 그는 거기에 사업을 가지고 있습니다. 그리고 그들은 NUMA 때문에 문제를 경험합니다. 따라서 재부팅보다 덜 침해적인 방법으로 비활성화하려고 노력하지만 비활성화되어 있는지 주의 깊게 확인하십시오. 경험에서 알 수 있듯이 상위 PostgreSQL 프로세스에서 NUMA를 비활성화하는 것이 좋지만 작동할 필요는 전혀 없습니다. 우리는 그녀가 정말로 전원을 껐는지 확인하고 확인해야 합니다.

Robert Haas의 좋은 게시물이 있습니다. 이것은 PostgreSQL 커미터 중 하나입니다. 모든 저레벨 곱창의 핵심 개발자 중 한 명. 그리고 이 게시물의 링크를 따라가면 NUMA가 어떻게 사람들의 삶을 어렵게 만들었는지에 대한 몇 가지 다채로운 이야기를 설명합니다. 데이터베이스가 제대로 작동하려면 서버에서 구성해야 할 사항에 대한 시스템 관리자 체크리스트를 연구하세요. 이러한 설정은 기록하고 확인해야 합니다. 그렇지 않으면 그다지 좋지 않기 때문입니다.

이는 제가 설명할 모든 설정에 적용됩니다. 그러나 일반적으로 데이터베이스는 내결함성을 위해 마스터-슬레이브 모드로 수집됩니다. 언젠가 사고가 나서 슬레이브로 전환하여 마스터가 될 것이기 때문에 슬레이브에서 이러한 설정을 수행하는 것을 잊지 마십시오.

긴급 상황에서 모든 것이 매우 나쁘고 전화가 계속 울리고 상사가 큰 막대기를 들고 달려 오면 확인할 시간이 없습니다. 그리고 그 결과는 매우 비참할 수 있습니다.

다음 요점은 거대한 페이지입니다. 거대한 페이지는 별도로 테스트하기 어렵고 이를 수행할 수 있는 벤치마크가 있더라도 그렇게 할 필요가 없습니다. Google에서는 쉽습니다.

점은 무엇인가? 예를 들어 30GB가 넘는 RAM을 갖춘 그다지 비싸지 않은 서버가 있습니다. 거대한 페이지를 사용하지 않습니다. 이는 메모리 사용량 측면에서 확실히 오버헤드가 있음을 의미합니다. 그리고 이 오버헤드는 가장 즐거운 것과는 거리가 멀습니다.

왜 그런 겁니까? 그래서 무슨 일이야? 운영 체제는 메모리를 작은 조각으로 할당합니다. 정말 편리해요. 역사적으로 그런 일이 일어났거든요. 그리고 자세히 살펴보면 OS는 가상 주소를 물리적 주소로 변환해야 합니다. 그리고 이 프로세스는 가장 간단하지 않으므로 OS는 이 작업의 결과를 TLB(Translation Lookaside Buffer)에 캐시합니다.

그리고 TLB는 캐시이기 때문에 캐시에 내재된 모든 문제는 이 상황에서 발생합니다. 첫째, RAM이 많고 모두 작은 덩어리로 할당된 경우 이 버퍼는 매우 커집니다. 캐시가 크면 검색 속도가 느려집니다. 오버헤드는 정상이며 자체적으로 공간을 차지합니다. 즉, RAM이 잘못된 것에 의해 소비되고 있습니다. 이 시간.

둘째, 이러한 상황에서 캐시가 더 많이 커질수록 캐시 누락이 발생할 가능성이 더 높아집니다. 그리고 이 캐시의 효율성은 크기가 증가함에 따라 급격히 감소합니다. 따라서 운영 체제는 간단한 접근 방식을 제시했습니다. 오랫동안 리눅스에서 사용되어 왔습니다. 얼마 전 FreeBSD에 등장했습니다. 그러나 우리는 Linux에 대해 이야기하고 있습니다. 이것은 거대한 페이지입니다.

그리고 여기서는 거대한 페이지라는 아이디어가 초기에 Oracle 및 IBM을 포함하는 커뮤니티에 의해 추진되었다는 점에 주목해야 합니다. 즉, 데이터베이스 제조업체는 이것이 데이터베이스에도 유용할 것이라고 강력하게 생각했습니다.

그리고 이것이 PostgreSQL과 어떻게 친구가 될 수 있습니까? 첫째, Linux 커널에서 거대한 페이지를 활성화해야 합니다.

둘째, sysctl 매개변수로 명시적으로 지정해야 합니다. 즉, 개수가 몇 개인지 지정해야 합니다. 여기에 있는 숫자는 일부 오래된 서버에서 가져온 것입니다. 거대한 페이지가 들어갈 수 있도록 공유 버퍼 수를 계산할 수 있습니다.

그리고 전체 서버가 PostgreSQL 전용인 경우 좋은 시작점은 RAM의 25%를 공유 버퍼에 할당하거나, 데이터베이스가 확실히 이 75%에 맞을 것이라고 확신하는 경우 75%를 할당하는 것입니다. 시작점 256. 그리고 64GB의 RAM이 있으면 그에 따라 XNUMXGB의 대형 버퍼를 갖게 됩니다. 약간의 여백을 두고 대략적으로 계산하십시오. 이 수치는 무엇으로 설정되어야 합니까?

버전 9.2 이전(실수하지 않는다면 버전 8.2 이후)에는 타사 라이브러리를 사용하여 PostgreSQL을 거대한 페이지와 연결하는 것이 가능했습니다. 그리고 이것은 항상 이루어져야 합니다. 첫째, 거대한 페이지를 올바르게 할당하려면 커널이 필요합니다. 둘째, 이들과 함께 작동하는 애플리케이션이 이를 사용할 수 있도록 하기 위함입니다. 그런 식으로만 사용되지는 않을 것입니다. PostgreSQL은 시스템 5 스타일로 메모리를 할당했기 때문에 libhugetlbfs를 사용하여 이 작업을 수행할 수 있습니다. 이는 라이브러리의 전체 이름입니다.

9.3에서는 메모리 작업 시 PostgreSQL 성능이 향상되었으며 시스템 5 메모리 할당 방법이 중단되었습니다. 모두가 매우 기뻐했습니다. 그렇지 않으면 한 컴퓨터에서 두 개의 PostgreSQL 인스턴스를 실행하려고 할 때 공유 메모리가 충분하지 않다고 말하기 때문입니다. 그리고 그는 sysctl을 수정해야 한다고 말했습니다. 그리고 여전히 재부팅이 필요한 sysctl이 있습니다. 일반적으로 모두가 행복했습니다. 그러나 mmap 메모리 할당으로 인해 거대한 페이지 사용이 중단되었습니다. 대부분의 클라이언트는 대규모 공유 버퍼를 사용합니다. 그리고 9.3으로 전환하지 말 것을 적극 권장합니다. 왜냐하면 오버헤드가 좋은 비율로 계산되기 시작했기 때문입니다.

하지만 커뮤니티에서는 이 문제에 주목했고 9.4에서는 이 이벤트를 아주 잘 재작업했습니다. 그리고 9.4에서는 시도를 활성화하거나 비활성화할 수 있는 매개변수가 postgresql.conf에 나타났습니다.

시도하는 것이 가장 안전한 선택입니다. PostgreSQL이 시작되면 공유 메모리를 할당할 때 거대한 페이지에서 이 메모리를 가져오려고 합니다. 작동하지 않으면 일반 선택으로 롤백됩니다. FreeBSD나 Solaris가 있다면 시도해 볼 수 있습니다. 항상 안전합니다.

켜져 있으면 거대한 페이지에서 선택할 수 없으면 시작되지 않습니다. 여기에는 이미 누구와 무엇이 더 좋은지에 관한 내용이 있습니다. 그러나 시도했다면 오류가 발생할 여지가 많기 때문에 강조해야 할 내용이 실제로 있는지 확인하십시오. 현재 이 기능은 Linux에서만 작동합니다.

더 진행하기 전에 작은 메모를 하나 더 하겠습니다. 투명한 거대한 페이지는 아직 PostgreSQL에 관한 것이 아닙니다. 그는 그것들을 정상적으로 사용할 수 없습니다. 그리고 이러한 워크로드를 위한 투명 거대 페이지를 사용하면 대규모 공유 메모리가 필요할 때 매우 큰 볼륨에서만 이점을 얻을 수 있습니다. 테라바이트의 메모리가 있다면 이것이 작동할 수 있습니다. 더 일상적인 애플리케이션에 대해 이야기하는 경우 컴퓨터에 32, 64, 128, 256GB의 메모리가 있으면 일반적인 대용량 페이지는 OK이므로 Transparent를 비활성화하기만 하면 됩니다.

그리고 기억에 관한 마지막 것은 열매와 직접적인 관련이 없으며, 그것은 당신의 삶을 정말로 망칠 수 있습니다. 서버가 지속적으로 교체된다는 사실은 모든 처리량에 큰 영향을 미칩니다.

그리고 이것은 여러 면에서 매우 불쾌할 것입니다. 그리고 주요 문제는 최신 커널이 이전 Linux 커널과 약간 다르게 동작한다는 것입니다. 그리고 이것은 밟기 매우 불쾌한 일입니다. 왜냐하면 우리가 스왑 작업에 대해 이야기할 때 OOM-killer의 시기적절한 도착으로 끝나기 때문입니다. 그리고 제때에 도착하지 않고 PostgreSQL을 떨어뜨린 OOM-killer는 불쾌합니다. 즉, 마지막 사용자까지 모든 사람이 이에 대해 알게 될 것입니다.

무슨 일이야? 거기에 많은 양의 RAM이 있고 모든 것이 잘 작동합니다. 그러나 어떤 이유로 서버가 스왑에서 중단되고 이로 인해 속도가 느려집니다. 메모리가 많은 것 같지만 이런 일이 발생합니다.

이전에는 vm.swappiness를 32으로 설정하는 것, 즉 스왑을 비활성화하는 것을 권장했습니다. 이전에는 XNUMXGB의 RAM과 이에 상응하는 공유 버퍼가 엄청난 양인 것처럼 보였습니다. 스왑의 주요 목적은 우리가 떨어지면 크러스트를 던질 장소를 마련하는 것입니다. 그리고 그것은 더 이상 특별히 성취되지 않았습니다. 그러면 이 껍질로 무엇을 할 건가요? 특히 이러한 규모의 경우 스왑이 필요한 이유가 명확하지 않은 작업입니다.

그러나 보다 현대적인 커널 버전에서는 동작이 변경되었습니다. 그리고 스왑을 XNUMX으로 설정하면, 즉 끄면 조만간 RAM이 남아 있더라도 가장 집약적인 소비자를 죽이기 위해 OOM 킬러가 올 것입니다. 그는 그러한 작업량이 아직 조금 남아 있다고 생각하고 뛰어 내릴 것입니다. 즉, 시스템 프로세스를 결정하는 것이 아니라 덜 중요한 것을 결정하기 위해 뛰어들 것입니다. 덜 중요한 것은 공유 메모리를 집중적으로 소비하는 포스트마스터입니다. 그 후에는 기지를 복원할 필요가 없으면 좋을 것입니다.

따라서 이제 내가 기억하는 한 기본값은 대부분 6 정도입니다. 즉, 남은 메모리 양에 따라 스왑 사용을 시작해야 하는 시점은 어디입니까? 이제 vm.swappiness = 1로 설정하는 것이 좋습니다. 왜냐하면 이렇게 하면 실질적으로 기능이 꺼지지만 예기치 않게 도착하여 모든 것을 종료하는 OOM-killer와 동일한 효과를 제공하지 않기 때문입니다.

무엇 향후 계획? 데이터베이스의 성능을 이야기하다 점차 디스크 쪽으로 옮겨가다 보면 다들 고개를 갸우뚱하기 시작합니다. 디스크는 느리고 메모리는 빠르다는 사실은 어릴 때부터 누구에게나 익숙하기 때문이다. 그리고 데이터베이스에 디스크 성능 문제가 있다는 것은 누구나 알고 있습니다.

체크포인트 스파이크와 관련된 주요 PostgreSQL 성능 문제는 디스크 속도가 느리기 때문에 발생하지 않습니다. 이는 메모리와 디스크 대역폭의 균형이 맞지 않기 때문일 가능성이 높습니다. 그러나 다른 위치에서는 균형이 맞지 않을 수도 있습니다. PostgreSQL이 구성되지 않았고, OS가 구성되지 않았으며, 하드웨어가 구성되지 않았고, 하드웨어가 올바르지 않습니다. 그리고 이 문제는 모든 것이 정상적으로 발생하는 경우에만 발생하지 않습니다. 즉, 부하가 없거나 설정과 하드웨어가 잘 선택되어 있습니다.

그것은 무엇이며 어떻게 생겼습니까? 일반적으로 PostgreSQL을 사용하는 사람들은 이 문제를 두 번 이상 경험했습니다. 설명하겠습니다. 앞서 말했듯이 PostgreSQL은 공유 메모리의 더티 페이지를 디스크에 덤프하기 위해 주기적으로 체크포인트를 만듭니다. 공유 메모리가 많은 경우 체크포인트는 fsync를 사용하여 이러한 페이지를 덤프하므로 디스크에 집중적인 영향을 미치기 시작합니다. 커널 버퍼에 도착하고 fsync를 사용하여 디스크에 기록됩니다. 그리고 이 사업의 규모가 크면 불쾌한 효과, 즉 디스크 사용률이 매우 높아지는 것을 관찰할 수 있습니다.

여기에 두 장의 사진이 있습니다. 이제 그것이 무엇인지 설명하겠습니다. 이는 두 개의 시간 상관 그래프입니다. 첫 번째 그래프는 디스크 활용도입니다. 현재 시점에서는 거의 90%에 도달합니다. RAID 컨트롤러 사용률이 90%이고 물리적 디스크에 데이터베이스 오류가 있는 경우 이는 나쁜 소식입니다. 즉, 조금 더 지나면 100에 도달하고 I/O가 중지됩니다.

디스크 어레이가 있다면 이야기는 약간 다릅니다. 구성 방법, 배열 종류 등에 따라 다릅니다.

동시에 내부 postgres 보기의 그래프가 여기에 구성되어 체크포인트가 어떻게 발생하는지 알려줍니다. 여기의 녹색은 해당 순간 동기화를 위해 이 체크포인트에 도착한 버퍼, 즉 더티 페이지의 수를 나타냅니다. 그리고 이것이 여기서 알아야 할 주요 사항입니다. 여기에 많은 페이지가 있다는 것을 알 수 있으며 어느 시점에서 우리는 보드를 쳤습니다. 즉, 쓰고 썼습니다. 여기서 디스크 시스템은 분명히 매우 바쁩니다. 그리고 우리의 체크포인트는 디스크에 매우 강한 영향을 미칩니다. 이상적으로 상황은 다음과 같아야 합니다. 즉, 여기서는 녹음 횟수가 적습니다. 그리고 계속해서 이런 상태가 되도록 설정으로 수정하면 됩니다. 즉, 재활용 규모는 작지만 어딘가에 여기에 무언가를 쓰고 있습니다.

이 문제를 극복하려면 어떻게 해야 합니까? 데이터베이스에서 IO를 중지한 경우 이는 요청을 이행하기 위해 온 모든 사용자가 대기한다는 의미입니다.

Linux의 관점에서 보면 좋은 하드웨어를 선택하고 올바르게 구성하고 PostgreSQL을 정상적으로 구성하여 이러한 체크포인트를 덜 빈번하게 만들고 시간이 지남에 따라 서로 간에 분산시킨 다음 기본 Debian 매개변수로 들어갑니다. 대부분의 Linux 배포판의 경우 vm.dirty_ratio=20, vm.dirty_Background_ratio=10과 같습니다.

무슨 뜻이에요? 커널 2.6부터 하나의 플러싱 데몬이 나타났습니다. Pdglush는 누가 무엇을 사용하는지에 따라 커널 버퍼에서 더티 페이지를 백그라운드로 폐기하고 무슨 일이 있어도 더티 페이지를 폐기해야 할 때 폐기하는 데 관여하며, 백그루인드 폐기는 도움이 되지 않습니다.

배경은 언제오나요? 서버에서 사용 가능한 총 RAM의 10%가 커널 버퍼의 더티 페이지에 의해 점유되면 특수 쓰기 해제 기능이 백그라운드에서 호출됩니다. 왜 배경인가요? 매개변수로 쓸 페이지 수를 고려합니다. 그리고 그가 N 페이지를 썼다고 가정해 보겠습니다. 그리고 잠시 동안 이것은 잠들었습니다. 그리고 나서 그녀는 다시 와서 몇 페이지를 더 복사했습니다.

이것은 지극히 단순한 이야기이다. 여기서 문제는 수영장과 같습니다. 한 파이프에 물이 들어가면 다른 파이프로 흘러갑니다. 체크포인트가 도착했고 폐기하기 위해 몇 개의 더티 페이지를 보냈다면 점차적으로 모든 것이 커널 버퍼 pgflush에서 깔끔하게 해결될 것입니다.

이러한 더티 페이지가 계속해서 누적되면 최대 20%까지 누적되며, 그 이후 OS 우선 순위는 모든 것을 디스크에 기록하는 것입니다. 전원이 꺼지고 모든 것이 우리에게 좋지 않기 때문입니다. 예를 들어, 이 데이터는 손실됩니다.

비결은 무엇입니까? 비결은 현대 세계에서 이러한 매개변수가 시스템에 있는 전체 RAM의 20~10%이며, 보유한 디스크 시스템의 처리량 측면에서 절대적으로 엄청난 수준이라는 것입니다.

128GB의 RAM이 있다고 가정해 보세요. 12,8GB가 디스크 시스템에 도착합니다. 그리고 거기에 어떤 캐시가 있든, 어떤 어레이가 있든 상관없이 오래 지속되지는 않습니다.

따라서 RAID 컨트롤러의 기능에 따라 이러한 수치를 즉시 조정하는 것이 좋습니다. 저는 여기서 즉시 512MB의 캐시가 있는 컨트롤러를 추천했습니다.

모든 것이 매우 간단한 것으로 간주됩니다. vm.dirty_Background를 바이트 단위로 넣을 수 있습니다. 그리고 이러한 설정은 이전 두 가지를 취소합니다. 비율은 기본적으로 설정되어 있거나 바이트가 있는 비율이 활성화되면 바이트가 있는 비율이 작동합니다. 하지만 저는 DBA 컨설턴트이고 다양한 클라이언트와 작업하기 때문에 짚을 그리려고 노력하므로 바이트 단위라면 바이트 단위입니다. 좋은 관리자가 서버에 메모리를 추가하지 않고 재부팅해도 수치가 그대로 유지된다는 보장은 아무도 없습니다. 모든 것이 보장되도록 이 숫자를 계산해 보세요.

적응하지 못하면 어떻게 되나요? 나는 모든 플러싱이 효과적으로 중단된다고 썼지만 실제로 이것은 비유적인 표현입니다. 운영 체제에는 큰 문제가 있습니다. 더티 페이지가 많기 때문에 클라이언트가 생성하는 IO가 효과적으로 중지됩니다. 즉, 애플리케이션이 데이터베이스에 SQL 쿼리를 보내려고 왔는데 기다리고 있습니다. 데이터베이스가 체크포인트에 의해 점유되므로 이에 대한 모든 입력/출력의 우선순위가 가장 낮습니다. 그리고 그녀가 언제 끝낼지는 완전히 불분명합니다. 그리고 비백그라운드 플러시를 달성했다면 이는 모든 IO가 해당 플러시에 의해 점유되었음을 의미합니다. 그리고 끝날 때까지 당신은 아무것도 하지 않을 것입니다.

여기에는 이 보고서의 범위를 벗어나는 두 가지 중요한 사항이 더 있습니다. 이러한 설정은 postgresql.conf의 설정, 즉 체크포인트 설정과 일치해야 합니다. 그리고 디스크 시스템이 적절하게 구성되어 있어야 합니다. RAID에 캐시가 있는 경우 배터리가 있어야 합니다. 사람들은 배터리 없이 좋은 캐시를 갖춘 RAID를 구매합니다. RAID에 SSD가 있는 경우 서버 SSD여야 하며 거기에 커패시터가 있어야 합니다. 자세한 체크리스트는 다음과 같습니다. 이 링크에는 PostgreSQL에서 성능 디스크를 구성하는 방법에 대한 보고서가 포함되어 있습니다. 거기에는 모든 체크리스트가 있습니다.

또 무엇이 인생을 매우 어렵게 만들 수 있습니까? 이는 두 가지 매개변수입니다. 그것들은 비교적 새로운 것입니다. 기본적으로 다른 애플리케이션에 포함될 수 있습니다. 그리고 잘못 켜면 생활도 마찬가지로 어려워질 수 있습니다.

비교적 새로운 것이 두 가지 있습니다. 그들은 이미 세 번째 코어에 나타났습니다. 이는 나노초 단위의 sched_migration_cost 및 sched_autogroup_enabled(기본값)입니다.

그리고 그들은 당신의 인생을 어떻게 망치나요? sched_migration_cost란 무엇입니까? Linux에서 스케줄러는 한 CPU에서 다른 CPU로 프로세스를 마이그레이션할 수 있습니다. 그리고 쿼리를 실행하는 PostgreSQL의 경우 다른 CPU로 마이그레이션하는 것이 완전히 불분명합니다. 운영체제 입장에서는 오픈오피스와 터미널 사이에서 창을 전환할 때 이것이 좋을 수도 있지만, 데이터베이스의 경우 이것은 매우 나쁩니다. 따라서 합리적인 정책은 migration_cost를 최소한 수천 나노초 이상의 큰 값으로 설정하는 것입니다.

이것은 스케줄러에게 무엇을 의미합니까? 이 시간 동안 프로세스는 여전히 뜨겁다고 간주됩니다. 즉, 오랫동안 어떤 작업을 수행해 온 장기 실행 트랜잭션이 있는 경우 스케줄러는 이를 이해합니다. 그는 이 제한 시간이 경과할 때까지 이 프로세스를 어디로든 마이그레이션할 필요가 없다고 가정합니다. 동시에 프로세스가 어떤 작업을 수행하면 다른 곳으로 마이그레이션되지 않고 할당된 CPU에서 조용히 작동합니다. 그리고 그 결과는 훌륭합니다.

두 번째 요점은 자동 그룹입니다. 최신 데이터베이스와 관련되지 않은 특정 작업 부하에 대한 좋은 아이디어가 있습니다. 이는 프로세스가 실행되는 가상 터미널을 기준으로 프로세스를 그룹화하는 것입니다. 이는 일부 작업에 편리합니다. 실제로 PostgreSQL은 단일 터미널에서 실행되는 프리포크를 갖춘 다중 프로세스 시스템입니다. 잠금 작성자, 체크포인트가 있으며 모든 클라이언트 요청은 CPU당 하나의 스케줄러로 그룹화됩니다. 그리고 그들은 서로 간섭하고 그를 더 오래 점유하기 위해 그가 자유로워지기를 한마음으로 기다릴 것입니다. 이런 부하의 경우 전혀 불필요한 이야기이므로 꺼야합니다.

내 동료 Alexey Lesovsky는 간단한 pgbench로 테스트를 수행했는데, 여기서 그는 migration_cost를 몇 배나 늘리고 자동 그룹을 껐습니다. 불량 하드웨어의 차이는 거의 10%였습니다.. 사람들이 쿼리 속도에 대해 유사한 변경 결과를 제공하는 postgres 메일링 리스트에 대한 토론이 있습니다. 50% 영향을 받음. 그런 이야기가 꽤 많이 있습니다.

마지막으로 절전 정책에 대해 말씀드리겠습니다. 좋은 점은 이제 노트북에서도 Linux를 사용할 수 있다는 것입니다. 그리고 아마도 배터리를 잘 소모할 것입니다. 그런데 갑자기 이런 일이 서버에서도 일어날 수 있다는 것이 밝혀졌습니다.

또한 일부 호스터로부터 서버를 임대하는 경우 "좋은" 호스터는 귀하의 성능이 더 나은지 신경 쓰지 않습니다. 그들의 임무는 철분을 최대한 효율적으로 활용하는 것입니다. 따라서 기본적으로 운영 체제에서 랩톱 절전 모드를 활성화할 수 있습니다.

로드가 많은 데이터베이스가 있는 서버에서 이 항목을 사용하는 경우 acpi_cpufreq + 성능을 선택합니다. 온디맨드에도 문제가 있을 수 있습니다.

Intel_pstate는 약간 다른 드라이버입니다. 그리고 이제는 이것이 더 나중이고 더 잘 작동하기 때문에 선호됩니다.

따라서 주지사는 단지 성과일 뿐입니다. 온디맨드, 절전 및 기타 모든 것은 귀하에 관한 것이 아닙니다.

PostgreSQL 분석 결과는 절전 기능을 활성화한 경우 몇 배나 달라질 수 있습니다. 실제로 데이터베이스 아래의 CPU는 완전히 예측할 수 없는 방식으로 실행되기 때문입니다.

이러한 항목은 기본적으로 포함될 수 있습니다. 기본적으로 켜져 있는지 주의 깊게 살펴보세요. 이것은 정말 큰 문제가 될 수 있습니다.

마지막으로, 매일 이 문제에 앞장서고 있는 PosgreSQL-컨설팅 DBA 팀의 Max Boguk 및 Alexey Lesovsky 팀원들에게 감사 인사를 전하고 싶었습니다. 그리고 우리는 고객을 위해 최선을 다하여 모든 것이 고객에게 도움이 되도록 노력합니다. 항공 안전 지침과 같습니다. 여기의 모든 것은 피로 쓰여 있습니다. 이 견과류 각각은 일종의 문제 과정에서 발견됩니다. 나는 그것을 당신과 공유하게 되어 기쁘게 생각합니다.

질문 :

감사합니다! 예를 들어, 회사가 비용을 절감하고 데이터베이스와 애플리케이션 로직을 하나의 서버에 배치하려는 경우 또는 회사가 PostgreSQL이 컨테이너에서 실행되는 마이크로서비스 아키텍처의 유행 추세를 따르는 경우입니다. 비결은 무엇입니까? Sysctl은 전체 커널에 전역적으로 영향을 미칩니다. sysctls가 어떻게든 가상화되어 컨테이너에서 별도로 작동한다는 이야기를 들어본 적이 없습니다. cgroup만 있고 컨트롤의 일부만 있습니다. 이걸 가지고 어떻게 살 수 있나요? 아니면 성능을 원한다면 별도의 하드웨어 서버에서 PostgreSQL을 실행하고 조정하시겠습니까?

귀하의 질문에 대해 세 가지 방법으로 답변했습니다. 조정 등이 가능한 하드웨어 서버에 대해 이야기하는 것이 아니라면 안심하세요. 이러한 설정 없이도 모든 것이 잘 작동할 것입니다. 이러한 설정이 필요한 부하가 있는 경우 이러한 설정보다 먼저 아이언 서버에 접속하게 됩니다.

문제는 무엇입니까? 이것이 가상 머신인 경우, 예를 들어 대부분의 가상 머신에서 디스크의 대기 시간이 매우 일관되지 않는다는 사실과 같은 많은 문제가 발생할 가능성이 높습니다. 디스크 처리량이 양호하더라도 체크포인트 시점이나 WAL에 쓸 때 발생한 평균 처리량에 큰 영향을 미치지 않는 I/O 트랜잭션 하나가 실패하면 데이터베이스는 이로 인해 큰 어려움을 겪게 됩니다. 그리고 이러한 문제가 발생하기 전에 이를 알게 될 것입니다.

동일한 서버에 NGINX가 있는 경우에도 동일한 문제가 발생합니다. 그는 공유 기억을 위해 싸울 것입니다. 그리고 여기에 설명된 문제는 해결되지 않습니다.

그러나 반면에 이러한 매개변수 중 일부는 여전히 귀하와 관련이 있습니다. 예를 들어, 너무 이상하지 않도록 sysctl로 dirty_ratio를 설정하십시오. 어쨌든 이것이 도움이 될 것입니다. 어떤 방식으로든 디스크와 상호 작용하게 됩니다. 그리고 그것은 잘못된 패턴을 따르게 될 것입니다. 이는 일반적으로 제가 보여드린 매개변수의 기본값입니다. 그리고 어쨌든 변경하는 것이 좋습니다.

그러나 NUMA에 문제가 있을 수 있습니다. 예를 들어 VmWare는 정반대의 설정으로 NUMA와 잘 작동합니다. 그리고 여기서 철제 서버 또는 비철제 서버를 선택해야 합니다.

Amazon AWS 관련 질문이 있습니다. 사전 구성된 이미지가 있습니다. 그 중 하나가 Amazon RDS입니다. 운영 체제에 대한 사용자 정의 설정이 있습니까?

거기에 설정이 있지만 다른 설정입니다. 여기서는 데이터베이스가 이 기능을 사용하는 방식에 따라 운영 체제를 구성합니다. 그리고 성형과 같이 지금 어디로 가야할지 결정하는 매개 변수가 있습니다. 즉, 자원이 너무 많이 필요해서 이제 다 먹어치울 것입니다. 그 후에는 Amazon RDS가 이러한 리소스를 강화하고 성능이 저하됩니다. 사람들이 어떻게 이 문제를 어지럽히기 시작했는지에 대한 개인적인 이야기가 있습니다. 때로는 아주 성공적이기도 합니다. 그러나 이것은 OS 설정과 관련이 없습니다. 클라우드를 해킹하는 것과 같습니다. 그것은 다른 이야기입니다.

투명 거대 페이지가 거대 TLB에 비해 효과가 없는 이유는 무엇입니까?

주지 마. 이것은 여러 가지 방법으로 설명될 수 있습니다. 그러나 실제로 그들은 그것을 주지 않습니다. PostgreSQL의 역사는 무엇입니까? 시작 시 많은 양의 공유 메모리를 할당합니다. 투명 여부는 전혀 관련이 없습니다. 그들이 처음부터 눈에 띄는 사실이 모든 것을 설명합니다. 메모리가 많고 shared_memory 세그먼트를 다시 빌드해야 하는 경우 투명 거대 페이지가 적합합니다. PostgreSQL에서는 처음에 큰 덩어리로 할당되기만 하면 되고, 그 다음에는 특별한 일이 발생하지 않습니다. 물론 사용할 수 있지만 무언가를 다시 할당할 때 shared_memory가 손상될 가능성이 있습니다. PostgreSQL은 이에 대해 알지 못합니다.

출처 : habr.com