인프런 커뮤니티 질문&답변
메모리 누수 이슈
작성
·
78
·
수정됨
1
형 질문이 있어!
형 강의 너무 고마워!
배치에서 리모트 파티션 사용중인데
리모트 파티션을 전달에 쓰이는 내부 큐가 있는걸로 알고 있어!
그 큐가 GC 가 안되어 1주일 정도 넘으면 OOM 이 떨어지는거 같아!
혹시 무언가 놓친게 있을까??
설정이나 아니면 필요한 부분이?
답변 부탁해!
답변 3
2
1
Jaess형 하나씩 파헤쳐가보자 💀
매니저쪽에서 문제가 발생한 것인가, 워커쪽에서 문제가 발생한 것인가?
문제가 발생한 컴포넌트의 구성과 코드 등을 알려줄수있나??버전에 따라 이야기가 달라질 수 있다. 사용중인 버전을 알려주면 보다 정확한 판단을 하도록하겠다.
우선 배치5를 기준으로 이야기하자면
StepExecution이 계속 누적된다면 
잡이 돌 때마다 MessageChannelPartitionHandler 빈이 새로 생성되거나
(이게 가능하려면 Master step이 JobScope로 선언되어야하는데 내 기억이 맞다면 최신 버전 기준, Manager Step은 JobScope를 달면 동작하지 않는다) 
그게 아니라면 MessageChannelPartitionHandler의 워커 스텝 결과 취합 과정에 오류가있는것으로보인다
메타데이터 저장소 폴링 방식으로 결과를 취합하는가 아니면 별도 inputChannel을 구성해서 워커로부터 메세지를 전달받는가?
미들웨어는 mq를 사용하는가 아니면 카프카?

미들웨어는 activeMQ 사용중이야!
그리고 xml 설정을 보니 <int:channel> 형식으로 선언 되어있어!
회사에서 적용해서 사용중이라 일단 생각나는 부분은 여기까지고 추가적으로 필요한 부분들은 다음주에 더 취합해볼께! 
신경써줘서 너무 고마워!

xml 설정을 확인해보니
<bean id="pushHandler" class="org.springframework.batch.integration.partition.MessageChannelPartitionHandler">
<int:aggregator ref="pushHandler"
input-channel= "abc"
output-channel = "efg"
send-timeout= "3600000"/>
<int:channel id ="abc"/>
<int:channel id="efg">
    <int:queue/>
</int:channel>이렇게 설정이 되어 있어!
현재 내가 조취를 해봤던 부분
int:aggregator // 석처리 해놓고 돌려보니
heapDump 상에 org.springframework.integration.channel.QueueChannel 객체가 사라진 것까진 확인해봤어
내가 접근한 방법이 맞는걸까??
다른 방향이 있으면 알려줬으면 좋겠어!
확인이 늦었다 Jaess형💀
현재 구성이 메타데이터 저장소 폴링 방식이 아니라 replyChannel로 워커의 결과를 전달받는 방식으로 되어 있는 것으로 보인다.
문제는 이 QueueChannel에서 메시지 소비가 제대로 안 되서 데이터가 계속 쌓이는 것으로 보인다.
확인이 필요한 부분
1. MessageChannelPartitionHandler의 receiveReplies() 메서드가 정상적으로 호출되는가? 
2. 그 내부의 messagingGateway.receive(replyChannel)이 정상적으로 메시지를 읽어가는가?


답변 고마워!
일단 aggregator 를 비활성화 하고 처리하는 걸로 일단락 됐어!
replyChannel설정에 channel 설정으로 되어 있어서 소비 되는 걸로 추측은 되고 있고 xml 설정이라 추가적으로 형이 알려준 메서드가 호출되는지는 파악이 어려운 상황이야!
0
안녕하세요, 인프런 AI 인턴입니다.
Jaess님, 리모트 파티션 사용 중 메모리 누수(OOM) 이슈에 관한 질문을 주셨군요. Spring Batch에서 리모트 파티션 기능은 배치 작업을 분산 처리하기 위해 내부 큐를 사용하기도 하며, 이러한 큐가 올바르게 관리되지 않으면 메모리 누수 문제로 이어질 수 있습니다.
주요점 및 해결책:
- 큐의 크기 및 수명: - 내부 큐의 크기를 적절하게 설정하고, 사용 후에는 큐의 내용물을 명시적으로 클리어하는 것이 중요합니다. 큐에 남아 있는 객체가 많거나 크기가 너무 크면 GC가 이루어지기 어려울 수 있습니다.
 
 
- 내부 큐의 크기를 적절하게 설정하고, 사용 후에는 큐의 내용물을 명시적으로 클리어하는 것이 중요합니다. 큐에 남아 있는 객체가 많거나 크기가 너무 크면 GC가 이루어지기 어려울 수 있습니다.
- 메모리 매니지먼트: - JVM의 메모리 설정을 조정하여 더 많은 힙 메모리를 사용하고 있는지 확인하세요. 또한, 메모리 사용량을 모니터링하면서 System.gc()를 명시적으로 호출할 수 있는 타이밍을 고려해 보세요.
 
 
- JVM의 메모리 설정을 조정하여 더 많은 힙 메모리를 사용하고 있는지 확인하세요. 또한, 메모리 사용량을 모니터링하면서 System.gc()를 명시적으로 호출할 수 있는 타이밍을 고려해 보세요.
- 구조적 개선: - 가능한 한 배치 작업의 데이터를 효율적으로 관리해야 합니다. 데이터베이스와의 연결 관리, 데이터의 스트리밍 방식 등을 최적화하여 메모리 소비를 줄일 수 있는 방법을 고려해 보세요.
 
 
- 가능한 한 배치 작업의 데이터를 효율적으로 관리해야 합니다. 데이터베이스와의 연결 관리, 데이터의 스트리밍 방식 등을 최적화하여 메모리 소비를 줄일 수 있는 방법을 고려해 보세요.
- 프로파일링 도구 사용: - JProfiler나 VisualVM과 같은 프로파일링 도구를 사용하여 메모리 사용 패턴을 분석합시다. 이를 통해 어떠한 객체가 주로 메모리를 점유하고 있는지 확인할 수 있습니다.
 
 
- JProfiler나 VisualVM과 같은 프로파일링 도구를 사용하여 메모리 사용 패턴을 분석합시다. 이를 통해 어떠한 객체가 주로 메모리를 점유하고 있는지 확인할 수 있습니다.
추가 참고자료:
기존 질문으로 비슷한 문제를 다루고 있는 답변을 참고하시면 더 도움이 되실 것 같습니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.






현재 버전이 구버전이라 xml 로 되어있어..
에서 파티션을 한 후에 문제가 되지 않나 추측중이야
heapdump 를 보니 stepExecution 객체가 누적되는 걸로 추측이 되고 있거든!