OOM 장애 난 것 성능 개선 블로그 써봤는데 이런식으로 괜찮을까요?

Question

저번에 프리티어 인스턴스에서 OOM에러가 나서 원인분석 해보았습니다.첫 모니터링 후 측정한 후 개선한 것을 블로그에 써봤는데로컬 환경에서 인스턴스와 똑같은 환경 만들어놓고성능테스트하면서 원인 찾고 해결하는 식으로 했는데글 한번 읽어보고 가독성이나 타당성 측면에서 괜찮은지 확인해 주시면 감사하겠습니다.요약하자면기존 : 메모리에 필요한 엔티티 전부를 읽어 와 자바 컬렉션으로 그룹핑, 집계, 정렬, 페이징까지 처리하는 방식개선 : 모든 데이터 가공 작업을 DB가 직접 처리하도록 전면 수정+) 이번에 알게됐는데 subList()가 Memory Leak 위험이 있더군요부모 List를 계속 해서 붙잡고 있는 성질이 있어서 GC가 자동으로 해제 못한다는 것을 알았네요ㅎㅎ+) 블로그 링크가 누락됐었네요 ㅎㅎ..: https://changha-dev.tistory.com/194

개나소나고생 · Answer

역할을 DB서버에 넘기는 상황인데..결국 그렇게 되더라도 DB서버에 부하가 발생하는건 똑같은거 아닌가요?DB서버 부하발생이 더 큰듯 싶은데요.

RWB · Answer

쉽게 말해서 원래는 전체 데이터 SELECT -> 자바 메모리 단계에서 조건 따라 데이터 가공 방식이였다면,후자는 쿼리를 통해 자바단에서의 데이터 정제를 최소화하고 DB 단계에서 뽑는다는 말씀이신거죠?쿼리로 가능한 데이터 정제는 쿼리로 수행하는 것이 퍼포먼스에서 훨씬 이득입니다. 이는 데이터의 양이 많으면 많을수록 그렇습니다.1000줄짜리 쿼리같은 괴상한 쿼리가 나오고 사용되는 이유이기도 하죠. 때문에 쿼리 상에서 문제가 생기면, 쿼리 튜닝을 통해 다른 방안을 찾는 경우가 대부분입니다.(쿼리에서도 부하가 발생하는 데이터는 웹서버 상에선 훨씬 부하가 큼)모든게 그렇듯 언제나 우위는 아니구요. 아예 컨텍스트가 달라서 코드적으로 구성하는 것이 복잡한 쿼리보다 유지보수성, 가독성 측면에서 나을 경우가 있습니다.즉, 쿼리로 하면 엄청나게 복잡해지고 난해하지만, 그냥 서버 단에서 간단한 연산으로 끝나는 경우가 진짜 간혹 나오는데, 이 땐 그냥 서버단에서 하시는 게 낫습니다. (하다보면 감이 와요)GC의 경우 자동으로 메모리를 관리해준다는 이점이 있지만, 개발자가 직접 명시하긴 어렵습니다.(C++은 일일히 직접 해주어야만함)때문에 그런 문제를 관측했다면, 연산 후에 필요 없어진 데이터는 깔끔하게 null을 할당하여 메모리 사용량을 줄일 수 있습니다.add) 본문 보면 링크가 첨부되어야 할 것 같은데, 누락된 것 같네요

집킨 · Answer

subList를 어떤식으로 쓰신건지는 모르겠는데 API응답이 끝나면 GC대상이 되는게 맞습니다

zoony · Answer

특정한 api이고 원인찾기도 쉬웠던거 같아서 살짝 설득력이 떨어질수도 있을거 같습니다.문제상황 후 성능 테스트 한다음에 문제를 찾았는데 문서상으론 Out of memory의 원인을 글로만 알수 있을뿐찾는 과정이 구체적이지 않습니다.제 3자인 제가 보기엔 답을 이미 알고 있는 상황에서 역으로 문제원인을 적은것처럼 보여집니다.설득력을 얻으려면 특정 객체가 메모리를 많이 잡아먹게 된 4가지 원인을 수치로 보여주던지부하테스트를 통해 나온 결과로 보여줘야 보는 입장에서 열심히 했구나 하는 생각이 들거 같습니다.정상일때의 숫자로된 수치와 문제가 생겼을때의 특정객체를 확실하게 볼수 있는 증거물과 숫자로된 수치예를 들면 부하가 피크치에 찍었을때 메모리를 분석하는 내용이 좀더 자세히 들어가면 더 좋은 문서가 될거 같습니다.그리고 위에 분들도 말씀해 주셨지만 결국 나중에 DB에도 데이터가 엄청 쌓이면 추가적으로 문제가 생길수도 있을거 같기도 한데요.현재처럼 서버의 부담을 DB로 이동시켜서 해결한거 + DB의 부담이 점점 커졌을때 해결책이나 이것에 대한 대응책을 추가로 적는것도 좋아보입니다.

OOM 장애 난 것 성능 개선 블로그 써봤는데 이런식으로 괜찮을까요?

4개의 답변

기술 목록