음냐...kldp에 뭔일이 있는지 다 알고있다!!

익명 사용자의 이미지

라고 말할수 있었으면 좋겠습니다. -)

아파치에 php에 mysql로 홈페이지를 몇개 만들어 준게 있는데요,
사용자가 늘어날 때 어떤 문제가 발생할 수 있는지,
그걸 어떻게 해결할 수 있는지,
실제 사례를 들어 보고 싶군요.

이런 정보도 공유해야 진정한...정보의 공유~~~

(홈페이지 망가져서 머리에 김이 나는 판에,
이런 공짜심리가 얼마나 짜증이 날까요. 죄송합니다. -b )

박성호.

익명 사용자의 이미지

아고...일단 문제가 뭐였냐믄...

현재 apache/php/mysql 이 함께 돌아가고 있거든요.
그런데 이중에서 mysql이 말썽을 피운 겁니다.

db에 접속이 일어났다가 필요없게 된 것은 죽어 줘야 하는데
사용하지 않는 프로세스들이 계속해서 떠있다 보니
더이상 접속을 위한 프로세스를 생성하지 못하고
에러를 뿌리게 되는 것이지요.

근본적으로는, apache/php/mysql을 모두 최신버전으로 업그레이드하는
것이 최선이라고 봅니다만, 그렇게 하기에는 기존의 데이터들이나
설정 파일들의 호환성에 문제가 생길 소지가 있기 때문에
(물론 시간을 더 투자해서 정확히 백업받고 튜닝하면 되겠지만)
문제가 되는 mysql의 설정을 조금 바꾼것 뿐입니다.

필요없는 프로세스들이 빨리빨리 죽어 나가도록 하기 위해서
어떤 설정이 필요한지 알아보니 wait_timeout 이라는 파라미터가
있더라구요. 그래서 이놈을 디폴트 값보다 훨씬 작게 주고
mysql을 새로 돌렸더니 조금 상태가 좋아진것 같습니다.

그러나 이것은 어디까지나 임시방편일 뿐 근본적으로는
웹서버와 db서버를 분리하고
자주 접속이 일어나는 부분에 대해서는 캐싱을 해주고
db접속에 대해서 일반적인 cgi 대신에 pcgi나 fast cgi등을
적용하는 방법도 고려해볼 수 있겠지요.
php의 경우 db접속시 mysql_connect 대신 mysql_pconnect를
써서 이미 접속되어 있는 것을 재활용하는 방법도 고려해 주고요.

근데 이게 말이 쉽지....
이런것을 고려하지 않고 이것저것 기능들을 누더기처럼 붙여나가다
보면 결국 언젠가는 이렇게 문제점이 불거져 나오게 마련일 겁니다. -_-;;

일단, 현재 설정으로 접속이 많은 평일 오후에 얼마나 잘 버텨줄지
한번 살펴보고 apache/php/mysql을 갈아 엎을지 다시한번 검토해
보려 합니다.

걱정해 주시는 분들이 많으니 특히 부담이 더하군요.

건드리다가 데이터를 날려 먹지나 않을까 하는 부담....

겨울아이님이 그래도 많이 도와주셔서(저보다 더 자세히 살피고 계십니다)
든든합니다. 문제가 생긴줄도 모르고 가만히 있는데 전화까지 해주시더라구요. -)

박성호 wrote..
라고 말할수 있었으면 좋겠습니다. -)

아파치에 php에 mysql로 홈페이지를 몇개 만들어 준게 있는데요,
사용자가 늘어날 때 어떤 문제가 발생할 수 있는지,
그걸 어떻게 해결할 수 있는지,
실제 사례를 들어 보고 싶군요.

이런 정보도 공유해야 진정한...정보의 공유~~~

(홈페이지 망가져서 머리에 김이 나는 판에,
이런 공짜심리가 얼마나 짜증이 날까요. 죄송합니다. -b )

박성호.

익명 사용자의 이미지

음냐...

이거 공개적으로 칭찬을 해주시다니... 몸둘바를 모르겠군요. ^^;;;;
너무 걱정 및 생각나는대로 순선님에게 시시콜콜
참견을 해서 부담을 느끼시는것은 아닌지..

저도 모험심이 투철하여 새로운거만 나오면 밤새노가다를 해서라도
몽땅 바꾸어버리는 성격인데 순선님은 한술 더뜨시는것 같습니다. ㅎㅎ

일단 제가보기에는 서버가 데비안인것이 좀 부담스럽습니다.
레드햇에 비해서는 문서가 부족하고 경험한 사람들이 적어서
문제 발생시에 적극적인 조언을 받아들이기가 어렵군요.

구서버가 아직도 존재한다면 거기에 레드햇에 아파치 2.0 에
MySQL 3.23alpha 에 PHP 4.0 으로 시험적으로 포팅을 해서
검증을 해보면 좋을것 같습니다. KLDP 사용자들의 도움을 받아서
오버로드도 마구 걸어보구...

