modelmapper memory leak

최근 추가한 코드를 테스트하는 개발서버에서 아래의 에러 메시지가 발생했다.

java.lang.OutOfMemoryError: Direct buffer memory
        at java.nio.Bits.reserveMemory(Bits.java:694)
        at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
        at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
        at io.netty.buffer.UnpooledUnsafeDirectByteBuf.allocateDirect(UnpooledUnsafeDirectByteBuf.java:111)
        at io.netty.buffer.UnpooledUnsafeDirectByteBuf.(UnpooledUnsafeDirectByteBuf.java:68)
        at io.netty.buffer.UnsafeByteBufUtil.newUnsafeDirectByteBuf(UnsafeByteBufUtil.java:626)
        at io.netty.buffer.UnpooledByteBufAllocator.newDirectBuffer(UnpooledByteBufAllocator.java:65)
        at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179)
        at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:170)
        at io.netty.buffer.AbstractByteBufAllocator.ioBuffer(AbstractByteBufAllocator.java:131)
        at io.netty.channel.DefaultMaxMessagesRecvByteBufAllocator$MaxMessageHandle.allocate(DefaultMaxMessagesRecvByteBufAllocator.java:73)
        at io.netty.channel.socket.nio.NioDatagramChannel.doReadMessages(NioDatagramChannel.java:243)
        at io.netty.channel.nio.AbstractNioMessageChannel$NioMessageUnsafe.read(AbstractNioMessageChannel.java:75)
        at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:642)
        at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:565)
        at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:479)
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:441)
        at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
        at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
        at java.lang.Thread.run(Thread.java:748)

추가한 부분은 udp 클라이언트 용도의 프로그램이었다. 

소스를 분석해 봤지만 문제되는 부분을 알 수 없었다.

visulavm을 이용해 모니터링을 해봤더니, classes의 Total loaded 개수가 계속 증가하면서, Metaspace 영역이 계속 증가하는 현상을 확인했다.

dump를 받아서 mat 프로그램으로 분석했다. 잘 사용할 줄은 몰랐지만 대충 보다 보니 modelmapper가 보인다. 뭐지...

'modelmapper 성능 이슈'로 검색해 봤더니, 이런 글을 찾았다. 

설마 하는 생각으로 modelmapper 부분을 제외했더니, 정상적으로 돌아왔다.

modelmapper는 예전부터 web 프로젝트에서 많이 사용했었기 때문에 이런 문제가 발생할 줄 몰랐다.

'modelmapper memory leak'으로 검색해서 더 알게 된 정보는 modelmapper는싱글톤으로 구성하여 사용하라는 것이다.

modelmapper를 많이 사용하지 않았기 때문에 전부 걷어내고 직접 지정하는 방식으로 변경했다.

이런 문제가 한 번 생기고 나니 modelmapper를 다시 사용하기 꺼려진다.

modelmapper memory leak으로 찾아 본 글

https://www.programmersought.com/article/1444628366/
https://better-dev.netlify.app/java/2020/10/26/compare_objectmapper/
http://modelmapper.org/user-manual/faq/
https://github.com/modelmapper/modelmapper/issues/375

오라클 접속이 되다 안되다 하는 현상.

스프링 기반으로 만든 소스에서 오라클 접속이 로컬에서 개발 할 때는 잘 되었다. 

문제는 개발서버에서는 연결 자체가 안됐다. 아예 안 되는 건 아니고, 가끔 연결이 될 때도 있었다. 

오류메시지가 연결되지 않은 것에 대한 메시지만 나오니 이 에러메시지로는 해결책을 찾기가 어려웠다.

이것저것 여러가지를 적용해 봤지만, 해결이 안 됬다. 다음날 다시 검색 시작. 해결법을 찾았다.

해결법은 이거였다.

-Djava.security.egd=file:/dev/./urandom

리눅스에서 오라클 jdbc 드라이버는 기본적으로 random 을 사용하는 데, random은 서버의 엔트로피를 사용하여 random 값을 생성한다고 한다. 여기서 엔트로피란 서버의 노이즈라고 한다.

노이즈는 서버의 디스크 읽기, 키보드 입력, 네트워크 패킷등이라고 한다.

