다른 분들은 로그 기록을 어떤 방식으로 하는지 궁금합니다. ^^
글쓴이: aswip / 작성시간: 금, 2005/06/24 - 9:09오전
멀티쓰레드 환경에서, 다른 개발자분들깨서는 로그기록을 어떤방식으로 하는지 궁금하여 이렇게 질문을 올립니다. 현재 저는 락킹처리후 로그파일에 로그 내용을 Append 하는 방식을 사용하고 있지만, 동시에 여러개의 쓰레드가 로그를 기록할 경우, 일부 병목현상이 발생하여, 이나마도 그리 좋은 로그 기록방식 같지는 않습니다. 막상 적고나니, 질문 보다는 조언에 가까운 답을 기다리는 느낌이네요~ ㅋㅋㅋ, 그럼 행복한 주말 되세요~ ^____________^
Forums:
syslog 는 어떨까요man openlogman syslog
syslog 는 어떨까요
man openlog
man syslog
man closelog
man syslog.conf
LOCAL0 ~ LOCAL7 까지 사용하면 편합니다.
---------
간디가 말한 우리를 파괴시키는 7가지 요소
첫째, 노동 없는 부(富)/둘째, 양심 없는 쾌락
셋째, 인격 없는 지! 식/넷째, 윤리 없는 비지니스
이익추구를 위해서라면..
다섯째, 인성(人性)없는 과학
여섯째, 희생 없는 종교/일곱째, 신념 없는 정치
락킹 안하고 그냥 기록합니다.fprintf, fwrite, wri
락킹 안하고 그냥 기록합니다.
fprintf, fwrite, write 함수등의 호출 단위별로는 꼬이는 일이 없습니다.
그래서 그냥 락킹 없이 write 해버립니다.
[quote="ssehoony"]락킹 안하고 그냥 기록합니다.fp
여러개의 스레드에서 하나의 파일 디스크립터를 공유하고 있는데
이 fd를 i/o 할때마다 mutex를 걸어주고 있습니다.
근데 이걸 걸어줄 필요가 없다는 말씀이신가요? :shock:
----
jai guru deva om...
락킹은 필수적입니다.
윗에분이 말씀하셨듯이, 락킹 처리없이 로그 기록은 싱글 프로세스, 싱글쓰레드 환경이 아니고서는, 문제가 될 소지가 다분히 있습니다. 이와 관련된 정보를 몇가지 찾아보았는데, 정리하면 다음과 같았습니다.
1. 로그 기록전 버퍼링 한다.
=> 소규모 IO 작업 (로그를 기록하는 것과 같은 )을 n번 하는것 보다, 대규모 IO 작업을 한번 하는게 성능면에서 좋다.
2. 버퍼링 사이즈 설정시, 클러스트 크기 * n 수로 설정하는 것이 좋다. ( 예를 들어 클러스트 사이즈가 512KB라면, 512Kb * n 으로 버퍼 사이즈를 설정 )
좀 더 좋은 방법이 있을까요?
아니면.. 로그기록만을 위한 하드웨어가 있을려나... ^^;;;
Re: 락킹은 필수적입니다.
이 말씀을 들으니, 로그 기록만을 위한 클래스 하나 있으면 좋을 것 같네요.
일정 개수까지 자체적으로 버퍼링하고, 좀 찼다 싶으면 한꺼번에 쓰고 비우고....
Re: 다른 분들은 로그 기록을 어떤 방식으로 하는지 궁금합니다.
스레드별로 따로 출력해뒀다가,
로그를 살펴봐야 할 때 취합하는 것은 어떨까요.
어차피 로그를 살펴봐야 하기 전까지는 로그가 어떤 형태로 기록되어
있는가는 별로 중요한 문제가 아닐테니까요.
Orion Project : http://orionids.org
아파치에서 추천하는 cronolog 를 보시면 어떨까요?pipe로
아파치에서 추천하는 cronolog 를 보시면 어떨까요?
pipe로 처리하는듯합니다.
Re: 다른 분들은 로그 기록을 어떤 방식으로 하는지 궁금합니다.
락킹 처리는 들어가지 않아도 되겠지만, 잦은 소규모 IO 작업을 피하지는 못할 것 같습니다.
- 인생은 스스로 -
Re: 락킹은 필수적입니다.
아.. 이글 제가 올린글입니다. ^^;;
효율적인 로그 기록방식을 찾던 도중 DBMS가 위와 같은 방식으로 로그를 남기더라구요. ^^;;
- 인생은 스스로 -
흠.. 제가 맡고 있는 프로세스가 사용하는 방법은 좀 무식합니다만, 나름
흠.. 제가 맡고 있는 프로세스가 사용하는 방법은 좀 무식합니다만, 나름대로의 어쩔수 없는 몇가지 이유때문에 이 방법을 고수합니다.
10여개의 쓰레드가 각각 로그를 남기게 되는데.. 무식하게 로그를 쌓을일이 있으면 바로 바로 쌓고 flush해 버립니다.(뮤텍스로 파일 IO를 보호하지 않았을때 멎어 버리는 경우도 있었습니다.)
그 양도 좀 엄청납니다. 큰 사이트의 경우 3~4분정도에 5MB를 쌓아 버리고 있는 실정이죠(네트웍으로 주고받는 메시지를 다 찍습니다.)... 그래서 5MB단위로 한 100개 정도 쌓도록 설정해 놓으면 하루를 못넘기고 한바퀴 돌아서 0번부터 다시 쌓기 시작하는 정도입니다.
제가 생각해도 상당히 비효율 적인데.. 생각보다 파일 IO때문에 시스템의 퍼포먼스가 크게 떨어지진 않더군요.. ㅡㅡ;;
이렇게 구현되었던 이유중 하나는 초기에 프로세스가 다운되는 일이 좀 잦아서, 다운되게 만들었던 메시지를 확인해 보기 위함도 있었고 다른 하나는 잘 되다가도 의도하지 않았던 사용법이나 아니면 타이밍적인 문제로 발생한 현상을 추적하기 위함도 있었습니다.
버퍼링 하였다가 쓰도록 하였다면 프로세스가 다운되어버렸을때 정확한 위치를 찾기 힘들어서, 버퍼링은 시도도 해보지 못하였습니다.
컴파일할때 디버그 옵션을 주어서 컴파일하고 프로세스가 다운되면 core파일을 분석한다면 다운된 위치를 쉽게 찾을수 있겠지만, 실제론 좀 어려운 환경입니다.
이런 쓰다보니 질문이 되어 버리는 분위기입니다만, 한가지만 좀 알려주세용.. 디버그 옵션을 주지않고서도 프로세스가 다운될때 마지막으로 수행하였던 스택정보나 아니면 위치 정보를 찍어줄순 없을까요?
ㅋㅋ 난대없이 질문을 해버렷넹...
-_-
프로세스가 다운될때 마지막으로 수행하였던 스택정보나 아니면 위치 정보라...
의심가는 부분 앞뒤로 마구 로그를 찍는 방법 밖엔 없지 않을까요..-_-
멀티쓰레드 디버깅에서는..
죽은 부분과는 상관없는 곳에서 core가 떨어지기도 하는데..
하물며 그냥 로그를 통해서 디버깅 한다면.. 쩝
참.. 저도 비효율적으로 로그 찍는 사람중에 하나랍니다
mutex걸어놓구 바로 파일에 찍죠 ㅎㅎ
안정화 시키면서 로그양을 계속 줄입니다
10개의 쓰레드라... 300개 정도는 되어야....
테스트 중이거나, 문제가 많은 프로세스라면, 로그 버퍼링을 하면 안될것 같습니다. 버퍼링을 하다보면, 말씀하신대로 분명 일부 정보를 놓칠수 있으며, 이는 어쩌면, 사건현장을 해결할 수 있는 유일한 실마리 일수도 있기 때문입니다.
그리고, 두번째 말씀하신 부분은 저두 궁금합니다. 제가 알기로는 없습니다. ^^ 하지만 혹시모르니...
- 인생은 스스로 -
댓글 달기