그러면 KLDP 여러분들 도와주실거죠?
헤헤... 변명하려다 이야기가 이상한데로 흘렀네요.

여러분도 좋은 의견주시면 순선님이 고민을 조금은 적게 하시겠죠?

- 겨울아이 -

권순선 wrote..
아고...일단 문제가 뭐였냐믄...

현재 apache/php/mysql 이 함께 돌아가고 있거든요.
그런데 이중에서 mysql이 말썽을 피운 겁니다.

db에 접속이 일어났다가 필요없게 된 것은 죽어 줘야 하는데
사용하지 않는 프로세스들이 계속해서 떠있다 보니
더이상 접속을 위한 프로세스를 생성하지 못하고
에러를 뿌리게 되는 것이지요.

근본적으로는, apache/php/mysql을 모두 최신버전으로 업그레이드하는
것이 최선이라고 봅니다만, 그렇게 하기에는 기존의 데이터들이나
설정 파일들의 호환성에 문제가 생길 소지가 있기 때문에
(물론 시간을 더 투자해서 정확히 백업받고 튜닝하면 되겠지만)
문제가 되는 mysql의 설정을 조금 바꾼것 뿐입니다.

필요없는 프로세스들이 빨리빨리 죽어 나가도록 하기 위해서
어떤 설정이 필요한지 알아보니 wait_timeout 이라는 파라미터가
있더라구요. 그래서 이놈을 디폴트 값보다 훨씬 작게 주고
mysql을 새로 돌렸더니 조금 상태가 좋아진것 같습니다.

그러나 이것은 어디까지나 임시방편일 뿐 근본적으로는
웹서버와 db서버를 분리하고
자주 접속이 일어나는 부분에 대해서는 캐싱을 해주고
db접속에 대해서 일반적인 cgi 대신에 pcgi나 fast cgi등을
적용하는 방법도 고려해볼 수 있겠지요.
php의 경우 db접속시 mysql_connect 대신 mysql_pconnect를
써서 이미 접속되어 있는 것을 재활용하는 방법도 고려해 주고요.

근데 이게 말이 쉽지....
이런것을 고려하지 않고 이것저것 기능들을 누더기처럼 붙여나가다
보면 결국 언젠가는 이렇게 문제점이 불거져 나오게 마련일 겁니다. -_-;;

일단, 현재 설정으로 접속이 많은 평일 오후에 얼마나 잘 버텨줄지
한번 살펴보고 apache/php/mysql을 갈아 엎을지 다시한번 검토해
보려 합니다.

걱정해 주시는 분들이 많으니 특히 부담이 더하군요.

건드리다가 데이터를 날려 먹지나 않을까 하는 부담....

겨울아이님이 그래도 많이 도와주셔서(저보다 더 자세히 살피고 계십니다)
든든합니다. 문제가 생긴줄도 모르고 가만히 있는데 전화까지 해주시더라구요. -)


박성호 wrote..
라고 말할수 있었으면 좋겠습니다. -)

아파치에 php에 mysql로 홈페이지를 몇개 만들어 준게 있는데요,
사용자가 늘어날 때 어떤 문제가 발생할 수 있는지,
그걸 어떻게 해결할 수 있는지,
실제 사례를 들어 보고 싶군요.

이런 정보도 공유해야 진정한...정보의 공유~~~

(홈페이지 망가져서 머리에 김이 나는 판에,
이런 공짜심리가 얼마나 짜증이 날까요. 죄송합니다. -b )

박성호.

익명 사용자의 이미지

에구... 투표게시판에 가서 보니
리눅스 배포판이 그렇게 종류가 많던가요?
레드햇 하나만 가지고도 쩔쩔매고 있는데....

서버를 레드햇으로 이야기를 한것은 제가 아는게 그것뿐이라서
였구요. ^^; 서버에 강하다는 배포판을 조사해 봐서 신중한
판단을 내려야 할것 같군요. 큐메일 사이트를 운영하다 보니
FreeBSD 의 파일시스템이 그중 안전하다는 내용도 본것 같은데...

이것도 여러분들 의견 주시지요. -)

- 겨울아이 -

익명 사용자의 이미지

솔직히 배포판이나 OS가 특별히 중요한건 아니지요.
윈도우즈도 튜닝만 잘 하고 관리자가 실력만 있다면야
잘 돌아갈 테고, 리눅스도 잘 모르는 사람이
만지게 되면 서로 고생할 테니까요.

저도 레드햇에 익숙하긴 합니다만, 이번에 데비안으로 전향한 것은
어디까지나 "정치적"인 이유였습니다.

