현재 위치

홈 ›› Forums ›› 공부 ›› 설치 및 활용 QnA

서버 시스템 부하 해결 방안.. 질문..

suk2059의 이미지
글쓴이: suk2059 / 작성시간: 수, 2004/09/08 - 11:36오전

만약 서버를 운영중에.. 사용자가 폭주하여 서버에 부하가 걸리면서 느려질때..

단기적인 부하를 줄이기 위해선 쿼리 수정으로 가능한가요??

장기적으로 생각하는 부분에선 하드웨어 업그레이드가 우선인가요?

당사자가 되어서 서버 부하로 시스템이 많은 부분 느려진다면 어떻케 하는게 단

기적으로는,장기적으로는 어떤대처를 취해야 하나요..?

Forums: 
설치 및 활용 QnA
budle77의 이미지

글쓴이: budle77 / 작성시간: 수, 2004/09/08 - 11:44오전

쿼리 튜닝을 하면 어느정도 부하가 걸리는걸 방지할수 있겠지만, 사용자가 계속 늘어날걸 생각하면 시스템 업그레이드는 피할수 없겠죠.

경영진의 입장이라면 개발자에게 어플리케이션 튜닝을 요구하는게 당연(비용이 안 들잖아요)할테지만 장기적으로는 서비스 추가 및 변경, 그리고 사용자 증가를 고려한다면 어플리캐이션 튜닝과 시스템 업그레이드를 병행하는게 좋을겁니다.

madhatter의 이미지

글쓴이: madhatter / 작성시간: 수, 2004/09/08 - 11:45오전

그런 경우에 쿼리 수정으로 부하를 줄인다는 말은..튜닝이 필요한데 하지 않았다는 것과 같습니다. 단기적인 대책이라고 말하기엔 좀 어폐가 있을 것 같네요.
사실 일시적인 사용자 폭주에는 답이 없습니다. 하드웨어 증설이 가장 장기적이고도 적절한 대책이구요, 일시적으로 사용자가 폭주할만한 요인이 있다면(단기성 이벤트등의) 장비를 대여해서라도 캐퍼를 좀 늘려놓는 게 좋겠지요.

ㅡ,.ㅡ;;의 이미지

글쓴이: ㅡ,.ㅡ;; / 작성시간: 수, 2004/09/08 - 12:44오후

쿼리수정이 더중요한 부분일수 있습니다. 단기적이란게 말이좀안맞겠죠..

예를들어 자금을2배투자하여 하드웨어를 2배가량 늘렸다면 처리능력이 2배가 되었다치고 회원수를 2배가량 더견디겠지요....

그러나 이렇게 했다해서 문제가 완전히 없어지지는 않을겁니다
대부분의경우 문제는 정책과 프로그램 로직에 있답니다.
쿼리문제도 그일부지요..
즉 하드웨어를 늘리는것보다 훨씬중요한것이 정책과 프로그램로직이겠죠..

정책튜닝 -> 로직튜닝 -> 쿼리튜닝 -> 적정HW 셋팅

정책튜닝을하려면 프로그램을 잘알아야 가장업무에도 효과적으로대처할수 있고
프로그램성능도 최대화할수 있는 정책을 설정하겠지요..

물론 정책을 바꿀수 없다면 그다음은 로직을 고려해봐야겠지요..


----------------------------------------------------------------------------

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 수, 2004/09/08 - 1:19오후

위에 말씀하신 내용이 맞습니다만,
저는 현실적인 말씀을 드리고 싶습니다.

쿼리튜닝과 로직 수정은 장기적인 관점에서 진행 되어야 합니다.
보통 문제를 해결하기 위해서는 단기적인 대책과 장기적인 다시말해 근본적인 해결책이 병행되어야 하는 경우가 대부분 입니다.

일반적으로 소프트웨어적인 튜닝의 효과는 30%정도를 넘지 못합니다.
물론 더 나오는 경우도 있습니다만,
그런 경우가 발생한다면, 인력편성이나 플랫폼등 그 자체가 문제라고 하겠습니다.
현실적으로 사용자가 폭주하는 상황에서 어느세월에
1. 현재 성능 테스트
2. 튜닝
3. 튜닝 효과 테스트
4. 튜닝
5. 튜닝 테스트.
6. 결과 확인
이러고 있겠습니까.
차라리 하드웨어를 임대를 하든, 구매를 하든 추가 시키고
어느정도 안정되고 난 후 튜닝 작업을 하는게 맞다고 하겠습니다.
또한 사용자가 폭주하고 있는 상황에서 튜닝을 한다는 생각도 위험한 생각입니다.

