>

> 안녕하세요, 송재호입니다.

>

>

> 서버를 운영하고 있는 데, 부하가 걸려서요. 서버를 여러분 재 부팅했었습니다.

>

> 아래의 두 파일에 대해서 궁금합니다.

> yhost.log 라는 것인데 아래와 같이 제법 덩치가 크죠?

> 이 로그 파일은 yhost 라는 컴퓨터의 DB 서버에서 이루어지는 전체 DB 파일에

> 대한 로그인 것으로 알 고 있는 데.... 그렇다면 필요가 없을 것 같은 데...

> 삭제대로 별 상관없나요?

> mysqld 를 실행할 때 그런 옵션이 있긴한데... 그 옵션을 주면 이 파일이 생기

> 죠? (사실 아래에 보시면 제가 safe_mysqld -l 과 같이 옵션을 주었습니다.

> 디폴트 디렉토리(설치된 디렉토리)에 생기는 것이 정상이겠죠? 그냥 싹 지워도

> 될까요?)

>

> 그리고 yhost.co.kr.err 의 내용을 보니 .. 에러에 관한 별 내용이 없더군요.

> -rw-r--r-- 1 root root 2576 Apr 18 22:30 yhost.co.kr.err

> -rw-rw---- 1 root root 527551599 Apr 18 23:06 yhost.log

-l 옵션이 아마 모든 sql문이 기록되는 것이지요? 그러니깐 저렇게 커지겠지요.

그런데 로그를 기록하면 이걸 가지고 백업에 이용할 수 있습니다.

그러므로 가능하면 보관할 것을 추천합니다.

저도 모든 로그를 기록하지요.

문제는 이 파일이 너무 커지는 것이지요.

이때문에 생기는 부하도 클 듯합니다.

이걸 적절한 주기마다 로그를 로테이션하여 처리하면 될 듯 합니다.

크기를 보아서 일주일 또는 매일 또는 한달마다.

이것만 해도 성능개선에 도움될듯.

에러로그야 당연히 두어야지요. 그래야 문제가 생겼으때 볼 수 있구요.

>

> 음, ... 그리고... 질문이 더 있는 데, ... 죄송.

> MySQL 쓰레드는 ... 커넥션이 이루어질 때 그 하나를 말하나요?

> 아니면 질의를 한 번 때를 말하나요?

http://linux.kreonet.re.kr/mysql/Manual_chapter/manual_Introduction.html#Features

Fully multi-threaded using kernel threads. That means it easily can use multiple CPUs if available

매뉴얼에 위 내용이 있지요. 저도 프로그래밍에 대해서는 잘 몰라서 정확히 이해는 안 가는데요.

여러개의 CPU를 잘 활용할 수 있다는 의미가 있을듯.

이것말고 사용자가 서버에서 특정 쓰레드를 얻어 다른 사용자와 동시에 동일 테이블에 접근할 수 있다는 내용도 있지요.

쩝. 저도 정확한 개념을 못잡고 있음. 아뭏든 좋다니깐~~

>

>

>

> 그리고, 조언을 좀 부탁드립니다.

> P-II, 64M, IDE HDD 에서 MySQL 서버와 웹서버, 그리고 PHP 를 운용하고 있는 데,

> ..., 접속자수가 좀 많습니다.

> 그리고 MySQL 서버 액세스도 엄청나구요.

> 짧게 짧게 접속 해서... 지속적으로 많이 MySQL 을 액세스합니다.

> 이 때 MySQL 데몬 실행시 별도의 옵션을 주면 ... 반응이 빠르거나 부하가 좀 적

> 게 걸리는 그런 옵션은 없습니까?

> 이전에는 이렇게 옵션을 주었는 데... 좀 ... 액세스를 많이하니 속도가 느리더군요.

>

> (cd /usr/local/mysql; ./bin/safe_mysqld -l -O max_allowed_packet=10M &)

>

> 물론.. .. 부하가 ... MySQL 데몬에서 걸리는지는 정확히 체크를 못했습니다만,

> 의심이 가는 부분이 MySQL 데몬이더군요.

>

>

>

> 이번에는 위의 옵션을 아래와 같이 바꾸어 주었습니다.

>

> (cd /usr/local/mysql; ./bin/safe_mysqld -O back_log=50 &)

먼저 찾아야할것이 어디에서 부하가 걸리느냐입니다.

