다른 분들은 로그 기록을 어떤 방식으로 하는지 궁금합니다. ^^

aswip의 이미지

멀티쓰레드 환경에서, 다른 개발자분들깨서는 로그기록을 어떤방식으로 하는지 궁금하여 이렇게 질문을 올립니다. 현재 저는 락킹처리후 로그파일에 로그 내용을 Append 하는 방식을 사용하고 있지만, 동시에 여러개의 쓰레드가 로그를 기록할 경우, 일부 병목현상이 발생하여, 이나마도 그리 좋은 로그 기록방식 같지는 않습니다. 막상 적고나니, 질문 보다는 조언에 가까운 답을 기다리는 느낌이네요~ ㅋㅋㅋ, 그럼 행복한 주말 되세요~ ^____________^

IsExist의 이미지

syslog 는 어떨까요

man openlog
man syslog
man closelog

man syslog.conf

LOCAL0 ~ LOCAL7 까지 사용하면 편합니다.

---------
간디가 말한 우리를 파괴시키는 7가지 요소

첫째, 노동 없는 부(富)/둘째, 양심 없는 쾌락
셋째, 인격 없는 지! 식/넷째, 윤리 없는 비지니스

이익추구를 위해서라면..

다섯째, 인성(人性)없는 과학
여섯째, 희생 없는 종교/일곱째, 신념 없는 정치

ssehoony의 이미지

락킹 안하고 그냥 기록합니다.

fprintf, fwrite, write 함수등의 호출 단위별로는 꼬이는 일이 없습니다.
그래서 그냥 락킹 없이 write 해버립니다.

peccavi의 이미지

ssehoony wrote:
락킹 안하고 그냥 기록합니다.

fprintf, fwrite, write 함수등의 호출 단위별로는 꼬이는 일이 없습니다.
그래서 그냥 락킹 없이 write 해버립니다.

여러개의 스레드에서 하나의 파일 디스크립터를 공유하고 있는데

이 fd를 i/o 할때마다 mutex를 걸어주고 있습니다.

근데 이걸 걸어줄 필요가 없다는 말씀이신가요? :shock:

----
jai guru deva om...

익명 사용자의 이미지

윗에분이 말씀하셨듯이, 락킹 처리없이 로그 기록은 싱글 프로세스, 싱글쓰레드 환경이 아니고서는, 문제가 될 소지가 다분히 있습니다. 이와 관련된 정보를 몇가지 찾아보았는데, 정리하면 다음과 같았습니다.

1. 로그 기록전 버퍼링 한다.
=> 소규모 IO 작업 (로그를 기록하는 것과 같은 )을 n번 하는것 보다, 대규모 IO 작업을 한번 하는게 성능면에서 좋다.

2. 버퍼링 사이즈 설정시, 클러스트 크기 * n 수로 설정하는 것이 좋다. ( 예를 들어 클러스트 사이즈가 512KB라면, 512Kb * n 으로 버퍼 사이즈를 설정 )

좀 더 좋은 방법이 있을까요?

아니면.. 로그기록만을 위한 하드웨어가 있을려나... ^^;;;

nainu의 이미지

Anonymous wrote:
윗에분이 말씀하셨듯이, 락킹 처리없이 로그 기록은 싱글 프로세스, 싱글쓰레드 환경이 아니고서는, 문제가 될 소지가 다분히 있습니다. 이와 관련된 정보를 몇가지 찾아보았는데, 정리하면 다음과 같았습니다.

1. 로그 기록전 버퍼링 한다.
=> 소규모 IO 작업 (로그를 기록하는 것과 같은 )을 n번 하는것 보다, 대규모 IO 작업을 한번 하는게 성능면에서 좋다.

2. 버퍼링 사이즈 설정시, 클러스트 크기 * n 수로 설정하는 것이 좋다. ( 예를 들어 클러스트 사이즈가 512KB라면, 512Kb * n 으로 버퍼 사이즈를 설정 )

좀 더 좋은 방법이 있을까요?

아니면.. 로그기록만을 위한 하드웨어가 있을려나... ^^;;;

