[Go] 데이터 경합을 감지해보자, Data Race Detector

서론

동시 처리 시스템(Concurrent System)에서 데이터 경합은 매우 흔하고, 디버깅하기 힘든 문제이다.

Go에서는 이런 문제 해결을 돕기 위한 built-in Data Race Detector가 존재한다! (야호🎉)

 

어떻게 쓰나요?

사용방법은 매우 단순하다.

go command에 -race 플래그를 추가하면 된다!

$ go test -race mypkg    // to test the package
$ go run -race mysrc.go  // to run the source file
$ go build -race mycmd   // to build the command
$ go install -race mypkg // to install the package

race build tag로 효율적으로 사용하기

모든 코드와 모든 테스트에 대해 race detector를 사용하는 것이 비효율적일 수 있다.
그럴 때는, race build tag를 사용하면 좋다.

파일 맨 첫번째 라인에 아래와 같이 작성해 활용할 수 있다.

• ` // +build !race` : -race 플래그가 없을 때만 빌드에 포함됨
  • race 검사가 불필요한 코드/테스트
• ` // +build race` : -race 플래그가 있을 때만 빌드에 포함됨
  • race 검사만을 위한 코드/테스트

 

어떻게 알려주나요?

Race Decector가 race를 발견하면, report를 작성해준다.

 

report는 아래의 내용들을 포함한다.

1. 경고 메시지:
2. 읽기 작업을 수행한 goroutine의 스택 트레이스:
   • 함수 호출과 파일/라인 정보 포함
   • 예시:

     net.(*pollServer).AddFD()
     src/net/fd_unix.go:89 +0x398

3. 이전 쓰기 작업을 수행한 goroutine의 스택 트레이스:
   • 함수 호출과 파일/라인 정보 포함
   • 예시:

     net.setWriteDeadline()
     src/net/sockopt_posix.go:135 +0xdf

4. 읽기 작업을 수행한 goroutine의 생성 위치:
   • 함수 호출과 파일/라인 정보 포함
   • 예시:

     net.func·061()
     src/net/timeout_test.go:609 +0x288

5. 쓰기를 수행한 goroutine의 생성 위치:
   • 함수 호출과 파일/라인 정보 포함
   • 예시:

     net.TestProlongTimeout()
     src/net/timeout_test.go:618 +0x298

report 예시

==================
WARNING: DATA RACE
Write at 0x00c000098180 by goroutine 6:
  runtime.mapaccess2_faststr()
      /opt/homebrew/Cellar/go/1.20.2/libexec/src/runtime/map_faststr.go:108 +0x42c
  main.main.func1()
      /Users/bada/Projects/Concurrency-in-Go/main.go:67 +0x48

Previous write at 0x00c000098180 by main goroutine:
  runtime.mapaccess2_faststr()
      /opt/homebrew/Cellar/go/1.20.2/libexec/src/runtime/map_faststr.go:108 +0x42c
  main.main()
      /Users/bada/Projects/Concurrency-in-Go/main.go:70 +0xf4

Goroutine 6 (running) created at:
  main.main()
      /Users/bada/Projects/Concurrency-in-Go/main.go:66 +0xd8
==================
Found 1 data race(s)

 

report를 통해 데이터 경합 문제가 어디에서 어떻게 발생하고 있는지 파악할 수 있다.

다양한 report관련 option들

GORACE 환경변수를 통해 race detector에 옵션들을 설정할 수 있다.

 

사용 가능한 옵션 목록은 아래와 같다.

1. log_path (default : stderr)
   • report 작성 위치
   • stderr, stdout로 설정하면 표준에러, 표준출력으로 작성됨
   • 특정 파일 경로를 입력하면 file_name.pid 형식의 파일에 작성됨
2. exitcode (default : 66)
   • 경합상태 감지 후 프로그램이 종료될 때 사용할 exit status를 설정
3. strip_path_prefix (default : "")
   • report에 포함될 모든 파일 경로에서 생략할 prefix 지정
4. history_size (default : 1)
   • 각 goroutine의 메모리 접근 히스토리는 32K * 2**history_size 로 구성됨
   • 이 값을 증가시키면 스택을 복원하지 못함(failed to restore the stack)에러를 피할 수 있지만, 메모리 사용량이 증가함
5. halt_on_error (default : 0)
   • 첫 번째 race를 탐지하고 바로 종료할것인지, 이어서 계속 탐지할 것인지 설정
   • 0: 종료하지 않음 / 1: 종료함
6. atexit_sleep_ms (default : 1000)
   • 프로그램이 종료되기 전에 main goroutine에서 대기할 시간(ms)을 설정

사용 예시

  GORACE="log_path=/tmp/race/report strip_path_prefix=/my/go/sources/" go test -race

 

Test를 통한 race탐지의 한계와 해결방법

go test -race를 사용하여 race detector를 실행할 경우, 실행중에 발생하는 race만 찾을 수 있다.

(== 실행되지 않는 코드에서 발생하는 레이스는 찾을 수 없음)

 

따라서, test coverage가 충분히 높지 않은 경우에는 ,
-race플래그로 build한 바이너리를 실제와 유사한 환경에서 실행하면 더 많은 race를 탐지할 수 있다.

 

Runtime Overhead

race detector를 사용하면 메모리 사용량과 실행 시간이 크게 증가할 수 있다.
그리고 race detector로 인한 메모리 증가는 runtime.ReadMemStats나 runtime/pprof와 같은 메모리 프로파일링 도구에서는 확인할 수 없기 때문에 주의해서 사용해야 한다.

1. 일반적인 프로그램의 경우 메모리 사용량이 5배 ~ 10배 증가할 수 있고, 실행 시간은 2배 ~ 20배 증가할 수 있음
2. race dector는 defer 및 recover 문마다 추가로 8바이트를 할당
   • defer 및 recover가 많이 사용되는 프로그램은 더 많은 메모리를 사용하게 됨
3. 이러한 추가 메모리 할당은 고루틴이 종료되고 나서 회수됨
   • 고루틴이 오랫동안 실행될 경우 메모리 사용량이 계속 증가할 수 있음
     ==> 장기간 실행되는 고루틴이 주기적으로 defer와 recover 호출을 하는 경우, 프로그램의 메모리 사용량이 무한히 증가할 수 있으므로 주의하자.

 

 

아래 문서를 참고한 포스팅입니다.

https://go.dev/doc/articles/race_detector

Data Race Detector - The Go Programming Language