Postgres 데이터베이스에 접속하는 애플리케이션에 대해 부하 테스트를 실행 중입니다.
테스트 중에 갑자기 오류율이 증가했습니다. 플랫폼과 애플리케이션 동작을 분석한 후 다음 사항을 확인했습니다.
- Postgres RDS의 CPU는 100%입니다.
- 동일한 서버에서 사용 가능한 메모리가 떨어집니다.
그리고 postgres 로그에는 다음이 표시됩니다.
2018-08-21 08:19:48 UTC::@:[XXXXX]:LOG: 서버 프로세스(PID XXXX)가 신호 9에 의해 종료되었습니다: 종료됨
문서를 조사하고 읽은 후 Linux oomkiller가 실행되어 프로세스를 종료했을 가능성이 있는 것으로 보입니다.
하지만 RDS를 사용 중이므로 확인을 위해 시스템 로그/var/log 메시지에 액세스할 수 없습니다.
그래서 누군가는:
- oom killer가 실제로 Postgres용 AWS RDS에서 실행되는지 확인
- 이것을 확인할 수 있는 방법을 알려주시겠어요?
- 연결 수에 따라 Postgres에서 사용하는 최대 메모리를 계산하는 방법을 알려주시겠습니까?
여기서는 답을 찾지 못했습니다.
답변1
OOM 킬러가 작동하지 않더라도(아마 작동했을 것입니다), 100% CPU를 유지하고 사용 가능한 메모리가 매우 낮은 것은 성능에 좋지 않습니다.
더 큰 인스턴스 크기를 사용하고 문제가 해결되는지 확인하십시오. 제어하는 RDS가 아닌 Postgres에서 더 작은 크기를 테스트하고 OOM 킬러가 화를 내는지 확인하세요.
연결 수가 반드시 메모리 소비를 지배하는 요소는 아닙니다. 공유 메모리는 다른 용도로 사용되며 모든 쿼리가 큰 메모리 덩어리를 사용하는 것은 아닙니다. 이 대화도 참조하세요:PostgreSql은 각 연결에 메모리를 할당합니다..
추가 조언Amazon RDS 모범 사례
DB 인스턴스 RAM 권장 사항
Amazon RDS 성능 모범 사례는 작업 세트가 거의 완전히 메모리에 상주하도록 충분한 RAM을 할당하는 것입니다. 작업 세트가 거의 모두 메모리에 있는지 확인하려면 DB 인스턴스가 로드되는 동안 ReadIOPS 지표(Amazon CloudWatch 사용)를 확인하십시오. ReadIOPS 값은 작고 안정적이어야 합니다. DB 인스턴스 클래스를 더 많은 RAM이 있는 클래스로 확장하면 ReadIOPS가 급격히 감소하는 경우 작업 세트가 메모리에 거의 완전히 포함되지 않은 것입니다. 확장 작업 후 ReadIOPS가 더 이상 급격하게 떨어지지 않거나 ReadIOPS가 아주 작은 양으로 줄어들 때까지 계속해서 확장합니다.
성능 지표 평가
여유 메모리 – DB 인스턴스에서 사용할 수 있는 RAM의 양(MB)입니다. 모니터링 탭 지표의 빨간색 선은 CPU, 메모리 및 스토리지 지표에 대해 75%로 표시됩니다. 인스턴스 메모리 소비량이 해당 선을 자주 넘는 경우 이는 워크로드를 확인하거나 인스턴스를 업그레이드해야 함을 나타냅니다.
답변2
저는 Postgres에 대한 경험이 많지 않지만 같은 상황에서 RDS MySql 인스턴스가 완전히 재부팅되는 경향이 있다는 것을 알게 되었습니다. 기본 시스템에 대한 액세스 권한이 없더라도 웹 콘솔을 통해 postgres 로그를 얻을 수 있습니다. 다시 부팅하면 데몬이 닫히고 시작 중임을 나타내야 합니다.
어쨌든 위험 지역에서 일하고 있다면. 당신이 할 수 있는 일은 많지 않습니다. 사용 가능한 RAM/CPU가 더 많은 인스턴스로 이동해야 합니다.