fsync가 on이면, PostgreSQL서버는 fsync()시스템콜을 통해서 변경분을 디스크에 물리적으로 바로 쓴다. 이는 데이터베이스클러스터가 OS나 하드웨어 장애시 consistent한 상태로 복구가 가능함을 보장한다.
fsync를 off한다면, OS가 알아서 메모리에 있는 것을 디스크로 내려쓰게 된다. 언제 무엇이 디스크에 쓰여졌는지 아닌지 알수 없다. 그러므로 성능상 이득을 볼수는 있겠지만, 전원장애나 system crash로가 발생했을때 복구가 불가능할수 있다. 만약 전체 데이터베이스를 쉽게 재생성할수 있는 경우에만 off하도록 한다. 예를들어 백업본으로부터 새로운 데이터베이스 클러스트를 초기 구축하는 경우, 버리고 재생성할 데이터베이스의 데이터 처리, 자주 재생성되는 read-only 데이터베이스 복제본으로 failover에 사용되지 않는 데이터베이스인 경우 사용할 수 있다. 고성능의 하드웨어 장비라고해서 fsync를 끄는 것은 올바르지 않다.
성능을 위해서라면 synchronous_commit을 off하는 것만으로 충분할 것이다.
만약 off하기로 했다면, full_page_writes도 off하는 것을 고려하도록 한다.
WAL 를 사용하여, PITR 지원이 가능
WAL 를 재생하여 복구가 가능
Asynchronous Commit
DB Crash 발생 시, 가장 최근의 Transaction은 유실 가능성 존재(Risk)
다만, transaction 을 더 빠르게 처리가 가능
Default 는 synchronous (동기)
Client에 transaction result를 return 하기 전에, WAL 의 record가 Disk 에 write될 때까지 기다렸다가 ack 처리. -> commit 된 transaction 에 대한 무결성 보장을 의미
다만, 이것에 대한 비용은 발생
이러한 비용을 조금이라도 줄이기 위한 방법으로, disk flush 응답을 받기 전에 WAL buffer에서만 작성 후 ack 하는 방식을 Asynchronous Commit -> Transaction 처리량 향상
synchronous_commit Parameter 를 이용하여 수정이 가능하며, transaction 마다 설정이 가능
off : 클라이언트에 바로 transaction commit을 보냄. 하지만 실제로 트랜잭션이 안전하게 반영(WAL record가 WAL file에 쓰여짐) 되기까지 딜레이가 존재함. 서버 crash났을때 트랜잭션 손실될 수 있음. (최대 delay는 wal_writer_delay(200ms)의 3배). 하지만 fsync와는 달리 off로 한다고 해서 db 일관성에 문제가 되지는 않음. 최근 커밋되어야하는 트랜잭션이 손실될 수는 있으나 database 상태는 이 트랜잭션들이 정상적으로 롤백된 것과 같아서 일관성에 문제 없음.
DROP TABLE 은 synchronous_commit 와 상관없이 동기식으로 처리 : 일관성을 보장하기 위함.
PREPARE TRANSACTION 와 같은 2-phase commit 의 경우도 동기식으로 처리
wal_writer_delay ms 마다 WAL Writer 가 Disk 로 flush 진행
최대 유실 시간은 wal_writer_delay milliseconds * 3 의 risk 가 존재
busy periods(바쁜기간?)에 WAL writer 가 한 번에 Disk 로 flush 를 진행하는 것을 선호로 인해 발생 (정확한 의미는 모르겠습니다. 왜 wal_writer_delay 의 최대 3배의 시간으로 명시했는지.
commit_delay parameter 와 유사하지만, commit_delay 는 synchronous commit 의 방법에 속함
Asynchronous commit 을 설정하면, commit_delay 는 무시
commit_delay 는 transaction 이 WAL disk flush 지연을 유발
checkpoint 이후 각 Disk page를 수정(dml로 인해) 하는 도중에 해당 페이지의 전체 내용을 WAL 에 기록
os crash 발생 시, 진행 중인 페이지 쓰기가 부분적으로만 완료 되어 디스크 상의 페이지에 과거 데이터와 새 데이터가 공존하기 때문에, 복구 진행 시 올바른 복구가 보장되지만 WAL 에 기록하는 데이터량은 증가될 수 밖에 없음
checkpoint 간격을 늘릴 수 있음.
off 하면, 운영 속도가 향상되지만, 시스템 crash 발생 시, 손상된 데이터가 복구 불가능 또는 데이 손사이 발생 가능성 존재
fsync 를 해제했을 때와 유사
PITR 진행 시, WAL 아카이빙 사용에는 영향을 미치지 않음
postgresql.conf 파일 또는 command 로 설정 가능
checkpoint_timeout sec 마다 또는 max_wal_size 가 초과될 경우 checkpoint 발생
default : 5 min (300 sec) / 1 Gb
WAL 에 작성이 안된 경우 checkpoint_timeout 이 되어도 checkpoint 가 발생하지 않음
물론 CHECKPOINT 명령어로 강제 실행은 가능
만약 해당 변수 값들을 줄이며, 더 자주 checkpoint 발생 : DB crash 후 빠른 복구는 가능하지만 Disk I/O 비용 발생
full_page_writes 가 설정된 경우 (default 설정) , check point 발생 후 데이터 페이지 수정이 발생하는 경우 전체 페이지가 기록 -> 더 많은 Disk I/O 발생(시간을 짧게 가져갈수록 disk I/O는 더욱더 증가)
checkpoint_timeout 시간을 충분히 여유있게 가져가는 것을 책에서는 권장하며, checkpoint_warning 로 checkpoint 에 대해 sanity check (온전성 검사?)가 가능
당연하겠지만, checkpoint timeout 보다 더 잦은 checkpoinrt 가 발생하면 max_wal_size 증가 하라는 메시지가 log 에 남음
XLogInsertRecord
Shared memory 내 WAR buffer 에 new record 를 배치하는데 사용
만약 새로운 데이터가 insert 될 공간이 없으면, kernel cache 로 채워진 WAL buffer 일부를 move 시킴 -> 이것은 exclusive lock (대상 data page) 을 유발하기 때문에, 성능에 좋지 않음
일반적으로 XLogFlush 에 의해 WAL buffer 를 WAL file 에 flush 되어야 함.
wal_buffers 를 이용하여 WAL bufferpool 수를 조정 가능하며, full_page_writes 가 설정되어 있고, 시스템이 바쁜경우 wal_buffers 수를 늘려주는 것을 권장
XLogFlush
LogWrite 의 issue_xlog_fsync 의 호출에 의해 XLogFlush 가 WAL buffer 의 내용을 disk 로 flush
commit_delay
commit_delay (ms)는 XLogFlush 내에서 lock 을 획득 하는동안, group commit 을 기다리는 시간(지연시간) parameter
목적은 동시에 commit 되는 transaction 전체에 걸쳐 flush 작업의 비용을 분할할 수 있는 것(다만 transaction 시간은 증가)
commit_delay 가 발생하면, 대기하는 commit record들은 WAL Buffer 에 추가 하여 정합성을 지키는 효과 -> Transaction 대기 시간을 최소화
0 : ( default)그룹 커밋의 효과가 중요
1 : 동시에 commit 이 발생하여 transaction 처리?
2 : 처리량이 commit 속도에 따라 제한 되는 경우 도움 ?
wal_debug 를 활성화 하면, XLogInsertRecord, XLogFlush 의 call 횟수를 확인할 수 있음.
WAL 데이터를 Disk 에 Writer 하는 함수는 XLogWrite and issue_xlog_fsync 존재
WAL 데이터를 동기화하는 데 소요되는 시간은, pg_stat_wal 내의 wal_write_time and wal_sync_time 에 기록
wal_sync_method 가 open_sync 또는 open_datasync 이면, XLogWrite는 WAL 데이터를 Disk 로 flush 하고 데이터 정합성을 보장하고, issue_xlog_fsync 는 어떠한 작업도 하지 않음
wal_sync_method 가 fdatasync , fsync , 또는 fsync_writethrough 가 되면, write opertaion이 WAL buffer 를 kernal cache로 이동하고 issue_xlog_fsync 는 kernal cache 내용을 Disk로 동기화 진행
XLogWrite Write 및 issue_xlog_fsync 가 WAL 데이터를 disk 로 동기화하는 횟수가, pg_stat_wal 에서 wal_write 및 wal_sync 값으로 저장
WAL Internal
WAL 는 rotation 하기 때문에, 관리자가 별도로 disk 관련하여 신경쓰지 않아도 됨
LSN 으로 어느 WAL 파일에 작성해야 하는지 (마지막 지점) 확인
WAL 파일은 Data directory 아래 pg_wal directory 에 segment file 로 저장되며, 16mb
기존에는 innodb_flush_log_at_trx_commit 의 값이 2의 경우, OS buffer 까지 Transaction 내용을 작성하여, DB Crush 에 대해서는 Transaction 의 정합성을 보호해 주었습니다.
이로 인하여 DB 상에서는 Commit, Write latency 등의 각종 Transaction 지표를 향상시켜주는 마법을 보여줬지만, OS Crush에 대해서는 데이터 유실에 대한 위험성은 감수해야 했습니다. (DBA 입장에서는 피하고 싶은 Parameter 수정 중 하나 입니다.)
Aurora mysql 3 version 에서는 innodb_flush_log_at_trx_commit 의 1과 2의 동작이 동일하게 변경 되었습니다. 즉, 기존 2를 사용하여 DML 관련 latency 성능 지표들을 통해 효과를 본 것이, 없어지게 되었습니다.
이건 redo log 동작(Engine Instance에서 log flushing을 처리하는 방식)이 Aurora storage engine 에서 처리하는 것으로 일괄 변경되면서, 기존 Aurora instance 에서 동작+storage engine에서 동작하던 것이 변경된 것으로 이해하면 됩니다.
이는 Aurora mysql 의 Write 에 대한 강점을 더 높인 것이라고 생각합니다.
그래서, 혹시라도 Aurora mysql 3에서의 DML latency를 좀 더 높이면서, 데이터 유실을 감수하겠다고 한다면, 기존 innodb_flush_log_at_trx_commit 의 값을 2가 아닌, 0으로 설정해야 합니다. innodb_flush_log_at_trx_commit 값을 설정하기 전, innodb_trx_commit_allow_data_loss parameter 를 1로 설정한 후, innodb_flush_log_at_trx_commit 변경이 가능합니다. innodb_flush_log_at_trx_commit 를 1로 설정한다는 것 자체가, 다시 한번 데이터 유실에 대한 경감식과 고객이 스스로 인지하고 있다는 것을 확인 받는 것이라고 생각되어 현웃이 터졌네요..ㅎㅎ
자세한 내용은 아래 공홈 확인 부탁 드립니다.
DBA 는 데이터 유실에 대해서는 항상 애민해질 수 밖에 없는 이슈이며, 또한 서비스 운영하는 개발자 분들의 서비스 성능에 대한 논의를 할때 해당 Parameter 가 꼭 거론 되는 내용이라 공유해 봅니다.
서비스 성능은 DB를 잘 사용하면, 엄청난 효과를 가져오지만, 그렇다고 데이터 유실에 대한 Risk를 가져가면서 서비스 성능을 높이는 것은 다른 이야기 입니다.
Admin 에 대해 고급까지는 아니지만, 중급까지는 공부합니다. 아키텍처 및 동작 방식까지 공부 합니다. 5명(모집자 포함) 모두 발표 합니다. (하루전에 발표 자료 공유 부탁 드립니다.) 모집 인원은 모두 찾았습니다. Postgresql 운영만 최소 3년 이상 리더 한분 섭외(리더는 내용에 대해 경험에 대해 발표-리더도 발표합니다.) 2주에 한번 합니다. 현생이 힘듭니다...
목차
Postgresql 에 대한 소개
Postgresql 설치
rpm 패키징 설치는 간략하게
Source 설치에 대해서 진행합니다.
원하는 곳에 Log, Data file 지정이 필요
Source 수정까지는 아니지만 필요할때는 코드라는걸 한법 봅시다.
업그레이드 / 다운그레이드
무중단 업그레이드 위주로 테스트
HA
Major 설정값(parameter) 위주로 확인 (메모리, path, character set 등)
Aurora Postgresql 간략하게(자세하게 확인은 맨 마지막에)
Postgresql Architecture
내부 구조에 대해 두리뭉실하게...
client
Server
process
내부 process (Wal, vacuum 등)
memory
Files
계정 및 권한
내부 Architecture 와 연관
Schema, Database, table 에 대한 권한과 권한에 따른 영향
계정에 대한 관리
Transaction 과 Lock 관리
Index
Optimize 와 Hint, Explain
내부 명령어 및 system 테이블
백업 복구
반드시 한번씩 해봅시다.
Full backup / restore, Incremental backup, PITR
옵션도 공부합시다.
Third party 하나 정도 이용해 봅시다.
동작 방식도 이해합니다.
DB 이관 (Oracle to Postgresql)
주의 점
단순 Migration 외의 서로 다른 엔진 특성 상 수정 되어야 하는 설계
모니터링
모니터링 지표들과 조회 방식
Third party tool
그 외 추가 되어야 하는 내용들
참고 사이드
개인적으로 북마크하는 곳이지만, 그 외 많은 숨고 사이트가 있습니다. 공홈 : https://www.postgresql.org/ postgresql dba 커뮤니티 : https://www.postgresdba.com/ 페이스북 통해서 확인 : https://postgresql.kr/ 넘사벽 김두비 : https://kimdubi.github.io/postgresql/
한글로 된 자료도 많지가 않아서 초등이하 수준의 영어를 번역기 돌리고 나쁜 머리로 이해하고 쓰느라 부족한 부분이 많습니다. 부디 저의 글이 도움이 되어, 보다 자세하고 정확한 글들이 나오길 기대하는 마음으로 작성하였습니다.
Logical Session
server session 또는 logical session 은 클라이언트에서 Causal Consistency 와 다시 쓰기 시도(retryable write)와 같은 기본 프레임 워크를 지원
Logical session(식별자)을 생성함으로써, single operation 또는 multiple-operation transaction에서 사용되는 리소스를 추적이 가능
이러한 프레임 워크를 이용하여 Transaction 을 구현이 가능
Logical session 과 Logical session Identifier(식별자) 를 만드는데, 이것을 lsid라고 하고 lsid는 유니크한 값으로 mongodb cluster와 client간 연결
MongoDB 3.6이후로는 client 조작은 모두 logical session 과 연관되며, lsid가 클러스터 전체에서 명령어의 조작과 관련
lsid를 이용하여 특정 lsid 를 식별하는게 쉬워지고 전체 프로세스가 단순해 짐
컨트롤러 프로세스가 연결된 lsid를 5분마다 수집하고 30분 후에 트리거되는 ttl 인덱스를 이용하여 30분간 재사용 되지 않는 session에 대해서는 리소스 정리가 가능
application 은 client session 을 이용하여 server session 을 이용
server session 은 replica set / sharded cluster 에서만 사용 가능
option
type
description
lsid
Document
명령을 실행하는 session 의 고유 ID(GUID-Global Unique ID)를 지정
MongoDB Client에 의해 자동으로 생성
txnNumber 는 lsid 가 반드시 필요
txnNumber
64 bit integer
명령 세션에서 명령을 고유하게 식별하는 양수
lsid 옵션도 함께 필요
cf) RDBMS 는? 단일노드에서 읽기 및 쓰기를 서비스하기 때문에 자연스럽게 Casual Consistency 으로 알려진 읽기 및 쓰기 작업에 대한 순차적 순서 보증을 제공 하지만 분산 시스템은 이러한 보증을 제공할 수 있지만 이렇게 하기 위해서 모든 노드에서 관련 이벤트를 조정하고 정렬해야 특정 작업이 완료 될 수 있는 속도를 제한 필요 Casual Consistency 는 모든 데이터 순서 보증이 유지되는 경우를 이해하는 것이 가장 쉽지만, 시스템이 노드 충돌이나 네트워크 파티션과 같은 장애에 직면할 때에도 시스템이 해야 할 많은 일관성과 내구성 트레이드 오프가 존재
Causal Consistency
v3.6
인과적 일관성이라고 번역
읽기 쓰기 등이 순차적 순서를 보장하는 것을 의미
연산이 앞선 연산에 논리적인 의존성을 가지는 경우(동일한 데이터에 접근), 이 두 연산은 causal relationship을 가졌다고 표현
이때, 클라이언트 어플리케이션에서는 반드시 한번에 한 쓰레드만이 이 연산들을 시도하도록 보장해야만 함
일관성을 보장하기 위한 작업을 의미
Write / Read Concern 이 모두 majority 가 casual consistency 를 보장
참고로 분산 시스템에 대한 일반적인 데이터 개념 (단순 Mongodb만 해당 하는 것이 아님)
주요 memory 일관성 모델 중 하나
공유 메모리에 접근하는 프로그래밍에서 일관성 모델은 어떤 access 가 정확한 순서인지를 제한
분산 공유 메모리 또는 분산 트랜잭션에서 올바른 데이터 구조를 정의하는데 유용
분산시스템이 Scale up/down 만 가능한 DBMS를 모방한 작업 순서를 보장 기능
majority 를 이용하여 읽기, 쓰기에 대한 완전한 일관성을 보장하지만, 사용 사례로 다양하게 사용 가능
Causal Consistency는 read / write 어떤 연산을 수행과 상관없이 동작하는데 이 때 비용이 발생하기에, 단조적 읽기 보장(monotonic read guarantees)이 필요한 곳에만 사용함으로써 causal consistency에 의한 지연을 최소화할 수 있음
read operations reflect the results of write operations that precede them
(읽기 작업은 앞에 있는 쓰기 작업의 결과를 반영합니다.)
Monotonic reads
(단조로운 읽기)
Read operations do not return results that correspond to an earlier state of the data than a preceding read operation.
읽기 작업은 이전 읽기 작업보다 이전 데이터 상태에 해당하는 결과를 반환하지 않습니다.
Monotonic write
(단조로운 쓰기)
Write operations that must precede other writes are executed before those other writes.
다른 쓰기보다 선행되어야 하는 쓰기 작업은 해당 다른 쓰기보다 먼저 실행됩니다.
Writes follow reads
읽기 다음 쓰기
Write operations that must occur after read operations are executed after those read operations.
쓰기 작업은 읽기 작업 후에 발생해야 합니다,
Casual Consistency 가 없는 경우
전제 사항으로 읽기작업은 secondary에서 진행하기 때문에, Primary 에 쓰기 작업 이후 바로 secondary에서 읽을 때 Write가 성공 되었다고 하지만, 복제 보다 먼저 read를 요청하여 write 작업이 반영 안된 현상 발생
단순히 replica set 을 예를 들었지만, Sharded cluster 에서도 동일한 문제가 발생 가능
Casual Consistency 가 없는 경우 해결방법
Lamport logical clock 을 기반으로 하이브리드 logical clock 을 구현
Primary에서 write 되는 이벤트에는 primary 시간이 할당
primary 시간은 모든 구성원 노드가 해당 시간으로 비교 진행
모든 DML(write)에 대해서는 각각의 최신 시간을 할당하고, 해당 시간으로 구성원 노드들이 비교하여 순서를 따져 작업 진행
Write and read concerns
Write Concern / Read Concern 은 Casually consistent 작업 집합 내, 각 작업에 적용할 수 있는 설정
Write concern에는 latency와 durabillity (내구성) 중 하나를 선택
Read Concern 의 경우 isolation level과 연관이 있음(commit 된 snapshot 에 반영된 데이터를 이용)
이러한 작업들은 모두 시스템 장애 시 데이터 보존에 영향(read / write concern)
여러 샤드에서 transaction 일 때, transaction 에서 변경 중인 데이터라고 transaction 외부에서 해당 데이터를 무조건 볼수 없는 것이 아닌, read concern이 local인 경우, 특정 샤드 내 커밋된 데이터는 볼 수 있음 (Transaction 내 A, B 샤드에 걸쳐서 write 가 발생 중인데, 이 때 A는 commit 되고, B에서는 commit 되기 전이라면, A의 commit 된 데이터는 read concern 이 local 상황에서 조회가 가능)
테스트 시나리오
테스트 시나리오
Read Concern majority with Write Concern majority
W1 의 Majority Write 작업이 모두 완료 될 때까지, R1는 기다려야함.
W1의 작업이 완료된 내역을 Read 하기 때문에 R1는 W1 의 결과값을 반환
혹시라도 장애가 발생하더라도, 데이터는 보장받기 때문에 속도가 느린 대신 예기치 않은 장애에도 정상적인 데이터를 반환하기 때문에 금융 어플리케이션 같인 주문 거래 등에서 일관성 / 내구성을 모두 확보하기 때문에 활용 가능
Read Concern majority with Write Concern majority
Read Concern majority with Write Concern 1
W1은 primary에만 성공하면 완료 되기 때문에, w1이 rollaback 되더라도 P1, P2 모두 정상적인 데이터 결과 제공
R1은 Majority이기 때문에 T1-W1 작업이 각 secondary에 전파되어 과반수 commit 될 때까지 기다렸다가 정상적이 데이터 확인
단, p1 같이 primary가 failover 발생 시 , w1는 primary에만 작성하니 성공적으로 끝나지만, Read majority - R1는 과반수로 전파가 되지 않았기 때문에 읽을 수 없음을 의미
장애가 발생할 경우 내구성을 보장하지 않지만, casual 한 순서만 보장
Read Concern majority with Write Concern 1
사용자 기반에 신속하게 서비스를 제공해야 하는 대규모 플랫폼에 고려.(높은 처리량 트래픽을 관리하고 짧은 대기 시간 요청의 이점, 방금 write한 것은 지연 또는 rollback 이 발생할 수 있기 때문에 글 작성한 유저 등은 일시적으로 아래와 같이 회색 처리하여 write 가 끝나지 않음을 간접적으로 제공)
Read Concern local with Write Concern majority
Write Concern majority 이기 때문에 과반수 노드에 저장
Read 가 local 이기 때문에 P1, P2에서 W1의 commit 되지 않은 데이터를 모두 읽기 가능
"read your own writes" 보장이 깨지는 현상 발생
p1, p2에서 여러개의 읽기가 순차적으로 실행 되는 단조로운 경우에도 읽기 순서가 보장되지 않음
장애 발생 시 정상적인 데이터가 인과적 보장이 유지되지 않음
다양한 제품, 서비스에 대한 리뷰가 있는 사이트에서 유용
리뷰를 작성하는 내역에 대해서는 확실한 내구성 보장이 유지되면서, 최신 리뷰 또는 실시간 리뷰를 읽을 경우 write 가 majority라 read를 대기하는 그런 현상이 발생하지 않기 때문에 성능상 이점
단, 승인 되지 않은 롤백되는 리뷰도 읽을 수 있는 경우가 발생
Read Concern local with Write Concern majority
Read Concern local with Write Concern 1
Write Concern 1이기 때문에 내구성이 부족
W1에서 write 후 rollback 하더라도, P2/P1 모두 읽을 수 있음
Casual read 인 R1의 경우도 P1, P2에서 모두 읽을 수 있음
"read your own writes" 보장이 깨지는 현상 발생
p1, p2에서 여러개의 읽기가 순차적으로 실행 되는 단조로운 경우에도 읽기 순서가 보장되지 않음
장애 발생 시 정상적인 데이터가 인과적 보장이 유지되지 않음
스마트 센서 장치 데이터 수집 같은 높은 쓰기 처리량을 유도하는 곳에서 유용
처리량이 높은 워크로드 및 최신성을 선호하는 곳에서 사용
Read Concern local with Write Concern 1
eventual consistency
현재 읽고 있는 데이터가 일관되지 않을 수 있지만 결국 일관성이 유지된다는 의미 (최종 동기화)
적절한 읽기 문제 없이 클러스터 내 다른 구성원이 읽으면 일관성이 보장 되지 않음
Secondary에서 readPreference를 사용하여 읽을 경우인데, Primary에서 write 후에 해당 데이터를 secondary 에서 읽을 경우 복제가 완료되지 않아 잘못된 데이터를 읽을 수 있음을 의미
used_memory_scripts : 5.0 추가 (mh->lua_caches) 생성된 루아 스크립트가 사용하는 메모리 양
모니터링 진행 할 때 used_memory_scripts 를 확인하면 되며, set 명령어만 이루어진 스크립트는 별도로 used_memory_scripts 영역이 변경되지 않음
redis server에서 실행되는 lua script는 원자성(Atomicity)하게 처리된다. (lua가 실행되는 동안 다른 레디스 명령어는 실행 안되는 것을 의미-다른 모든 명령어 차단)
이 부분은 single thread 때문이 아닐까...
스크립트 내용이 동일한 동작!!!을 하더라도, 조금이라도 다르다면 다른 스크립트로 인식 하기 때문에, 의미만 변경되는 스크립트 들에 대해서는 변수 처리로 하여 사용하면 캐싱 절약 효과를 얻을 수 있음
#아래는 동일한 동작을 하지만 내용이 다르기 때문에 서로 다른 내용으로 인식하여 used_memory_lua / used_memory_scripts 값 둘다 변경
eval "return 'hellow world?'" 0
eval "return 'hellow world????'" 0
#아래는 동일한 내용을 호출한 경우 캐싱되어 있기 때문에 memory 변화값이 없음을 확인
eval "return 'hellow world????'" 0
eval "return 'hellow world????'" 0
테스트 1.
이번에는 재밌는 테스트를 진행 하였다. 동일한 redis 구문이지만, return 을 하고 안하고의 차이 이다. 둘다 명령어는 get 명령어로 값을 리턴을 하지만, 이것을 결국 client까지 return을 하느냐 안 하느냐 차이일 것 같은데, 스크립트는 역시 이것을 다른 script로 인식을 하는 것을 확인
당연히 get 명령어이고 lua script를 호출이기 때문에 used_memory_scripts / used_memory_lua 모두 값이 변경 된 것을 확인할 수 있다.
이번에는 명령어는 동일하지만 return 을 하는 명령어 실행
used_memory_scripts / used_memory_lua 모두 값이 변경 된 것을 확인할 수 있다.
당연하겠지만, 기존에 캐싱되어 있는 영역을 다시 조회 시
used_memory_scripts / used_memory_lua 모두 값이 변경 되지 않은 것을 확인
결국은 lua 는 내부 모두 동일해야 동일한 script로 인식하여 캐싱 여부를 사용할지 정하는 척도
데이터 변경이 일어나는 곳이라면 당연히 파라메터로 작성하여 사용 하는 것을 의미하며 이렇게 사용할 것을 권고
테스트 2.
추가로 set 명령어는 lua 엔진을 사용할 뿐, used_memory_scripts 의 값이 변경 되는 내역은 없음
기존 get 명령어나 return 하는 명령어의 경우 used_memory_scripts 값이 변경 되는 것을 확인할 수 있으나, 오로지 set 명령어의 경우 lua engine 의 값만 변경(used_memory_lua ) 되는 것을 확인 할 수 있다.
local src = KEYS[1]
for i=1, src, 2 do
local test_key = 'lua_test_' .. i
redis.call('set', test_key, i)
end;
-> 한마디로 set lua_test_홀수번호 홀수번호
EVAL "local src = KEYS[1] for i=1, src, 2 do local test_key = 'lua_test_' .. i redis.call('set', test_key, i) end;"
lua 엔진은 사용하였지만, get 명령어 같이 조회 하거나 하는 것이 아니기 때문에 lua 메모리 쪽에 적재 되는 것은 없는 것으로 확인
다시 한번 lua 스크립트 실행
동일하게 lua 엔진은 사용하였지만, memory 는 사용 하지 않은 것을 확인
바로 lua 로 실행 하여도 동일하게 engine 은 사용하지만, memory는 변경 되지 않는 것을 확인 완료
결론
동일한 의미로 보이는 Lua 스크립트라고 하더라도, 내용이 조금이라도 다르면 서로 다른 스크립트로 인식
동일한 명령어 이라고 하더라도, return 의 유무에 따라 위의 의미와 같이 서로 다른 스크립트로 인식
set 명령어로만 이루어진 lua 스크립트는, 별도의 메모리를 사용하지 않음 (lua 엔진만 메모리 사용)
그 외 메모리 사용률을 확인 하기 위해서는 used_memory_scripts 를 모니터링 하며, used_memory_lua 는 평소와 비슷한지 체크하면 좋을 듯 합니다.
Elasticache 를 이용한다면, Lua script 내용이 get 형태의 읽기로만 이루어진 내용이라면, read를 이용하는 것을 추천합니다.(Lua의 수행속도가 오래 걸린다면 write 뿐만 아니라 redis 자체가 싱글 스레드로 동작하기 때문에 대기를 하게 되지만, 적어도 read를 이용한다면 write에 대해서만큼은 영향을 덜 미치기 때문 / 하지만 Lua 성능 최적화는 꼭 합시다.)
그외
AWS 의 경우 Cloudwatch 상에서 Elasticache 지표에서는 used_momory_scripts / lua 등을 제공을 하지 않기 때문에 BytesUsedForCache 와 FreeableMemory 의 변화로 모니터링 하는 것으로 우회 하거나, 해당 지표를 직접 조회하여 모니터링 하는 것을 추천 드립니다.
MongoDB 여러 메모리 지표 중 cursor를 발생하는 과정에서 spinlock 이 발생 시키지만 lock 으로는 잡히지 않는 내용을 보고 검색 중 tcmalloc 전체를 정리하는 시간을 가지게 되었습니다.
tcmalloc 이란 ?
구글에서 만든 메모리 할당하는 라이브러리(memory allocation (malloc))
메모리 풀을 사용하면
빠른 메모리 할당
메모리 단편화 감소
Thread Caching malloc (TCmalloc)
메모리를 Thread Local Cache와 Central Heap으로 나누어서 관리
tcmalloc은 성능상의 이유로, 각각 스레드는 자체 로컬(Thread Local Cache) 여유 페이지 캐시와 중앙 여유 페이지(Central Heap) 캐시를 보유
메모리를 신청할 때 Thread Local 여유 페이지 캐시(32k 이하) 에서 사용 가능한 메모리를 찾고==> 사용 가능한 메모리가 없을 때만 Central Heap 페이지캐시(4k page)에서 추가 할당 적용 (Thread Local Cache는 32K이하의 작은 오브젝트 들을 담당하며 메모리가 부족할 시에는 Central Heap에서 메모리를 얻어와서 할당. 그리고 32K가 넘어가는 큰 오브젝트들은 Central Heap에다 4K의 페이지 단위로 나누어서 메모리 맵을 이용하여 할당)
단순 Central Heap은 일반적으로 사용하는 메모리 풀과 다를바가 없지만, Thread Local Cache가 있음으로 불필요한 동기화가 줄어들어 lock cost 가 꽤 많이 감소하여 성능향상 효과
THread 의 수가 늘어날 수록 메모리 단위가 작을 수록 TCMalloc 이 효율이 더 뛰어남
mongos는 메모리 설정 파라메터가 없으며, 전통적으로 많은 사용자들이 mongos는 많은 메모리를 사용하지 않으며 일반적인 경우 100~200MB 정도로 할당해도 충분하다고 알고 있음
MongoDB의 관리형 서비스인 Atlas MongoDB에서도 mongod(MongoDB 서버)와 mongos를 동일 인스턴스에 배포해서 서비스를 제공
mongos를 통해서 아주 큰 데이터를 읽어오는 경우, mongos는 일시적으로 많은 데이터를 버퍼링해야 하며 순간적으로 메모리 사용량이 증가
mongos는 적절한 페이징 사이즈만큼의 도큐먼트를 가져와서 클라이언트가 가져갈 때까지 버퍼링을 하기 때문에 1~2개의 클라이언트가 대량의 데이터를 읽어 간다고 해서 심각한 메모리 사용을 유발하지는 않음
MongoDB에서는 메모리를 해제할 때 메모리도 캐시로 반환되고 tcmalloc Background에서 OS로 천천히 반환
기본적으로 tcmalloc은 최대 메모리(1GB, 1/8 * system_memory)까지 캐시하며, 이 값은 setParameter.tcmallocMaxTotalThreadCacheBytesParameter매개변수가 있지만 일반적으로 수정하지 않는 것이 좋음
WiredTiger cacheSizeGB를 올바르게 구성(약 60%)
Sort 의 경우 메모리 정렬에는 일반적으로 더 많은 Tempory Memory 가 필요
그렇기 때문에 index를 생성할 때 seak - sort - range 순서로 index 생성하는 이유
primary 와 secondary 간의 replication의 간격이 너무 크면 안됨
secondary 가 oplog를 저장하고 가져오기 위해(테일러커서) buffer (default maxsize 256mb) 유지해야하는데, 백그라운드는 buffer에서 oplog를 검색하고 계속 적용해야하기 때문에 secondary의 동기화가 느리면 버퍼가 최대 메모리로 계속 사용하게 됨
colleaction 및 index의 수를 제어하여 메타 데이터의 메모리 오버헤드를 줄여야 함.
replSet:PRIMARY> db.serverStatus().tcmalloc
{
"generic" : {
"current_allocated_bytes" : NumberLong("55188352944"),
"heap_size" : NumberLong("102460903424")
},
"tcmalloc" : {
"pageheap_free_bytes" : NumberLong("11626672128"),
"pageheap_unmapped_bytes" : NumberLong("31339495424"),
"max_total_thread_cache_bytes" : NumberLong(1073741824),
"current_total_thread_cache_bytes" : 207674832,
"total_free_bytes" : NumberLong("4306382928"),
"central_cache_free_bytes" : NumberLong("4098687488"),
"transfer_cache_free_bytes" : 20608,
"thread_cache_free_bytes" : 207674832,
"aggressive_memory_decommit" : 0,
"pageheap_committed_bytes" : NumberLong("71121408000"),
"pageheap_scavenge_count" : 549140549,
"pageheap_commit_count" : 614667087,
"pageheap_total_commit_bytes" : NumberLong("119850820927488"),
"pageheap_decommit_count" : 560377066,
"pageheap_total_decommit_bytes" : NumberLong("119779699519488"),
"pageheap_reserve_count" : 7546,
"pageheap_total_reserve_bytes" : NumberLong("102460903424"),
"spinlock_total_delay_ns" : NumberLong("1232934807643"),
"release_rate" : 1,
"formattedString" : "------------------------------------------------\nMALLOC: 55188353520 (52631.7 MiB) Bytes in use by application\nMALLOC: + 11626672128 (11088.1 MiB) Bytes in page heap freelist\nMALLOC: + 4098687488 ( 3908.8 MiB) Bytes in central cache freelist\nMALLOC: + 20608 ( 0.0 MiB) Bytes in transfer cache freelist\nMALLOC: + 207674256 ( 198.1 MiB) Bytes in thread cache freelists\nMALLOC: + 498335744 ( 475.2 MiB) Bytes in malloc metadata\nMALLOC: ------------\nMALLOC: = 71619743744 (68301.9 MiB) Actual memory used (physical + swap)\nMALLOC: + 31339495424 (29887.7 MiB) Bytes released to OS (aka unmapped)\nMALLOC: ------------\nMALLOC: = 102959239168 (98189.6 MiB) Virtual address space used\nMALLOC:\nMALLOC: 5237759 Spans in use\nMALLOC: 182 Thread heaps in use\nMALLOC: 4096 Tcmalloc page size\n------------------------------------------------\nCall ReleaseFreeMemory() to release freelist memory to the OS (via madvise()).\nBytes released to the OS take up virtual address space but no physical memory.\n"
}
}
replSet:SECONDARY> db.serverStatus().tcmalloc
{
"generic" : {
"current_allocated_bytes" : NumberLong("54850342264"),
"heap_size" : NumberLong("95095918592")
},
"tcmalloc" : {
"pageheap_free_bytes" : NumberLong("23660171264"),
"pageheap_unmapped_bytes" : NumberLong("12539207680"),
"max_total_thread_cache_bytes" : NumberLong(1073741824),
"current_total_thread_cache_bytes" : 247460608,
"total_free_bytes" : NumberLong("4046197384"),
"central_cache_free_bytes" : NumberLong("3798717832"),
"transfer_cache_free_bytes" : 18944,
"thread_cache_free_bytes" : 247460608,
"aggressive_memory_decommit" : 0,
"pageheap_committed_bytes" : NumberLong("82556710912"),
"pageheap_scavenge_count" : 20418440,
"pageheap_commit_count" : 41285079,
"pageheap_total_commit_bytes" : NumberLong("9607290798080"),
"pageheap_decommit_count" : 27551593,
"pageheap_total_decommit_bytes" : NumberLong("9524734087168"),
"pageheap_reserve_count" : 27728,
"pageheap_total_reserve_bytes" : NumberLong("95095918592"),
"spinlock_total_delay_ns" : NumberLong("395391394174"),
"release_rate" : 1,
"formattedString" : "------------------------------------------------\nMALLOC: 54850342840 (52309.4 MiB) Bytes in use by application\nMALLOC: + 23660171264 (22564.1 MiB) Bytes in page heap freelist\nMALLOC: + 3798717832 ( 3622.7 MiB) Bytes in central cache freelist\nMALLOC: + 18944 ( 0.0 MiB) Bytes in transfer cache freelist\nMALLOC: + 247460032 ( 236.0 MiB) Bytes in thread cache freelists\nMALLOC: + 468451328 ( 446.8 MiB) Bytes in malloc metadata\nMALLOC: ------------\nMALLOC: = 83025162240 (79179.0 MiB) Actual memory used (physical + swap)\nMALLOC: + 12539207680 (11958.3 MiB) Bytes released to OS (aka unmapped)\nMALLOC: ------------\nMALLOC: = 95564369920 (91137.3 MiB) Virtual address space used\nMALLOC:\nMALLOC: 5004341 Spans in use\nMALLOC: 181 Thread heaps in use\nMALLOC: 4096 Tcmalloc page size\n------------------------------------------------\nCall ReleaseFreeMemory() to release freelist memory to the OS (via madvise()).\nBytes released to the OS take up virtual address space but no physical memory.\n"
}
}
지표들 내역
pageheap_free_bytes : 페이지 힙에 매핑된 사용 가능한 페이지 byte
해당 영역은 요청 시 할당하여 사용 가능한 페이지
OS에 의해 swap이 발생하지 않는 상태라면, 항상 해당 가상 메모리 사용량으로 계산
total_free_bytes : central_cache_free_bytes + transfer_cache_free_bytes + thread_cache_free_bytes 로 구성
