FireBird Forum
C++Builder  |  Delphi  |  FireMonkey  |  C/C++  |  Free Pascal  |  Firebird
볼랜드포럼 BorlandForum
 경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지
파이어버드 포럼
Q & A
FAQ
팁&트릭
강좌/문서
자료실
볼랜드포럼 홈
헤드라인 뉴스
IT 뉴스
공지사항
자유게시판
해피 브레이크
공동 프로젝트
구인/구직
회원 장터
건의사항
운영진 게시판
회원 메뉴
북마크
IBPhoenix
FireBird Main site
볼랜드포럼 광고 모집

FireBird Q&A
[2847] Re:이Re:Re:Re:Re:초당 수십레코드를 저장하는 어플에서 대략 5~10일정도 돌리면 쓰기속도가 현저히
삽질 [day1102] 3204 읽음    2008-05-27 02:24
안녕하세요..

저는 Redhat Linux에서 firebird 2.0 버전을 설치하고 바람님과 동일하게 초당 수십건의
로그를 insert 하는 routine을 가지고 있는 app.가 내장된 장비를 만들고 있습니다.
'엔서버'님께서 말씀하신, 멀티코어에서 문제가 있단 말씀은... 저도 한번 검토를 해봐야 할 것
같구요, 제가 개발하는 환경은 700 Mhz 정도의 성능을 가진 CPU이며 멀티코어 환경은
아닙니다. 그리고 classic server를 사용하고 있습니다.

먼저 명확한 답을 못드릴 것 같아 죄송하구요, 혹시 다른 분들도 '바람'님이나 저와 비슷한 경험
있으신 분들은 답변 주시면 감사하겠습니다.

'바람'님께서 질문하신 내용이 두 가지인 것 같습니다.

[첫 번째]
"초당 수십레코드를 저장하는 어플에서 대략 5~10일정도 돌리면 쓰기속도가 현저히 떨어지며
어플이 뻗어버립니다." 라고 하셨는데, 저도 비슷한 경험이 있습니다.
성능 테스트를 위해 저는 이론상으로는 초당 1000개 정도의 log를 강제로 insert 하도록 tool을 만들어
테스트를 하였는데, 어느 정도 Insert를 하면 지속적으로 HDD 사용량이 늘어가다가 일정 시간이 경과하면
HDD 사용량이 증가하는 것이 현저히 떨어집니다.
이 현상은 테스트 Tool의 구동 시간에 비례하더군요.
이럴 땐 DB 접속 조차 안되고 hang이 걸립니다. 
혹시나 해서 gfix로 transaction을 강제 commit해도 별다른 효과가 없었습니다.
몰론 auto commit이구요, gfix로 sync, async 둘 다 해봐도 결과는 동일하더군요.
시스템을 reboot 해도 마찬가집니다.

희안한 현상은, DB 접속이  hang 걸린 놈을 가만 냅두면 어느 순간엔가 정상 접속이 됩니다.
그 이후론 모든 것이 정상 복원이 되더군요.

무슨 짓을 해도 해결책을 찾지 못해 저는 다음과 같은 방법으로 해결 (언 발에 오줌누기..ㅠ.ㅠ)
를 했습니다.

(1) log와 정책을 관리하는 DB 파일을 분리하여 관리하였습니다.
insert 가 빈번한 log DB는 접속에 장애가 있을 경우, 접속을 지속적으로 대기하면서
그 사이에 발생하는 로그는 파일에 기록합니다. 이후 접속이 재개되면 파일의 로그를 log DB에
insert 합니다.

(2) 일정시간이 지나도록 log DB 접속이 되지 않으면 자동으로 바람님이 하신 것 처럼 gbak으로
백업/복원을 합니다.

(3) 주기적으로 로그 DB를 gbak을 이용해 백업합니다. 단, 백업 파일은 최신의 것 하나만 보관합니다.

(4) 하다하다 안된다.... 이럴땐 과감하게 현재 log DB를 파일 째로 삭제해버리고,
gbak으로 3번 과정에서 보관 중인 백업 파일로 복원합니다.

(5) 예외처리 대상 오류가 발생하면 무조건 gbak으로 강제 백업/복원합니다.
(page가 깨졌다던가.. index가 깨졌다던가.. 뭐 이럴 때..)

물론, 전 과정은 백그라운드에서 진행되며 과정 진행 중에 log DB가 없거나 백업, 복원 중일 경우에는
파일에 현재 log를 기록하였다가 나중에 log DB가 정상 상태일 때 insert 합니다.

잘 아시겠지만.... 제가 생각해도 저건 인간이 할 짓이 아니였습니다..ㅠ.ㅠ
혹시 잘 아시는 고수님 계시면 문제가 발생하는 원인이 무엇인 지 답을 주시면 감~~솨 하겠습니다.

[두 번째]
"백업 & 리스토어시 1기가가 350메가로 줄어들수 있는지입니다 " 라고 하셨는데, 이건 제가 아는 바대로
말씀 드리겠습니다.

저도 HDD 관리 측면에서 어느 정도 시간이 경과된 log에 대해서는 delete 한 후 DB shrink 같은 기능을
찾았더랬는데... 알고 보니 이 눔의 firebird는 그런게 없더군요.
결국 가능한 방법이 백업/복원을 하는 것이었습니다.
바람님도 어플 시작 시 delete를 하신다니 삭제 공간 만큼 자동으로 file size가 안줄어드는 것은
이유를 아실 것이구요, 이럴 때 필요한 것이 DB shrink 기능이겠죠.
뭐 아무튼, firebird 관련해서 사이트를 찾아들어가 봤더니... 뭐라뭐라 말이 많던데...
결론은 "firebird는 내부적으로 관리가 마~이 틀리다. 고로~ shrink 안된다" 이거더군요. 뭐 그렇답니다.
문제는, 이눔의 백업/복원이 file size가 크면 클 수록 하세월이란게 문제더군요.
답이 되었는 지 모르겠습니다. 저도 워낙에 부실한지라..

