안녕하십니까. 좋은아빠되기입니다.

 

조금 한가해지니깐. 별 걱정을 또하게 되는거 같습니다.

 

전문가분께 msyql 메모리 4G 할당 요청을 했고

 

실제로 4G가 할당되어 있는것 까지 확인했는데요.


default_storage_engine          = InnoDB
innodb_buffer_pool_size         = 4G
innodb_log_file_size            = 1G
innodb_log_buffer_size          = 128M
 

이렇게 설정되어 있습니다.

 

mysql 백업하면 1G 정도 의 DB량입니다.

 

 

서버 부팅하고 일주일 정도 지나면 2G 가까이 사용하던게.

 

점점 시간이 지나면서 3G 가까이 쓰더라구요.

 

근데.. optimize를 하고 나니깐..

 

4G 정도 쓰던데

 

한 45일 지나서 다시 optimize 하니깐...

 

top.png

 

그림에 보시는것처럼 6G를 사용하네요.. ㅎㅎㅎ

 

msyql restart 하면 확 줄고 처음부터 다시 시작하겠지만..

 

재부팅 일체없이 6개월 이상 버티는게 목표인데...

 

저대로 둬도 별문제 없는건가요?

 

optimize 한번 더하면 더 많이 메모리 먹나요?

 

4G로 할당해뒀는데.. 왜 자꾸 메모리를 많이 먹어서 사람 겁먹게 하는건지 모르겠네요.

 

조언 부탁 드립니다.

  • profile

    innodb_buffer_pool_size + 1~2G 정도는 정상입니다. 바로 밑에 나오는 로그 버퍼를 비롯해서, 쿼리 캐시나 MyISAM key buffer 등 RAM을 사용하는 다른 기능도 많으니까요. RAM이 정말 부족한 서버라면 이것까지 감안해서 버퍼 크기를 지정해야 하고요.

     

    무한정 늘어나기만 한다면 문제가 있는 거지만, 대개 며칠에 걸쳐 최대치까지 올라간 후 그 상태를 꾸준히 유지합니다. 메모리 16G짜리 서버에 APM만 돌린다면 MySQL이 40~50% 정도 쓰는 것은 괜찮아요.

  • profile ?
    역시나 전문가님께서 댓글 주셨네요. ㅎㅎㅎ
    추정은 하고 있으나 확신이 없어서 맨날 물어보기만 하게 되네요 ㅎㅎㅎ
    그럼... 아무리 optimize 해도.. 8G만 크게 넘지 않으면 문제 없다는 거군요. ㅎㅎㅎ
    optimize 방금 했는데..
    괜시리 한번 더해보고 싶어지네요 ㅎㅎ
    꾸~~~욱 참았다가 다음에 해야겠습니다. ㅎㅎㅎ
    도움 감사합니다.
  • ? profile

    그거 너무 자주 하실 필요 없어요. MyISAM의 optimize는 파일의 빈 공간을 제거하는 기능이지만, InnoDB는 테이블을 통째로 복사하고 기존 테이블을 삭제하는 방식으로 진행합니다. 용량이 크다면 SSD에 무리도 많이 가고, 작업 도중에는 조회수 증가 등 기본적인 쿼리도 모두 중단되기 때문에 사이트에 영향을 많이 줍니다.

  • profile ?
    보통 30일에 1회정도 생각하고 있습니다...
    혹시 추천하는 일수 있으시면 알려 주시면 시행하도록 하겠습니다. ㅎㅎㅎ
  • ? profile
    특별히 정해진 주기는 없고, 그동안 쌓인 글 수에 비해 DB 용량이 너무 커진다 싶으면 (예: 글 수는 저번보다 1.2배 정도밖에 안 늘었는데 xe_documents 테이블 용량이 2.5배로 커졌다거나) 한번씩 해주시면 됩니다. 대부분의 사이트는 1년에 한 번도 안 해도 됩니다.
  • profile ?

    대부분의 사이트에 제 사이트도 들어가는거 같습니다.
    방문자가 많은것도 아니고.... ㅎㅎㅎ
    매년 음력 1월 1일 설날쯤에 한번 해주고..
    서버 재부팅도 한번해주고.. 그러면 될꺼 같네요. ㅎㅎㅎ

    (설날은 저희 사이트 방문자수가 거의 없거든요 ㅎㅎ)
    조언 감사합니다.

  • profile

    일반적인 통념과 달리, 서버의 RAM은 최대한 많이 쓰는 (free가 적은) 것이 좋은 것입니다. DB와 어플리케이션이 쓰지 않는다면 리눅스 자체에서 버퍼/캐시(buff/cache) 용도로 다 끌어다 써버립니다. 물론 너무 많이 써서 스왑으로 넘친다면 문제가 있는 거지만, 안 쓰는 RAM은 서버에 전혀 도움도 안 되면서 전기만 잡아먹을 뿐이예요.

     

    따라서 RAM을 많이 쓰는 것이 문제가 아니라 어디에 얼마나 쓰고 있는지가 더 중요합니다. 일반적인 APM 서버라면 DB와 어플리케이션을 합쳐서 40~70% 사이, 버퍼/캐시가 나머지를 거의 다 쓰는 것이 적당합니다.

  • profile ?
    제 서버 스왑이 야금 야금 올라오기 시작하고 있는데요...
    예전서버는 한번 스왑수치가 가령 125k 이정도 정해지면 서버 다운될때까지 그대로 있던데..
    이번 서버는.. 점점점 조금씩 올라가네요..
    어느 순간 스왑이 확 넘칠까 걱정도 조금되고 그러네요..
    이 부분도 시간되시면 조언좀 부탁 드려요.
  • ? profile

    일시적인 DB 작업 때문에 DB의 실제 용량보다 MySQL에서 붙잡고 있는 RAM이 훨씬 많은 상황이지요. 그러면 리눅스 커널에서 "너는 이제 필요하지도 않은 RAM을 뭐 그렇게 많이 붙잡고 있냐? 나 버퍼/캐시 더 쓰고 싶으니까 좀 내놔라"라면서 사용 빈도가 낮은 부분부터 스왑으로 강제 이동시킵니다. RAM이 전혀 부족하지 않아도 커널이 더 쓰고 싶어서 치워놓는 거죠. 커널에서 치우라는데 MySQL이 반항할 수 있을 리가...

    보기 싫으면 이 기능을 끌 수도 있지만, 미관상(?)의 차이일 뿐 서버 안정성에는 영향을 주지 않습니다. 심지어 RAM이 펑펑 남아도는데 스왑만 꽉 채우고 있는 경우도 있어요. 놀랍게도 그 상태 그대로 두는 게 오히려 더 빠릅니다. 리눅스 커널의 심오하신 뜻에 일개 중생들이 감히 토를 달면 안됩니다 ㅋㅋㅋ

  • profile ?
    제가 인터넷에서 주워 들은건 많아서..이것도 대충 대충 알고 있었는데..
    명쾌한 답변 감사합니다.

    xetown도 인터넷인데...
    기진곰님 말씀은 항상 무조건 신뢰가 가네요 ㅎㅎㅎ
    조언 감사합니다.