이 말씀을 들으니, 로그 기록만을 위한 클래스 하나 있으면 좋을 것 같네요.

일정 개수까지 자체적으로 버퍼링하고, 좀 찼다 싶으면 한꺼번에 쓰고 비우고....

체스맨의 이미지

스레드별로 따로 출력해뒀다가,
로그를 살펴봐야 할 때 취합하는 것은 어떨까요.

어차피 로그를 살펴봐야 하기 전까지는 로그가 어떤 형태로 기록되어
있는가는 별로 중요한 문제가 아닐테니까요.

Orion Project : http://orionids.org

익명 사용자의 이미지

아파치에서 추천하는 cronolog 를 보시면 어떨까요?

pipe로 처리하는듯합니다.

aswip의 이미지

체스맨 wrote:
스레드별로 따로 출력해뒀다가,
로그를 살펴봐야 할 때 취합하는 것은 어떨까요.

어차피 로그를 살펴봐야 하기 전까지는 로그가 어떤 형태로 기록되어
있는가는 별로 중요한 문제가 아닐테니까요.

락킹 처리는 들어가지 않아도 되겠지만, 잦은 소규모 IO 작업을 피하지는 못할 것 같습니다.

- 인생은 스스로 -

aswip의 이미지

Anonymous wrote:
윗에분이 말씀하셨듯이, 락킹 처리없이 로그 기록은 싱글 프로세스, 싱글쓰레드 환경이 아니고서는, 문제가 될 소지가 다분히 있습니다. 이와 관련된 정보를 몇가지 찾아보았는데, 정리하면 다음과 같았습니다.

1. 로그 기록전 버퍼링 한다.
=> 소규모 IO 작업 (로그를 기록하는 것과 같은 )을 n번 하는것 보다, 대규모 IO 작업을 한번 하는게 성능면에서 좋다.

2. 버퍼링 사이즈 설정시, 클러스트 크기 * n 수로 설정하는 것이 좋다. ( 예를 들어 클러스트 사이즈가 512KB라면, 512Kb * n 으로 버퍼 사이즈를 설정 )

좀 더 좋은 방법이 있을까요?

아니면.. 로그기록만을 위한 하드웨어가 있을려나... ^^;;;

아.. 이글 제가 올린글입니다. ^^;;

효율적인 로그 기록방식을 찾던 도중 DBMS가 위와 같은 방식으로 로그를 남기더라구요. ^^;;

- 인생은 스스로 -

bejoy4him의 이미지

흠.. 제가 맡고 있는 프로세스가 사용하는 방법은 좀 무식합니다만, 나름대로의 어쩔수 없는 몇가지 이유때문에 이 방법을 고수합니다.

10여개의 쓰레드가 각각 로그를 남기게 되는데.. 무식하게 로그를 쌓을일이 있으면 바로 바로 쌓고 flush해 버립니다.(뮤텍스로 파일 IO를 보호하지 않았을때 멎어 버리는 경우도 있었습니다.)
그 양도 좀 엄청납니다. 큰 사이트의 경우 3~4분정도에 5MB를 쌓아 버리고 있는 실정이죠(네트웍으로 주고받는 메시지를 다 찍습니다.)... 그래서 5MB단위로 한 100개 정도 쌓도록 설정해 놓으면 하루를 못넘기고 한바퀴 돌아서 0번부터 다시 쌓기 시작하는 정도입니다.

제가 생각해도 상당히 비효율 적인데.. 생각보다 파일 IO때문에 시스템의 퍼포먼스가 크게 떨어지진 않더군요.. ㅡㅡ;;
이렇게 구현되었던 이유중 하나는 초기에 프로세스가 다운되는 일이 좀 잦아서, 다운되게 만들었던 메시지를 확인해 보기 위함도 있었고 다른 하나는 잘 되다가도 의도하지 않았던 사용법이나 아니면 타이밍적인 문제로 발생한 현상을 추적하기 위함도 있었습니다.

버퍼링 하였다가 쓰도록 하였다면 프로세스가 다운되어버렸을때 정확한 위치를 찾기 힘들어서, 버퍼링은 시도도 해보지 못하였습니다.