그럼 즐코~ 하세요.

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

바람 님이 쓰신 글 :
: 항상 성실한 답변 주셔서 너무너무 감사합니다.
:
: 먼저 알려주신 점검사항 중 디스크 용량이나 시스템 사양은 문제가 없습니다.
: 시스템 사양은
:    - CPU       : 제온 쿼드코어 2.0 GHz (64bit)
:    - Memory : 2 GByte
:    - OS         : 윈도 2003 서버(32 bit)
:    - HDD       : 500기가
:    - Firebird  : Version 2.1 - SuperServer(32bit)  입니다.
: 디비가 있는 디스크용량은 500기가중 200 기가를 파티션해서 쓰고 1.1기가 사용중입니다.(DB가 1기가일때)
:
: 그리고 복잡한 쿼리는 쓰지않습니다.
: 단순한 쿼리에 수집된 데이터값의 임계치를 설정해두고 그 로그기록과 분단위, 시단위, 일일단위의
: 누적값 기록을 위해 트리거를 쓰고 있습니다.  
:
:  그리고 어플 시작시 초기화 쿼리도 WHERE 조건도없는 단순한
: DELETE FROM TBL_AAAA      // Record 수 : 대략 10~100 여개내외
: DELETE FROM TBL_BBBB     // Record 수 : 대략 100~1000 여개 내외
: 딱 두 라인 입니다.
:
: 트랜잭션 페어에대해선 수십번 점검하였고 예전에 그렇게 문제가생겨 Excepption로그를 남겨 확인 해보니
: 명확히 Deadlock 관계라고 오류를 밷어내더군요.
:
: 다들 의아하게 생각하는 부분은 백업 & 리스토어시 1기가가 350메가로 줄어들수 있는지입니다 .
: (저 말고 다른 분들도 백업 & 리스토어를 했을때  줄어드는 정도의 차이는 있지만 분명 의아하게 생각하는 부부입니다)
: 이부분에 대한 참고가 될만한 자료가 있는지요.
:
: 참으로 내공이 부족한 제탓을 하고 있자니 답답 할 따름입니다.
:
: 다시한번 항상 성실한 답변 주셔서 너무 감사합니다.
: 그럼......
:
:
: ==================================================================================================
: 박지훈.임프 님이 쓰신 글 :
: : 파이어버드는 트랜잭션 로그를 사용하지 않기 때문에 그것 때문일 리는 없을 거구요.
: : 말씀하신 것을 보면, 제 상황하고는 다른 것이 UPDATE입니다. 저는 순수하게 INSERT밖에 없었습니다.
: :
: : 아마 UPDATE를 하고 나면, 파이어버드의 특성상 이전의 레코드를 업데이트하는 것이 아니라 새로운 레코드를 만들게 될 겁니다. 버저닝(versioning)을 한다고 하죠. 내부적으로는 새로운 레코드를 인서트하고 기존 레코드를 안보이게 하는 겁니다(DELETE와는 좀 다를 듯).
: :
: : 그런데, 이런 버저닝 결과로 가비지가 생긴다고 해도, 그것때문에 심각하게 느려진다는 것은 좀 상식적으로 안맞는 거 같고... 인서트나 업데이트에서 단순 쿼리문이 아닌 특이한 쿼리를 쓴다든지 그렇지는 않은가요? 예를 들면.. select count(*) 이런 식으로 count를 세고 있다든지요. 파이어버드에서 레코드가 많을 때 count는 많이 느립니다.
: :
: : 혹은, 하드디스크의 남은 용량이 적을 경우 단편화로 인해서 디스크 액세스 타임이 떨어지고, 그 결과로 속도가 극도로 떨어질 수도 있을 겁니다. 전반적인 상황을 다 봐야 문제가 뭔지 짚을 수가 있을 거 같은데..
: :
: : 그럼...

+ -

관련 글 리스트
2830 초당 수십레코드를 저장하는 어플에서 대략 5~10일정도 돌리면 쓰기속도가 현저히 떨어집니다. 바람 2675 2008/05/16
2834     Re:초당 수십레코드를 저장하는 어플에서 대략 5~10일정도 돌리면 쓰기속도가 현저히 떨어집니다. 박지훈.임프 2762 2008/05/22
2839         Re:Re:초당 수십레코드를 저장하는 어플에서 대략 5~10일정도 돌리면 쓰기속도가 현저히 떨어집니다. 바람 2388 2008/05/22
2843             Re:Re:Re:초당 수십레코드를 저장하는 어플에서 대략 5~10일정도 돌리면 쓰기속도가 현저히 떨어집니다 박지훈.임프 2918 2008/05/22
2844                 이Re:Re:Re:Re:초당 수십레코드를 저장하는 어플에서 대략 5~10일정도 돌리면 쓰기속도가 현저히 떨어 바람 2466 2008/05/23
2847                     Re:이Re:Re:Re:Re:초당 수십레코드를 저장하는 어플에서 대략 5~10일정도 돌리면 쓰기속도가 현저히 삽질 3204 2008/05/27
2849                         Re:Re:이Re:Re:Re:Re:초당 수십레코드를 저장하는 어플에서 대략 5~10일정도 돌리면 쓰기속도가 현 바람 2638 2008/05/27
2845                     Re:이Re:Re:Re:Re:초당 수십레코드를 저장하는 어플에서 대략 5~10일정도 돌리면 쓰기속도가 현저히 엔서버 2833 2008/05/23
Google
Copyright © 1999-2015, borlandforum.com. All right reserved.