이걸 먼저 찾아야지요. ps, vmstat 등 여러가지 툴을 이용해서 먼저 어디에서 부하가 걸리는지 찾아야지요. CPU에 문제? 메모리? 디스크 I/O? 가장 좋은건 메모리를 늘리는 것이겠지만요. 근데 이게 그리 쉬운 문제는 아닌것같지요? accounting 프로그램을 이용 각 프로그램의 부하를 계산하는 것도 한가지 방법이라고 생각되네요.

CPU 많이 쓰는 놈, I/O 많이 쓰는 놈, 메모리 많이 쓰는 놈.(일반적으로 I/O 와 메모리는 밀접한 관계를 맺겠지요) 그러고나서 이제 그 문제를 해결할 수 있겠지요.

mysqladmin -u root -p xxxx processlist | grep -v "" | grep -v "db" | grep -v "process" | wc

또는

ps aux | grep mysql | grep -v grep | wc

이렇게해서 mysql에 평소에 얼마나 동시에 접속하는지도 주기적으로 검사하구요.

(아래것을 쓰는게 좋겠지요. 비밀번호를 칠 필요없으니)

현재 64M 메모리는 서비스 규모가 커지면 부족할듯 합니다. HDD도 스카시로 변경을 하는게 좋겠지요.

가장 쉬운 방법은 DB서버와 웹서버 분리가 아닐까요? 성능좋은걸 DB 서버로 쓰고 삐리한걸 웹으로 쓰구요.

mysql 옵션은 접속패턴에 따라 바꾸어야지요. 그건 옵션을 참고로 해서 보시구 무엇을 바꾸는게 효율적일까 생각해서 설정 바꾸고 점검하는 방법밖에 없을듯.

짧게 여러번 접근하고 SQL문에 간단하다면 예를 들어 PHP에서 Persistenet Connection 갈은 것 쓸 필요없을것 같구요. 접속을 붙잡고 있으니깐요. timeout 시간도 줄여주시구요. (이것도 쓸데없이 접속을 붙잡는것 방지, 근데 5초이상 timeout이 넘어간다면... 이는 문제있는거죠)

버퍼(메모리)를 select 문에 많이 할당해주고요.

지금 위에서 옵션설정은 그다지 성능에 도움이 되지 않을듯.

-back_log

mysql이 가질 수 있는 최대 연결 요청의 수. 이것은 main mysql 스레드가 매우 짧은 시간동안 매우 많은 연결 요청을 받을 때 기능을 한다. 이때 메인 스레드가 연결을 체크하고 새로운 스레드를 시작하는데는 약간의 시간이 걸린다.(그러나 아주 짧은 시간임) back_log 값은 mysql이 순간적으로 새로운 요청에 답하는 것을 멈추기전에 이 짧은 시간동안 얼마나 많은 요청을 쌓아두고 있는지를 지정한다. 매우 짧은 시간동안 매우 많은 연결이 예상될때만 이 값을 증가시켜야 한다.

다른 말로 이 값은 tcp/ip 연결을 받는 listen queue의 크기이다. 각 운영체제마다 이러한 큐의 크기에 한계가 있다. Unix system call listen(2) 매뉴얼페이지에 자세한 정보가 있다. back_log값의 한계는 운영체제 문서를 확인해봐라. back_log를 최대값보다 더 높여도 효과가 없다.

(제가 번역한 매뉴얼 중)

-max_allowed_packet

한 패킷의 최대 크기. 메시지 버퍼는 net_buffer_length 바이트로 초기화되지만 필요하면 최대 허용 패킷 바이트를 증가시킬 수 있다.기본값은 큰 패킷을 잡기에는 작다. 거대 BLOB 컬럼을 사용한다면 값을 증가시켜야 한다. 사용자가 원하는 최대 blob만큼 크게 해야 한다.

join 버퍼나 순차 검색, 키버퍼, 정렬 버퍼등 적당한 것을 늘려주는게 효율적일듯합니다.

http://www.taejun.pe.kr/mysql/manual/10.txt

10. mysql의 최대 성능 향상 방법

이걸 참고하세요.

여기에 추가하면 프로그래밍 자체를 더 효율적으로 짜는것도 중요하죠.

SQL문 최적화. 동적인 파일을 가능한 줄이고 정적으로 만들기(일반 질문답같은 게시판이야 어쩔 수 없지만요) 등등.

웹서버차원에서의 최적화도 하구요.

여유돈이 있다면 시스템을 빠방하게 하는게 최고일듯~~