소프트웨어 튜닝이 돈이 안든다는 사실은 맞지 않다고 생각됩니다.
개발한 사람이 튜닝을 하다니...:(
중이 자기 머리 못 깍는거죠.. :)
효과도 별로 없을 뿐더러 시간도 많이 듭니다.
다시말해 제대로 효과를 보려면 별도 인원을 편성해야 합니다.
차라리 서버 한대 사는게 더 싸지 않겠어요?

ㅡ,.ㅡ;;의 이미지

글쓴이: ㅡ,.ㅡ;; / 작성시간: 수, 2004/09/08 - 3:19오후

Anonymous wrote:

일반적으로 소프트웨어적인 튜닝의 효과는 30%정도를 넘지 못합니다.
물론 더 나오는 경우도 있습니다만,
그런 경우가 발생한다면, 인력편성이나 플랫폼등 그 자체가 문제라고 하겠습니다.
현실적으로 사용자가 폭주하는 상황에서 어느세월에
1. 현재 성능 테스트
2. 튜닝
3. 튜닝 효과 테스트
4. 튜닝
5. 튜닝 테스트.
6. 결과 확인
이러고 있겠습니까.
차라리 하드웨어를 임대를 하든, 구매를 하든 추가 시키고
어느정도 안정되고 난 후 튜닝 작업을 하는게 맞다고 하겠습니다.
또한 사용자가 폭주하고 있는 상황에서 튜닝을 한다는 생각도 위험한 생각입니다.

소프트웨어 튜닝이 돈이 안든다는 사실은 맞지 않다고 생각됩니다.
개발한 사람이 튜닝을 하다니...:(
중이 자기 머리 못 깍는거죠.. :)
효과도 별로 없을 뿐더러 시간도 많이 듭니다.
다시말해 제대로 효과를 보려면 별도 인원을 편성해야 합니다.
차라리 서버 한대 사는게 더 싸지 않겠어요?

소프트웨어튜닝의 효과가 30%를 넘지못하다니요..
님은 아주 상당히 잘못알고 계시는군요.. 소프트웨어의 튜닝은 하드위어튜닝보다 훨씬 유동적인 효과가 납니다. 즉, 거의 안날수도 있고 수백% 가 날수도 있습니다. 실제로 오래전일이지만 제가 모대기업의 정산시스템을 수백% 향상시킨경험이 있습니다. 아니 몇일걸리던것을 불과 20분정도만에 나오게 했으니까요..
몇천%는 되는군요..

또한 제가 위에 말했듯이 소프트위어적인 튜닝은 오히려 단기적이 아니다..즉,장기적이란말이죠.. 이말은 님이 약간 반대로 이해하신듯합니다..
그러나 소프트웨어적인튜닝이 반드시 시간이 더걸리는것도 아닙니다.
이것도 상당히 유동적이죠..HW적인추가를 하려면 반드시 몇일정도의 시일이 걸리지만.. SW 는 짧을수도 있고 아주길수도 있겠죠..

개발한사람이 튜닝불가능하다는것도 말이 안되죠..
Linux 나 Oracle 거의 대부분의 프로그램들이 거의 같은 맴버가 upgrade 하지 항상다른사람이 와서 튜닝하지는 않죠..
한번개발한후 개발자를 없애버리는것은 참으로 안좋은방식이라생각합니다.
이를 뻔히 아는개발자는 아마도 신념을갖고 그리 잘만들려고 하지 않을겁니다.

서버를 한대더추가하는가 아니면 튜닝을할것인가는 상황을 봐가면서 판단해야겠지요..


----------------------------------------------------------------------------

LispM의 이미지

글쓴이: LispM / 작성시간: 수, 2004/09/08 - 4:30오후

시스템이 어떤식으로 구성되어서 어떤 이유로 폭주하는지 모르겠지만, 여러 층으로 설계했고 이미 각 층에서 적절한 캐쉬를 했다면, 하드웨어 특히 메모리를 추가해 봐야 겠죠.

