database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
ㆍPostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
PostgreSQL Q&A 10289 게시물 읽기
No. 10289
프로시저 wait로 인한 서비스 지연 발생 시 어떤문제를 의심할 수 있을까요?(replication 구성)
작성자
우재권(wjk0726)
작성일
2021-10-22 22:42ⓒ
2021-10-22 23:00ⓜ
조회수
488

먼저 내용이.좀 기네요...ㅠ 양해부탁드립니다...


DB는 postgres9.6버전을 사용하고 Replication 구성(streaming)으로 master-slave1-slave2 로 구성되어있습니다


두번의 서비스지연이 발생했는데 


첫번째는 지연 발생 후 master서버 모니터링 시  특정 프로시저에서 long이 잡히고 wait에 빠지는 현상이 있었습니다 ( 특정 프로시저의 경우 평균 30초내에 수행이완료되는 프로시저이나 지연발생당시 십수분이.지나도 처리되지 않고 wait에 빠지고 있었습니다. ) Slave서버들은 특이사항 없었음

해서 결국엔 master서버에 wait걸린 세션들은 모두 킬하여 해소하였습니다


***문제는 두번째 입니다. 서비스지연이 길어져 장애발생으로 이어진날인데

시작은 첫번째와 동일하게 서비스지연이 있다고 연락을 받았습니다


다만 약간 다른점은 이때는 서비스지연 연락을 받음과 동시에 slave1서버에서 알람이 발생했다고 전달받은 상태였습니다


이후 처음에 master서버를 확인했을 당시 첫번째 지연이 발생했던 날과 동일하게 특정 동일 프로시저수행세션이 처리되지 않고 wait에 빠져있었습니다

그래서 해당 세션들을 마찬가지로 정리를 했으나 서비스 지연은 계속 발생했었고 


다음으로 slave서버를 확인하자 아주 많은 세션들이 wait에 걸려있었습니다


급한 상황이라 먼저 ap에 이야기 후 wait 세션들을 모두 정리한 후에야 지연해소가 되었습니다

--------‐------------------------------------------------------------------

얘기가.길어졌는데 

***여기서 궁금한 것이 첫번째 지연당시와 달리 두번째 장애발생때는

Slave1 서버에 다수 wait이 걸리게 되었는지(master서버에서 특정프로시저를 수행하는 wait이 걸린 세션을 킬한것과 관련이 있는지..???.)


지연발생 당시 slave1서버 모니터링 시 가장 오래돌고 있는 세션이

idle in transaction에 걸려있는 상태인데 일반계정으로 postgres 내부카탈로그정보( pg_proc 프로시저관련 테이블) 를 조회하고 있었고


그 뒤에 들어오는 세션들이 모두 wait에 걸리게 되었습니다


세션들은 서비스에서 사용되는 세션도 일부 있었고 

세션이 끊어지지 않게하기 위한 show isolation level 세션들도 있었습니다...


****그런데 왜 Wait에 걸리게 된건지 이유가 궁금하네요

master서버에서 프로시저 킬수행한것과 관련이 있다면 첫번째 날에도 동일한 현상이 발생했을텐데 첫번째 날에는 slave서버는 특이사항이 없었습니다...


***** 그리고 slave서버에서 일반계정으로 pg_proc이 조회됐던것이 직접수행하지 않고 가능한 것인지요? ( 프로시저를 수행하는 세션이 wait에 빠지게 돼서 자동으로 내부 카탈로그 정보를 일반계정이 조회하는지....??? )


***마지막으로 건들면 안되는 테이블(pg_proc)을 일반유저가 조회해서  그 이후에 들어온 세션들이 모두 wait에 걸리게 된 것인지 궁금합니다..

이 글에 대한 댓글이 총 2건 있습니다.

PostgreSQL의 잠금 규칙을 이해할 필요가 있어요. 


첫째 세션이 select를 하고 

두번째 세션이 alter 작업을 하면,  첫번째 세션 작업이 마무리 되기 전까지는 alter 작업이 대기 상태가 되겠죠. 

이 상황에서 

세번째, 네번째 세션이 모두 select 작업을 한다고 해도, 두번째 작업의 예약된 테이블 잠금 때문에, 이들은 모두 대기 상태가 됩니다. 

이런 방식으로 잠금 처리를 합니다. 


문제는 첫번째 세션이 select 작업을 하고 idle in transaction 상태로 아무 작업도 하고 있지 않게 된다면, 

이 세션의 트랜잭션이 정리 되기 전까지는 두번째 세션은 영원히 기다리게 됩니다.

아주 위험한 상황입니다. 

그래서, idle in transaction 세션 관리가 필수입니다. 

응용프로그램 부서와 상의해서, 

'해당 서비스는 idle in transaction 상태가 1분 이상 있을 수 없다!' 이런 서비스 특성이 확인된다면, 

idle_in_transaction_session_timeout 환경 설정 값을 지정해서 이 문제를 피할 수는 있어요. 

하지만, 대부분의 서비스 환경이 그렇지 못하다보니, 

결국 운영 초기에는 이 idle in transaction 상황을 잘 파악해서, 

이런 세션을 정리하는 가장 최적의 방안을 찾아야합니다. 


워낙 다양한 경우가 있어, 딱 이렇게 하세요.라고 말하기는 힘듭니다. 

 

김상기(ioseph)님이 2021-10-25 09:58에 작성한 댓글입니다.

네 답변 감사드립니다^^

우재권(wjk0726)님이 2021-10-25 20:22에 작성한 댓글입니다.
[Top]
No.
제목
작성자
작성일
조회
10293백업 내역 확인을 할 수 있나요? [3]
초보
2021-10-26
473
10292pg_stat_tmp 파일 질문 [1]
카비
2021-10-26
453
10290postgresql 병렬처리 (dbeaver, pgadmin) [2]
궁금
2021-10-25
480
10289프로시저 wait로 인한 서비스 지연 발생 시 어떤문제를 의심할 수 있을까요?(replication 구성) [2]
우재권
2021-10-22
488
10288pg_partman 쓰고있는데 파티션 테이블이 왜 자동생성이 안될까요 ㅜㅠ?
끝판왕
2021-10-22
475
10287xpath 오류 질문입니다. [1]
xpath
2021-10-20
485
10286replication 방식에 대해 질문드립니다 [2]
cella
2021-10-16
626
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2021 DSN, All rights reserved.
작업시간: 0.038초, 이곳 서비스는
	PostgreSQL v13.3으로 자료를 관리합니다