Gc cr/current block 3-way
EXEM Knowledge Base
목차 |
[편집] Basic Info
gc cr/current block 3-way 이벤트는 gc cr/current request 이벤트에 대한 Fixed-up 이벤트로, 블록을 요청한 프로세스가 마스터 노드가 아닌 제 3의 홀더 노드로부터 블록 이미지를 전송 받았다는 것을 의미한다. gc cr/current block 3-way 대기 이벤트는, 노드 간의 통신 회수가 더 많다는 점을 제외하면 gc cr/current block 2-way 대기 이벤트와 거의 동일한 의미를 지닌다. gc cr/current request 이벤트가 gc cr/current block 3-way 이벤트로 바뀌는(fixed up되는) 흐름은 다음과 같다.
- 요청 노드의 유저 프로세스가 특정 데이터 블록을 읽고자 한다.
- 유저 프로세스는 해당 데이터 블록의 적절한 버전이 로컬 버퍼 캐시에 없는 것을 확인하고, 마스터 노드의 LMS 프로세스에 블록 전송을 요청한다. 유저 프로세스는 응답을 받을 때까지 gc cr/current request 이벤트를 대기한다.
- 마스터 노드의 LMS 프로세스는 GRD를 통해 해당 블록의 최신 버전을 제 3의 홀더 노드가 보유한 것을 확인하고, 블록 전송 요청을 홀더 노드로 전달한다.
- 홀더 노드의 LMS 프로세스는 자신의 로컬 버퍼 캐시에 요청 받은 블록 이미지가 존재하는 것을 확인하고, 인터커넥트를 통해 해당 블록 이미지를 요청 노드로 전송한다. CR 블록을 전송하는 경우에는 gc cr blocks served, gc cr block build time, gc cr block flush time, gc cr block send time 통계 값이 증가한다. Current 블록을 전송하는 경우에는 gc current blocks served, gc current block pin time, gc cr block flush time, gc cr block send time 통계 값이 증가한다.
- 유저 프로세스는 블록 이미지를 전송 받고, gc cr/current request 이벤트를 Fixed-up 이벤트인 gc cr block 3-way 이벤트나 gc current block 3-way 이벤트로 변경한다. CR 블록을 전송 받은 경우에는 gc cr blocks received, gc cr block receive time 통계 값이 증가한다. Current 블록을 전송 받은 경우에는 gc current blocks received, gc current block receive time 통계 값이 증가한다.
위의 흐름을 통해 예상할 수 있듯이, gc cr/current block 3-way 대기 이벤트는 세 개 이상의 노드로 이루어진 클러스터에서만 발생한다. 또한 클러스터를 구성하는 노드의 수와 무관하게 노드 간의 통신은 3-way가 최대(요청 노드:마스터 노드:홀더 노드)이기 때문에, gc cr/current block 4-way와 같은 이벤트는 존재하지 않는다. gc cr/current block 3-way 이벤트에 대한 대기 현상을 해소하는 기법은 gc current request 이벤트와 동일하다.
[편집] Parameter & Wait Time
[편집] Wait Parameters
gc cr block 3-way 이벤트와 같은 Fixed-up 이벤트는 P1, P2, P3 값이 별도로 부여되지 않으며, Placeholder 이벤트(여기서는 gc cr request 이벤트)와 동일한 값을 가지는 것으로 해석하면 된다.
[편집] Wait Time
[편집] Check Point & Solution
gc cr/current request#Check Point & Solution을 참조한다.