저희 팀이 개발중인 시스템의 경우 2 계층에서 캐쉬를 하기 때문에 불필요한 DB 쿼리 자체가 최대한 일어나지 않도록 했는데, 만일 이렇게 설계하지 않은 시스템이라면 매번 DB까지 갔다와야 하고 비록 DB에서 캐쉬한다고 해도 속도는 크게 떨어지겠죠.

위에서 말씀하신 소프트웨어 튜닝이라는 것이 바로 이말이 아닐까 생각되는 군요. 위와같은 근본적인 문제가 해결이 안된다면 하드웨어를 아무리 늘려봤자 소용 없거든요.

만일 크리티컬한 문제라면, 경험있는 사람에게 컨설팅 받아 최소의 수정으로 계층을 두어 불필요한 쿼리를 제거하기만 해도 괜찮지 않을까 생각합니다.

제 경우 DB 쿼리와 관련해서는 다음의 점에 특히 유의합니다.
1. 캐쉬로 불필요한 쿼리를 줄인다.
2. 대부분의 쿼리는 DB를 1회 hit하여 원하는 결과를 얻을 수 있도록 작성한다.
3. DB 테이블의 인덱스를 적절히 설정한다.

그래도 문제가 생길 때는 메모리 증설을 가장 먼저 떠올립니다.

http://lisp.or.kr http://lisp.kldp.org - 한국 리습 사용자 모임

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 목, 2004/09/09 - 9:48오전

Quote:
소프트웨어튜닝의 효과가 30%를 넘지못하다니요..
님은 아주 상당히 잘못알고 계시는군요.. 소프트웨어의 튜닝은 하드위어튜닝보다 훨씬 유동적인 효과가 납니다. 즉, 거의 안날수도 있고 수백% 가 날수도 있습니다. 실제로 오래전일이지만 제가 모대기업의 정산시스템을 수백% 향상시킨경험이 있습니다. 아니 몇일걸리던것을 불과 20분정도만에 나오게 했으니까요..
몇천%는 되는군요..

개발 단계에서부터 문제가 있었다는 이야기가 되겠지요.
저런 효과가 난다면 그건 튜닝이 아니고 디버깅이라고 해야겠지요.
거의 안날 수도 있고 수백%가 날수도 있는 다시말해 불확실한 결과를 기다리며
기다릴 시간이 없다는게 제 의견입니다.
말꼬리를 잡고 싶은것은 아닙니다만 말씀하시는 내용을 보고 대기업 전산실
프로젝트를 경험으로 말씀하시는 것이리라 예상했었습니다.
물론 대기업 전산실은 상대적으로 튜닝할 시간이 있습니다만(업무 종료후),
B2C 사이트는 이야기가 다릅니다.
대기업 전산실과 닷컴기업의 서비스는 접근방식과 환경이 다릅니다.
포털사이트에서 전산실에 1U서버를 쌓아놓는게 괜히 그러는게 아니겠지요.

Quote:
또한 제가 위에 말했듯이 소프트위어적인 튜닝은 오히려 단기적이 아니다..즉,장기적이란말이죠.. 이말은 님이 약간 반대로 이해하신듯합니다..
그러나 소프트웨어적인튜닝이 반드시 시간이 더걸리는것도 아닙니다.
이것도 상당히 유동적이죠..HW적인추가를 하려면 반드시 몇일정도의 시일이 걸리지만.. SW 는 짧을수도 있고 아주길수도 있겠죠..

저는 소프트웨어 튜닝은 장기적인 관점에서 단기적인 해결 방법과 동시에 진행되어야 한다고 글을 남겼는데요. ㅡㅡ;;
다시 말씀드립니다만, 소프트웨어 튜닝의 효과는 아주 유동적이기 때문에
장기적인 관점에서 진행되어야 합니다.

Quote:
개발한사람이 튜닝불가능하다는것도 말이 안되죠..
Linux 나 Oracle 거의 대부분의 프로그램들이 거의 같은 맴버가 upgrade 하지 항상다른사람이 와서 튜닝하지는 않죠..
한번개발한후 개발자를 없애버리는것은 참으로 안좋은방식이라생각합니다.
이를 뻔히 아는개발자는 아마도 신념을갖고 그리 잘만들려고 하지 않을겁니다.

중이 자기머리 못깍는것처럼
자기가 개발한 프로그램 자기가 베타 테스트 못하는 것과 마찬가지 입니다.
개발자를 없애버리는 것이라고 말씀드린 적 없습니다.
논리의 비약입니다.

