[leecholho]님이 남기신 글:
>답변 주셔서 감사합니다.
>
>>========================================
>>
>>max_connections 이 500 이상 넘어간 상태에서 빨간색 멘트가
>>나오면(거의 기계적인 멘트이지만) 절대적으로 메모리가 부족한 상황입니다.
>>
>>아마 덩치큰 SQL 이 가동된것도 같습니다. 차후 sql 을 튜닝해 보시고,
>>
>>현재로서는 메모리를 4G 이상을 장착해야 그럭저럭 돌것도 같네요.
>>
>>혹 DB 용량이 많지 않으면(1GB 이내) tmpfs (메모리기반) 에 올려놓고
>>사용해 보는 것도 한가지 방법이 될 수 있습니다.
>>
>>이때는 재부팅되면 데이터가 모두 날라가므로 replications 이 필수적입니다.
>
>========================================
>아, 제가 제목을 잘못 적었군요.. 속도저하가 아니라 리소스 문제인데..
>max_connections이 일반적일때는 그렇게 높지 않습니다. 다만 문제가 생겼을때 쿼리가 밀리다보니 저렇게 높아진건데요. 첨에 설정할때에도 많아야 3~400개 아닐까(진짜로 많을때)하고 그냥 크게 잡아 놓은건데요..
>문제가 생겼을때의 쿼리를 보면은 Copying to tmp table,Sending data상태가 대부분이고 이것들을 처리를 못해서 밀리는도중에 update쿼리나 insert쿼리가 오다보니 그 관련된 쿼리들이 다 락이 걸립니다.
>웹에서의 커넥션을 차단하지 않으면은 풀리지 않은 상황입니다.
>
웹서버에서 붙는 커넥션이 대부분이라면 wait_timeout 반드시 튜닝해
주세요. 웹서버라면 slow query 확인하고 그것에 준하는 값을 정하면
될것 같습니다. 또는 CRITICAL_LIFE_TIME 도 참고하시고..
>그래서 mysql의 옵션에 문제가 있는가 싶어서 질문을 드린건데 첨부터 자세히 썼어야 했는데 죄송합니다...
>DB크기는 데이터는 1.8기가 정도에 인덱스가 1.3기가 정도입니다.
>
tmpfs 로 올리기에는 좀 크군요. ㅠㅠ
>그리고 덩치큰 SQL 이 가동된것 같다고 하셨는데요, slow query의 로그를 보면서15초 이내의 쿼리들은 전부 처리했거든요.. 쿼리 이외에 다른게 문제가 될만한 것은 없는지 알고 싶습니다.(네트웍이라던지 옵션 설정값이라던지)
>
덩치큰 SQL 은 속도가 아닌 메모리를 많이 잡아 먹은 쿼리를 의미합니다.
ORDER BY 나 GROUP BY 또는 WHERE 절 없이 전체를 full-join 하는 쿼리가
많은지에 대해서도 SQL 튜닝(분석)이 요구되어야 합니다(웹호스팅용이라 아니라면).
>
>ps) key_buffer_size + (record_buffer + sort_buffer) * max_connections = available of memory
>여기에서 record_buffer가 옵션에는 없어서 한참 찾아봤더니 4.0버전에서read_buffer_size 로 바뀌었던데..
ㅎㅎ
======================================== |
sun's longitude:242 14 59.04
/board/delete.php:소스보기 