그런데 막상 문제가 불거지고 보니 익숙하지 않은 배포판을
사용하고 있다는 것이 이렇게 약점이 될줄을 몰랐지요. -_-;;;

FreeBSD도...좋다고는 하지만 잘 모르는 사람이 봤을땐 어차피
고생하기 마련이겠지요. 그리고, 다들 서로 자기가 선호하는 OS나
배포판이 있을테니 제생각에 결국은 자기에게 편한 것을 선택하게
될거라고 봅니다. 제 경우에는 이런 측면을 고려하지 않고 데비안이
공개 배보폰이라는 "정치적"인 면에 치중하다 덤터기를 쓴 것 같네요. -)

p.s. 근데 데비안....좋긴 좋습니다.
레드햇과는 또다른 맛이 있지요.

겨울아이 wrote..
에구... 투표게시판에 가서 보니
리눅스 배포판이 그렇게 종류가 많던가요?
레드햇 하나만 가지고도 쩔쩔매고 있는데....

서버를 레드햇으로 이야기를 한것은 제가 아는게 그것뿐이라서
였구요. ^^; 서버에 강하다는 배포판을 조사해 봐서 신중한
판단을 내려야 할것 같군요. 큐메일 사이트를 운영하다 보니
FreeBSD 의 파일시스템이 그중 안전하다는 내용도 본것 같은데...

이것도 여러분들 의견 주시지요. -)

- 겨울아이 -

익명 사용자의 이미지

저도 순선님처럼 "정치적"인 이유로 데비안을 사용하게 되었죠.
처음 데비안 potato 설치하는데 저는 이주 정도 걸린것 같군요.-)
여러 배포판을 사용해 보긴 했지만, 사실 거의 모두 레드햇 기반이기 때문에 특별히 커스터마이징(어떤 분이 이런 용어를 쓰시길래)한 경우가 아니라면 무슨무슨 리눅스하고 구분짓는게 별 의미가 없어 보이더군요. 어차피 모두 리눅스 커널에 GNU 유틸리티 및 많은 공개 소프트웨어로 이루어져 있으니까요.

그래도...
자신에게 꼭 필요한 패키지만 딱 골라서 설치하고 관리하는 데는 데비안이 좋더군요. 물론 저의 경우엔...
한글 사용도 한글판 리눅스보다는 못하지만 다국어를 겨냥한걸 고려한다면 괜찮은 편이고요.
얼마 전에-참고로 전 초보-데비안에서 넷스케이프에서 한글 입력하는 문제로 끙끙 앓다가 한글 패치된 넷스케이프 rpm 패키지를 설치해서 사용한 기억이 나는군요. -)

비약이 심하긴 하지만 레드햇 계열 쓰다가 데비안을 접할 때 들었던 느낌이 예전에 도스/윈도3.1 쓰다가 슬랙웨어를 만났을 때와 비슷했거든요.

다른건 몰라도 TEX 관련 패키지는 데비안이 제일 많이 포함되어 있더군요.

권순선 wrote..
솔직히 배포판이나 OS가 특별히 중요한건 아니지요.
윈도우즈도 튜닝만 잘 하고 관리자가 실력만 있다면야
잘 돌아갈 테고, 리눅스도 잘 모르는 사람이
만지게 되면 서로 고생할 테니까요.

저도 레드햇에 익숙하긴 합니다만, 이번에 데비안으로 전향한 것은
어디까지나 "정치적"인 이유였습니다.

그런데 막상 문제가 불거지고 보니 익숙하지 않은 배포판을
사용하고 있다는 것이 이렇게 약점이 될줄을 몰랐지요. -_-;;;

FreeBSD도...좋다고는 하지만 잘 모르는 사람이 봤을땐 어차피
고생하기 마련이겠지요. 그리고, 다들 서로 자기가 선호하는 OS나
배포판이 있을테니 제생각에 결국은 자기에게 편한 것을 선택하게
될거라고 봅니다. 제 경우에는 이런 측면을 고려하지 않고 데비안이
공개 배보폰이라는 "정치적"인 면에 치중하다 덤터기를 쓴 것 같네요. -)

p.s. 근데 데비안....좋긴 좋습니다.
레드햇과는 또다른 맛이 있지요.


겨울아이 wrote..
에구... 투표게시판에 가서 보니
리눅스 배포판이 그렇게 종류가 많던가요?
레드햇 하나만 가지고도 쩔쩔매고 있는데....

서버를 레드햇으로 이야기를 한것은 제가 아는게 그것뿐이라서
였구요. ^^; 서버에 강하다는 배포판을 조사해 봐서 신중한
판단을 내려야 할것 같군요. 큐메일 사이트를 운영하다 보니
FreeBSD 의 파일시스템이 그중 안전하다는 내용도 본것 같은데...

이것도 여러분들 의견 주시지요. -)

- 겨울아이 -