컴파일할때 디버그 옵션을 주어서 컴파일하고 프로세스가 다운되면 core파일을 분석한다면 다운된 위치를 쉽게 찾을수 있겠지만, 실제론 좀 어려운 환경입니다.

이런 쓰다보니 질문이 되어 버리는 분위기입니다만, 한가지만 좀 알려주세용.. 디버그 옵션을 주지않고서도 프로세스가 다운될때 마지막으로 수행하였던 스택정보나 아니면 위치 정보를 찍어줄순 없을까요?

ㅋㅋ 난대없이 질문을 해버렷넹...

cb2531의 이미지

프로세스가 다운될때 마지막으로 수행하였던 스택정보나 아니면 위치 정보라...
의심가는 부분 앞뒤로 마구 로그를 찍는 방법 밖엔 없지 않을까요..-_-
멀티쓰레드 디버깅에서는..
죽은 부분과는 상관없는 곳에서 core가 떨어지기도 하는데..
하물며 그냥 로그를 통해서 디버깅 한다면.. 쩝

참.. 저도 비효율적으로 로그 찍는 사람중에 하나랍니다
mutex걸어놓구 바로 파일에 찍죠 ㅎㅎ
안정화 시키면서 로그양을 계속 줄입니다

aswip의 이미지

bejoy4him wrote:
흠.. 제가 맡고 있는 프로세스가 사용하는 방법은 좀 무식합니다만, 나름대로의 어쩔수 없는 몇가지 이유때문에 이 방법을 고수합니다.

10여개의 쓰레드가 각각 로그를 남기게 되는데.. 무식하게 로그를 쌓을일이 있으면 바로 바로 쌓고 flush해 버립니다.(뮤텍스로 파일 IO를 보호하지 않았을때 멎어 버리는 경우도 있었습니다.)
그 양도 좀 엄청납니다. 큰 사이트의 경우 3~4분정도에 5MB를 쌓아 버리고 있는 실정이죠(네트웍으로 주고받는 메시지를 다 찍습니다.)... 그래서 5MB단위로 한 100개 정도 쌓도록 설정해 놓으면 하루를 못넘기고 한바퀴 돌아서 0번부터 다시 쌓기 시작하는 정도입니다.

제가 생각해도 상당히 비효율 적인데.. 생각보다 파일 IO때문에 시스템의 퍼포먼스가 크게 떨어지진 않더군요.. ㅡㅡ;;
이렇게 구현되었던 이유중 하나는 초기에 프로세스가 다운되는 일이 좀 잦아서, 다운되게 만들었던 메시지를 확인해 보기 위함도 있었고 다른 하나는 잘 되다가도 의도하지 않았던 사용법이나 아니면 타이밍적인 문제로 발생한 현상을 추적하기 위함도 있었습니다.

버퍼링 하였다가 쓰도록 하였다면 프로세스가 다운되어버렸을때 정확한 위치를 찾기 힘들어서, 버퍼링은 시도도 해보지 못하였습니다.

컴파일할때 디버그 옵션을 주어서 컴파일하고 프로세스가 다운되면 core파일을 분석한다면 다운된 위치를 쉽게 찾을수 있겠지만, 실제론 좀 어려운 환경입니다.

이런 쓰다보니 질문이 되어 버리는 분위기입니다만, 한가지만 좀 알려주세용.. 디버그 옵션을 주지않고서도 프로세스가 다운될때 마지막으로 수행하였던 스택정보나 아니면 위치 정보를 찍어줄순 없을까요?

ㅋㅋ 난대없이 질문을 해버렷넹...

테스트 중이거나, 문제가 많은 프로세스라면, 로그 버퍼링을 하면 안될것 같습니다. 버퍼링을 하다보면, 말씀하신대로 분명 일부 정보를 놓칠수 있으며, 이는 어쩌면, 사건현장을 해결할 수 있는 유일한 실마리 일수도 있기 때문입니다.

그리고, 두번째 말씀하신 부분은 저두 궁금합니다. 제가 알기로는 없습니다. ^^ 하지만 혹시모르니...

- 인생은 스스로 -

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.