random은 이런 엔트로피가 일정조건까지 채워져야 값을 생성해 준다고 한다. 이 기다림이 문제 였다. 반면 urandom 일정조건을 채우지 않고도 바로 값을 준다고 한다.

잘 이해가 안 가서 검색을 하니, 잘 정리된 블로그가 있었다.

역시 검색을 하려고 해도 뭘 알아야 검색을 할 수 있다.

결국 옵션 하나로 해결한 문제였지만 문제의 원인을 알 수 없을 때는 꽤 골치 아픈 문제였다.

ORA-12528, TNS:listener: all appropriate instances are blocking new connections.

 1. 오라클 접속 하려고 했더니 아래와 같은 에러 발생.

oracle.net.ns.NetException: Listener refused the connection with the following error:

ORA-12528, TNS:listener: all appropriate instances are blocking new connections.

2. 오라클 서버에 접속해서 리스너 상태 확인.

lsnrctl stat

상태가 BLOCKED로 나옴.

Instance "orcl", status BLOCKED, has 1 handler(s) for this service...

3. sqlplus 접속해서 오라클 재시작. ORA-00205 에러가 난다.

SQL> shutdown abort;

ORACLE instance shut down.

SQL> startup;

ORACLE instance started.

...

Total System Global Area 1.0133E+10 bytes

Fixed Size     3721272 bytes

Variable Size 1778386888 bytes

Database Buffers 8321499136 bytes

Redo Buffers    29831168 bytes

ORA-00205: error in identifying control file, check alert log for more info

...

4. alert log 확인. alert log의 기본위치는 아래와 같다.

10g 이하는 $ORACLE_BASE/admin/$ORACLE_SID/bdump

11g부터는 $ORACLE_BASE/diag/rdbms/'DATABASE NAME'/$ORACLE_SID/trace

아래와 같은 에러 확인.

Wed Oct 21 17:55:04 2020

starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...

starting up 1 shared server(s) ...

ORACLE_BASE from environment = /home/oracle/app

Wed Oct 21 17:55:04 2020

ALTER DATABASE   MOUNT

Wed Oct 21 17:55:04 2020

ORA-00210 : cannot open the specified control file 

ORA-00202: control file: '/oradata/oradata/mydatabase/control01.ctl'

ORA-27086: unable to lock file - already in use

Linux-x86_64 Error: 11: Resource temporarily unavailable

Additional information: 8

ORA-205 signalled during: ALTER DATABASE   MOUNT...

Wed Oct 21 17:55:07 2020

Using default pga_aggregate_limit of 6440 MB

5.

/oradata 위치는 nfs로 연결된 스토리지이다. 

/oradata/oradata/로 이동해서 파일 권한, 소유자 확인 했지만, 이상없음.

파일생성, 삭제, 수정 해봤지만, 정상임.

6.

에러 원인 확인 불가. 해결법은 찾음.

해결법은 에러가 나는 control01.ctl 파일이름을 변경 후 다시 원래 이름으로 복사.

오라클 중지 후 작업한다.

mv control01.ctl control01.ctl.bak

cp control01.ctl.bak control01.ctl

오라클 시작.

control01.ctl의 에러는 사라졌지만, /oradata 위치의 몇몇 파일들이 같은 문제를 일으킴. 역시 위와 같은 방식으로 다시 처리.

정상화 완료.

파일 디스크립터가 어떤 이유로 스토리지에서 열린 상태로 유지되어 발생하는 오류로 보인다. 아마도 네트워크에 뭔가 문제가 생겼을 때, 그냥 끊어져 버린게 아닌가 싶다.

버팀목전세자금 대출, 목적물 변경 및 증액 상담 내용.

 최근 직장을 옮기고, 직장 근처로 이사를 위해 집을 알아 보고 있다. 전세로 가기 위해 준비하고 있으나, 내 예산안에 맞는 집을 찾기가 어렵다. 검색해 보다, 기존 전세대출을 목적물 변경과 증액을 이용하는 방법을 찾았다.

목적물 변경은 이사를 하게 되는 집을 바꾼다고 보면 되고, 증액은 기존 대출금에서 더 대출을 요청한다고 볼 수 있다.

인터넷으로는 알아보는 정보에 한계가 있고, 제대로된 정보를 얻기 위해 실제 은행에서 대출상담을 받았다.

내가 알아본 은행은 우리은행이다. 기존에 우리은행을 통해서 버팀목전세자금 대출을 받고 있었다.

대출 상담 내용을 요약하면 이렇다.

1. 1금융권은 재직 3개월이상만 대출이 가능하다고 한다.

2. 대출 증액은 계좌가 새로 생성되는 개념으로 버팀목전세자금 대출의 자격요건을 다시 본다. 증액을 받을 시 자격요건이 맞지 않으면 대출이 안된다.

3. 목적물 변경은 기존 계좌를 사용하는 개념으로 자격요건을 다시 보지 않는다.

4. 대출금을 갚으면 갚은 한도 만큼만 목적물 변경시 다시 대출이 가능하다. 예를 들어 처음 버팀목전세자금 대출을 받을 때, 1억을 대출 받고 도중에 6천을 갚으면, 목적물 변경시 적용되는 대출금은 4천이다. 나가는 이자를 조금이라도 줄이기 위해 대출금을 중간에 조금 갚은 게 오히려 독이 됐다.

결국은 기존에 살던 집의 전세를 넘는 집으로는 가기 어려울 것 같다.

목적물 변경만을 위해 필요한 준비물 및 순서는 다음과 같다.

1. 이사 이후에 전입신고를 한다.

2. 주민등록등본과 확정일자를 받은 임대차 계약서, 등기부 등본을 가지고 은행을 방문하여 신청한다.

3. 처음 대출을 받은 지점과 다른 지점인 경우 필요서류를 해당 지점으로 보내서 처리한다고 한다.

ps . 완료 시점에 가족관계증명서를 제출 요청함. 등기부 등본 제출할 때 같이 제출하면 좋을 듯 하다.

Elasticsearch SQL parsing_exception

 엘라스틱서치에서 sql로 쿼리 실행시 특수문자가 들어간 경우 parsing_exception 에러가 난다.

이럴 때는 \" 를 사용하면된다.

ex>

{
    "query" : "select * from \"my.data.day.20200925\""
}

사이드 프로젝트는 성취감입니다.

 최근에 이동식 에어컨을 팔았다. 올리자마자 여기저기서 연락이 온다. 대충 비슷하게 시세 알아보고 올리는 데도 항상 너무 싸게 올리는 것 같다. 내가 생각하는 가격에 조금 더 비싸게 올려놓고, 안 팔리면 조금씩 가격을 내려야 하는데, 자꾸 잊어먹는다. 나는 장사 체질이 아닌가 보다. 

파이썬을 배운 김에 뭔가 하나를 만들어 보자는 생각에 중고가격을 한눈에 알아보는 사이트를 만들었다. 중고가격을 책정하는 데에 도움이 되는 사이트가 있으면 좋을 것 같았다. 찾아보니 비슷한 사이트가 없었다. 

중고 가격은 네이버 카페 중고나라에서 가져왔다. 처음에는 크롤링을 하려고 했으나, 네이버 카페 글 검색 api가 있었다. 내가 딱 원하는 api는 아니지만, 가공하면 쓸만한 정보를 얻을 수 있었다. 다 만들고 나니 꽤 그럴듯했다. 그래서 이왕 하는 김에 공부도 할 겸 Vuejs로 프론트도 만들었다. 프론트도 다 만들고 나니 아예 오픈하는 것도 나쁘지 않은 것 같았다. 그래서 도메인도 사서 연결했다. 서버는 AWS 1년 free 서버를 사용했다.

그래서 완성한 사이트가 바로 www.findusedprice.com 다. 많은 애용바란다.  

도메인 만료. 사이트 중단...

사이트를 열고 보니 크롬에서 안전하지 않은 사이트로 뜨는 게 마음에 걸린다.  ‎Let's Encrypt를 이용해서 SSL까지 적용했다.

이것저것 검색해 보니 가격이 완벽하지가 않다. IX940 같은 모델명으로 검색하면 정확한 데이터가 나오지만, 광범위한 검색은 제대로 된 가격을 얻기가 힘들다. 제외 키워드를 넣어서 그나마 조금 더 괜찮은 데이터가 나오도록 했다.

도메인은 3년짜리를 사면 할인을 해 주는데, 3년까지 저 서비스가 남아있을 것 같지가 않다. 일단 1년으로 했다. 구글 애널리틱스를 붙였다. 도메인 만료 전까지 사용자가 어느 정도 있으면 연장을 하고 거의 없으면 그대로 사장 시킬 예정이다.

최근에 취업하게 되어 출퇴근하고 있다. 출퇴근한다는 거 자체가 별거 아닌 거 같지만 꽤 힘들다. 정시 퇴근을 하고 집에 와도, 씻고 밥 먹고 조금 TV보고 하면 금방 잘 시간이다. 밥 먹으면서 졸기도 한다. 그 잠깐 시간하고 주말에 시간을 내서 완성하고 보니, 뿌듯함이 생긴다. 이래서 작은 일이라도 끝내는 일이 중요하다고 하나 보다.

변기 배관 막힘

 변기가 막혔다. 음식물 쓰레기를 잘못 버린 게 문제였다. 혼자 사는 지인의 집에 갔을 때, 음식물 쓰레기를 변기로 처리하길래 좋은 방법이라고 생각했다. 멍청한 생각이었다.

나흘 동안 변기를 뚫기 위해 온갖 방법을 다 동원했다. 그간의 노력을 기록으로 남긴다.

1. 페트병

예전에 한 번 뚫었던 적이 있어서 시도했으나, 이번에는 잘 안 됐다. 막힘의 정도가 달랐다.

2. 뚫어펑

다이소에서 샀다. 1,000원이다. 안된다. 뚫어뻥은 고무가 얇은 게 잘 뒤집어지지 않아 좋다고 한다. 다이소에서는 한 가지밖에 없었다.

2. 뚫어펑 액체

액체를 붓고 30분 정도 지나 물을 내려 확인했으나 그대로였다. 자기 전 부어 넣고, 아침에 확인했으나 역시 그대로였다.

0.5L를 넣으라는 걸 1L로 넣은 거였는 데도 그렇다.

3. 철사 옷걸이

절대 안 된다. 이걸로 된다는 사람들은 도대체 어떻게 했다는 건지 모르겠다.

4. 세제와 뜨거운 물

역시 안된다.

5. 미스터 펑

거금 5만 원을 주고 샀다. 이전 버전이 3만 6천 원 정도인데, 나중을 위해 올인원이라는 신형을 샀다. 택배를 받은 후 기쁜 마음으로 도전했다.

참패다. CO2가 2박스가 같이 오는데, 한 박스에 10개가 들어 있다. 11개를 썼지만, 안됐다. 댓글 간증을 너무 믿었다.

구멍을 막는 고무가 작다. 물이 튄다. 한 박스를 다 써도 안되니 더는 시도해 볼 용기가 나지 않는다. 한 박스면 6천 원이다.

중고나라 행 결정이다.

6. 관통기

나의 구세주. 철물점에서 9천 원에 샀다. 온라인에서는 5천 원 정도다. 배송비 생각하면 비슷한 가격이다. 관통기 역시 처음에는 안됐다. 땀을 삐질삐질 흘리며 힘써 봤지만, 안됐다.

거의 자포자기였다. 업체에 예약을 하고 혹시나 하는 마음으로 다시 시도했다. 됐다. 물이 내려가는 게 믿기지 않았다.

다시 한번 확인했다. 물이 잘 내려간다. 이때의 카타르시스는 뚫어 본 사람만 안다. 모든 방법을 다 동원하고 자포자기하고 있을 때 뚫리는 순간의 기쁨을 모를 것이다.

변기 막힘으로 인한 검색으로 참 많은 걸 알게 되었다. 대표적인 게 비데용 물티슈라는 거다. 물에 분해 되는 성분으로 만들었다고 한다. 이게 다 마케팅이다. 내가 쓰고 있는 물티슈 역시 물에 녹는 재질이라고 했다.

실험해 봤다. 컵에 수돗물을 받고 물티슈를 넣고 1시간을 기다렸다. 티슈는 전혀 분해 되지 않았다. 믿을 게 하나도 없다.

얼마나 많은 사람이 변기에 음식물 쓰레기를 버리는지 알게 됐다. 음식물 쓰레기는 쉽게 분해 되지 않기 때문에 배관이 막히는 원인이 된다. 변기에는 변과 휴지만 넣기로 다짐했다.