Quote:
서버를 한대더추가하는가 아니면 튜닝을할것인가는 상황을 봐가면서 판단해야겠지요

동시에 병행되어야 하는 경우가 대부분입니다.
이거 아니면 저거라는 의견은 위험한 생각 아닐까요?
단기적, 장기적 해결이 동시에 병행되어야 한다고 말씀드렸습니다.
제가 남긴글을 다시한번 읽어 보세요.

마지막으로

Quote:
님은 아주 상당히 잘못알고 계시는군요..

이런 말은 게시판에서 자제해 주시면 감사하겠습니다.
감정이 나서게 되지 않겠습니까?
ㅡ,.ㅡ;;의 이미지

글쓴이: ㅡ,.ㅡ;; / 작성시간: 목, 2004/09/09 - 4:14오후

Anonymous wrote:
개발 단계에서부터 문제가 있었다는 이야기가 되겠지요.
저런 효과가 난다면 그건 튜닝이 아니고 디버깅이라고 해야겠지요.

대충 이런말 하실거라 예상되었습니다.
제가 상황이 어떤거라 말한적도 없는데 님은 오직 성능개선이 얼마나되었는지만보고
많이 된것은 디버깅이고 적게된것은 성능개선이라고 못박아버리는군요.
너무 독단적인 의견이라고 생각되는군요.
Quote:

말꼬리를 잡고 싶은것은 아닙니다만 말씀하시는 내용을 보고 대기업 전산실
프로젝트를 경험으로 말씀하시는 것이리라 예상했었습니다.
물론 대기업 전산실은 상대적으로 튜닝할 시간이 있습니다만(업무 종료후),
B2C 사이트는 이야기가 다릅니다.
대기업 전산실과 닷컴기업의 서비스는 접근방식과 환경이 다릅니다.
포털사이트에서 전산실에 1U서버를 쌓아놓는게 괜히 그러는게 아니겠지요.

저는 소프트웨어 튜닝은 장기적인 관점에서 단기적인 해결 방법과 동시에 진행되어야 한다고 글을 남겼는데요. ㅡㅡ;;
다시 말씀드립니다만, 소프트웨어 튜닝의 효과는 아주 유동적이기 때문에
장기적인 관점에서 진행되어야 합니다.


A: a는 b다
B: 아니죠 a는 b 입니다.
A: ? 그러니까 제가 a 는 b다라고 한겁니다.
B: 저는 a는 b다라고 했는데요.ㅡㅡ;;
A: ㅡ,.ㅡ;;

Quote:

중이 자기머리 못깍는것처럼
자기가 개발한 프로그램 자기가 베타 테스트 못하는 것과 마찬가지 입니다.
개발자를 없애버리는 것이라고 말씀드린 적 없습니다.
논리의 비약입니다.

동시에 병행되어야 하는 경우가 대부분입니다.
이거 아니면 저거라는 의견은 위험한 생각 아닐까요?
단기적, 장기적 해결이 동시에 병행되어야 한다고 말씀드렸습니다.
제가 남긴글을 다시한번 읽어 보세요.

마지막으로

Quote:
님은 아주 상당히 잘못알고 계시는군요..

이런 말은 게시판에서 자제해 주시면 감사하겠습니다.
감정이 나서게 되지 않겠습니까?

님이 개발자 없애버리는 것이라고 말했다고 한적 없습니다.
님이 비약해서 받아들이셨군요..

또한 이것아니면 저것이라고 한적도 없는데 참 이상하군요.
저는 상황을 봐가면서 판단해야한다고 했습니다.
제가적지않은글이 보이는모양입니다.

마지막에 그런문제라면 님이 애초에 잘못하셨군요..

Quote:

어느세월에 ...이러고 있겠습니까.
... 튜닝을 한다는 생각도 위험한 생각입니다.

"잘못알고 있다" VS "위험한생각이다"
의 대결이군요..ㅎㅎ

그리고 웬만하면 로그인해서 글올리시는게 좋을듯합니다.
사실 손님은 님뿐만이 아니거든요..
그래서 머라고 부르기도 그렇고 또 다른손님과 헷깔릴수도 있거든요.


----------------------------------------------------------------------------

댓글 달기

텍스트 포맷에 대한 자세한 정보

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
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.