쿼리 실행 후 TajoWorker의 메모리 점유

[Byungnam Lim]

안녕하세요.

쿼리 실행 후 각 노드의 TajoWorker가 일정량의 메모리를 가지고 반환하지 않는데 이게 무엇인지, 왜 가지고 있는지 모르겠습니다.

32대 노드 클러스터에서 TPC-H 3번 쿼리를 1테라바이트 데이터에 대해 쿼리 수행이 끝난 후에 보면 각 노드에 대략적으로 25 - 35% (4 - 6GB) 정도의 메모리를 TajoWorker가 잡고 있습니다. 

그 이후에 다른 쿼리 수행을 해도 계속 그 정도를 가지고 있는데 점유율이 늘어나진 않습니다.

어떤 목적으로 잡고있는 건가요.

[Jinho Kim]

안녕하세요.

Heap 이라면 JVM old space 일것 같네요. 강제로 GC후 살펴 보시시기 바랍니다.

2015년 12월 22일 화요일 오전 9시 54분 48초 UTC+9, Byungnam Lim 님의 말:

[Byungnam Lim]

좀 예전에 질문했던 글인데, 오늘 이 문제가 다시 이슈가 되서 확인겸 강제 GC를 해봤는데요. 강제 GC후에도 약 5GB정도의 메모리 점유를 계속 하고있는 것으로 확인되었습니다. 

쿼리가 끝나고 나서 몇 시간이 지나도 계속 점유하고 있는 상황을 봐선, 제 생각으로는 쿼리 프로세싱 중에 사용한 오브젝트가 계속 살아있거나, 혹은 쿼리 결과물에 대한 템포럴 스토리지같은건 아닌가 싶습니다.

원인은 잘 모르겠지만, 종료후에도 리소스를 먹고 있는 상황은 개선해야 될 것으로 생각이 됩니다.

임병남 드림.

2016년 1월 11일 월요일 오후 4시 37분 37초 UTC+9, Jinho Kim 님의 말:

[Jinho Kim]

Physical memory 를 말씀하시는것 같은데 아래 메모리 옵션을 공부하시기 바랍니다.

http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

-XX:MinHeapFreeRatio=40 옵션을 수정하시면 원하는 결과를 얻을듯 하지만 너무 낮으면 과도한 gc 가 발생합니다.

2016년 8월 9일 화요일 오후 7시 33분 33초 UTC+9, Byungnam Lim 님의 말:

[Byungnam Lim]

안녕하세요.

말씀해 주신 부분을 적용하고나서 해결이 되는듯 싶었으나 메모리 점유 상황이 계속되고 있습니다. :(

이상하게도 같은 실험을 반복하는데도 어느 순간에는 메모리 점유가 풀렸다가도, 다시 보면 메모리를 잡고 안풀어주고 있을 때도 있네요.

다음은 TPC-H 1번 쿼리를 실행하면서 발견한 점입니다. 

TajoWorker가 메모리를 점유하고 난 이후, 디스크 버퍼 캐시를 drop 하였음에도 불구하고 쿼리 실행 속도가 빨라지는 것을 확인했습니다. 캐시 drop 후에 dstat 명령어로 작동 상황을 모니터링할 때 디스크 읽는 양을 보면 분명 데이터는 디스크에서 읽어오는것으로 보이는데, 읽는 시간은 평균 약 40% 가량 빨라지는 것을 반복확인했습니다. 그런데, 데이터를 TajoWorker가 가지고 있어서 디스크를 덜 읽는다던지 하는 버퍼매니저 기능은 0.11.1 버전의 타조에는 없는걸로 아는데요.

참고로 아래는 force gc 한 이후 top을 사용하여 메모리 점유량 순으로 정렬했을 때 모습입니다.

pid 1476이 TajoWorker입니다. (force gc 한 이전/이후가 메모리 점유량이 같습니다)

총 메모리가 16GB니까 약 8GB 정도를 가지고 놓질 않고있네요. :(

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                    

 1476 hadoop    20   0     10.750g  8.090g   5336 S   0.3   52.0  56:52.25 java                                                                 

30848 hadoop    20   0    1771940 124900    5096 S   0.3   0.8   1:18.17 java                                                                  

 3515 hadoop    20   0     101208   6324    2996 S   0.0   0.0   0:00.04 sshd     

2016년 8월 9일 화요일 오후 8시 32분 34초 UTC+9, Jinho Kim 님의 말: