잡담 IT

각 회사마다의 분위기가 상당히 틀린것 같다.

SI회사와 포털의 분위기는 완전히 천차 만별이고.

포털마다의 분위기도 상당히 차이가 있는거 같은.

그건 그렇고. 경력과 신입의 차이가 상당한것 같다.

신입모집은 거의 한 50%는 자회사 광고 부분이 들어가서 이벤트성이 상당한데.

경력은 완전 딴판이구나.

sms 를 보내는 배치프로그램의 속도 문제가 발생하여, 땜방하러 갔다.

sms 를 보내는 서버가 sql로 되어있고, 해당 서버에 인서트가 되면 sms가 발송된다.

대략 2000껀 보내는데. 한 40분 걸리더라. -_-a..

어떻게 사용했는지 나름 대단하다는.

찾아본 결과 sqlserver로 인서트후 번호를 따오는 select 문에서 1건당 2초씩 걸리는 걸 파악

sql server로 플랜 떠보니 빨른걸 우째. 그냥 쿼리 날려도 빠르고 거참.

오라클도 플랜이 계산이 잘못되서 느린거니 뭐 그러려니 하고 진행. 실제로 트레이스 떠 보면 나오지만. 

sql server는 트래스 같은걸 몰라서 그냥 sql을 고치기로 결정

인서트시 증가하는 시퀀스를 따오는 부분이 느린데 아무리 고쳐도 안되길래.
sqlserver 관련 함수를 찾아보니 번호따오는 함수가 있길래 사용했더니 한방에 해결.. 이런 황당한. -> ident_current (해당함수사용)

해당 함수를 사용하니. 대략 0005ms대로 줄어서 일단 해당 부분은 해결.
sql server는 실제 돌아가는건 어떻게 추적해야 될지.


근데 이상하게 60건씩 10초후에 또 60건씩 가는 현상이 발생,
 
상황파악해보니 예약시간에 도는 배치도 느린문제가 발생. 이런 이론 -_-a....

이건도 update 문이 느려서 오라클 플랜 떠보니 스킵스캔으로 인덱스를 타서 느리더라.

where 조건중 효율좋은 컬럼에 인덱스 걸어서 해결.

나름 잡기 힘들었던 문제 정리

케이스 1
1+N 쿼리 문제.
책으로는 많이 본 케이스이나 실질적으로 당했을때 어떤 결과가 나오는지 알수 없었음.
대략적인 증상 : 부모와 자식이 있다고 치고.
부모의 조회껀이 1만껀이고 자식이 만껀의 sql을 날린다고 가정했을때.
sql 조회에 따라 다르겠지만. 부모 테이블의 특정키를 사용해서 조인해서 테이터를 보여줄경우, 부모테이블의 레치가 심하게 걸림.
락과 비슷한 현상이 발생하고, 경우에 따라서 공통되는 키에 대한 트랜잭션이 지연되는 현상이 나타난다.

해결법 : 1+N쿼리를 한방 sql로 수정하면 해결이 가능하다.

케이스 2
채번시 문제
이것도 책에서는 많이 봤던 문제 인데. 역시 실제로 당하면 파악이 쉽지 않다.
채번테이블 사용시 select for update 구문 사용으로 테이블의 락을 걸로 번호를 딴후에 완전한 트랜잭션 진행후, 커밋로짓.
트랜잭션이 길 경우 채번 테이블을 액세스 하는 모든 트랜잭션이 지연된다.

해결방법 : 업무에 따라 다르다.
1. 번호가 연속적이지 않아도 된다. : 제일 쉬운케이스 간단한게 시쿼스로 변경하여 해결.
2. 번호가 연속적이지 않아도 되나 채번시의 번호가 간단하지 않고 로직이 있음.
 채번 로직의 트랜잭션을 고립시켜. 혼자 따게 한다.
3. 번호가 연속적으로 맞아야 한다.
   제일 문제되는 케이스로, 최대한 트랜잭션 에 포함되는 로직을 튜닝하여 최대한 빠르게 해야 한다.
  조회->채번->업무트랜잭션->결과 조회 같은 로직이 있을 경우 결과 조회같은 로직은 트랜잭션에서 제외하여, 최대한 트랜잭션을 효율적으로 해야함.

케이스 3
오라클 바인딩 변수 사용으로 인해 각 오라클 인스턴스의 플랜이 달라 문제가 생겼던 부분.
이 부분은 dba분이 해결.
dba분이랑 was문제다 db문제다로 줄당기가 힘들었는데.
was 구조까지 설명해가면서 설득한 결과, 결국 db문제 였음.
역시 오라클 책에서는 몇번 본적이 있는거 같은데. 역시 닥치면 파악하기가 어려웠다.
              L4
        ----------
       |              |            
    was1         was2  
       |              |
     db1  -rac-  db2

이런 형식으로 하드웨어 구성이 되어있었을 경우.
가끔식 was1이나 was2에서 특정 구문의 sql이 느려지는 현상이 발생
was2에서는 같은구문의 sql이 빠름.
was1 전체 인스턴스(컨테이너)가 느려지는 현상이 발생하였을 경우 의심해 볼만한다.
최초에 오라클이 바인딩변수 피킹을 할때, 재수 좋게 특정 케이스의 변수에서는 빠른 플랜을 생성하여,
특정 케이스의 변수시에어는 빠르지만. 그외의 모든 타입에 대해서는 좋지 않은 플랜을 생성하여, 비효율적인 액세스로 인해 느려지는 현상이 발생.

해결법 : 힌트를 사용하여, 플랜을 고정시켜 해결.

결론
트랜잭션 처리를 잘해야 한다.
트랜잭션은 최대한 짧게.
트랜잭션처리후 결과 조회로직은 넣지 않는게 성능에 좋다.(이런 이쪽 관련 문제가 심각하군)

요즘 java bytecode instructions에 관해서 보고 있는데.

예전 학부 시절에 배웠던 어셈블리와 동작형식이 거의 유사하다.

반대로 jvm위에 올라가는거라서 그런지 어셈블리보다 더 간단한데..

이런걸보면 전산쪽은 특별한 마법이 존재하지는 않는곳인거 같다.

과거의 기술이 재포장되서 더 좋게 변질되는 현상이 너무 많이 나온다.

컴파일 랭귀지->스크립트 랭귀지->컴파일+스크립트 랭귀지로 발전되듯이 과거의 양분을 먹고 자란다고 할까..

 bci기술은 곧 대중화가 되지 않을까 생각한다.

aop기술로 이미 어느정도 이미지는 알려져있는데..

aop에서 보다 더 하위 핸들링을 할려는 사람들이 생길것이고, 이건 bci쪽으로 이어질수 뿐이 없는것같다.

제니퍼같은 툴을 보더라도, 통합팀이나 이런 전체 시스템에 영향을 끼쳐야하는 팀들관점에서는 매우 좋은기술이고 생각된다.

회사에서 제니퍼(jennifer)를 사용중이라.

어떻게 돌아가는건지 궁금하고 해서 직접 까서 대략적으로 분석을 한번 해봤습니다.

자바에 대해서 확실하게 알고 있어야 만들수있는 솔류션이라고 판단됩니다.

기존 jvm 프로파일 같은경우는 부하가 커서 운영장비에 사용하기 힘들었는데.

제니퍼의 경우 그렇지가 않죠. 방식도 궁금하고.. 대략적으로 한번 아는데 까지만 설명해 보겠습니다.

일단 돌아가는 방식은 was를 직접 후킹하는 방법을 사용하고 있더군요.
처음에는 cg라이브러리나 AspectJ 같은걸로 강제로 코드를 인젝션 하는 줄 알았는데. 그런건 아니고 소스가 직접 박혀있었다는. AspectJ같은걸로 한번 돌리면 자동으로 박히는 건가??
이부분은 정확하지않아서...--a
암튼 이부분은 패스하고.

기존 class 파일을 자신이 커스터 마이징한 class 파일로 교체해 코드를 주입합니다..
그리고 datasource같은 것들은 자신이 커스터 마이징한 class를 기존의 datasource의 클래스 로더보다 더 상위로 놓아 먼저 로딩하게 하여. 자신의 소스를 주입합니다.
기존의 리퀘스트가 들어오면 쓰레드 값을 기준으로 하는 맵에 데이터를 저장해 놓고. 추가적으로 threadlocal 객체를 사용하면 되겠죠.
처리가 끝날 경우 기존 맵에서 데이터를 꺼내 데이터를 추출하여 처리를 합니다.

간단하게는 위와 같은데.. 통계나 이런 부분이 심오한듯 하네요.

아래는 심오한 말이네요..
You and I are the same engineer for the same purpose.

오늘도 역시 직장인의 낙인.... 커피타임을 했져.

DBA분하고 이런 저런 얘기를 했는데.
어떤 사람에 대한 얘기가 나왔습니다.

어떤 사람이냐 하면 주로 입으로 일하시고.. --a..
일 한번하면 무지 시끄럽게 떠들고 다니고, 일은 혼자 다하는 시늉만 내시고
실제로는 다 아래 애덜이 합니다.
괜시리 집에 안가고 회사에서 밤새고 그런 분.
IT쪽으로는 전혀 아는게 없고 업무만 약간 아는 사람인데. 파트장입니다.

뭐 개발자 입장에서는 최악으로 보이는 그런 사람이죠.
저런 사람도 줄타고 연봉많이 받고 일하는 구나.
암튼 이런 저런말이 나오고 있었는데.

그래도 그사람이 연봉값은 한다는 말이 나왔네요.

이유인 즉 슨.. 가격을 그렇게 잘 후려쳐서 온다고 하는 하네요.
20억 짜리를 10억에 가져오니.. 위에서는 좋아한다고 하더라구요. --;
위에서는 보이는거는 어차피 얼마에 해왔나만 보니.. 허..

개발자 쪽에서 죽어라 개발해서 시스템 만들고 있는데..
개발은 별볼일 없고. 가격 후려쳐서 오는게 대우라니..

오늘도 뭔가 좀더 편하고 쉽게 개발할수 있는 방법이 없나 생각하고 있었는데.
갑자기 허탈해지네요.

세상 참 재밌죠.