Extra Form
PHP PHP 7.3
CMS WordPress

안녕하세요.

 

늘 XE 게시판에서 많은 도움을 받고 있습니다. 감사합니다.

 

MYSQL의 설정 값에 관해 몇가지 궁금한 점이 있습니다.

 

1) 만약 my.cnf에 있는 값을 # 처리하게 되면 해당 값은 off로 설정되는 건가요? 아니면 mariadb의 초기값으로 자동으로 설정 되는건가요?

 

2) innodb_buffer_pool_size를 서버 전체 램의 50~70%로 설정하는 걸 권장하는 게시글을 매우 많이 보았습니다. 

그런데 많이 설정한다고 좋은건 아니라는 것도 보았습니다. 많다가는 스왑? 이 발생할 수 있다는걸 보았는데요..

 

실제 innodb의 사용량은 200 ~ 300m 정도의 경우에도 사이즈를 1~2기가 설정해도 괜찮은건가요?

 

3) 설정을 바꾼 후에 어떻게 테스트를 해봐야 되는지 모르겠습니다.. 이게 설정이 빨라진건지, 오히려 느려진건지, 효과가 있는건지 없는건지 전혀 구분을 할 수가 없습니다 ㅠㅠ

 

webpagetest 나 Pingdom 을 이용해 홈페이지 속도를 테스트해봐도 거의 미미한 차이라 오차로 봐도 될 정도구요... 슬로우 쿼리나 로그 등을 봐도 오류로 남겨진게 없으니 어디를 개선해야 될지 모르겠습니다.

 

혹시 측정해볼 수 있는 방법이 있다면 알고 싶습니다.

 

읽어주셔서 감사합니다.

  • profile

    1. 초기값이요.

     

    2. MySQL 외에는 특별히 돌아가는 것이 없는 서버라면 거의 모든 램을 MySQL에 할당해줘도 됩니다. 50~70%, 많게는 80%까지 권장하기도 하는데 모두 MySQL 단독으로 쓰는 서버라는 가정하에 얘기하는 거고요... 아파치도 돌아가고 PHP도 돌아가는 서버라면 당연히 램을 더 많이 남겨놓아야 합니다.

     

    단, 스왑이 발생하는 것만으로 문제가 되지는 않습니다. 램이 펑펑 남아도는 서버에서도 스왑 사용량이 은근히 꽤 나올 때가 있어요. 이건 그냥 리눅스 커널이 알아서 하는 겁니다. 억지로 스왑을 안 쓰도록 하면 오히려 성능이 나빠지니 너무 신경쓰지는 마시기 바랍니다. 제가 관리를 대행하고 있는 서버 중 하나를 방금 확인해 보니 램 192기가 중 70기가 이상 남아 있는데도 스왑을 무려 8기가나 쓰고 있네요. 얘가 원래 좀 이래요. ㅎㅎ

     

    3. 체감성능 차이도 없고 벤치마크 차이도 없다면 현 상태에서 더 튜닝하는 것은 의미가 없습니다. 그냥 남들이 권장하는 적당한 수준으로 해놓고, DB 용량이 많아지거나 접속자가 늘어나서 좀 불편이 느껴지면 그 때 다시 뜯어보시면 됩니다.

     

    서버 튜닝이라고 하는 것의 절반 이상은 속도를 빠르게 하는 것이 아니라 더 많은 접속자를 동시에 처리할 수 있도록 하는 효과가 있습니다. 접속자가 1명일 때는 웬만하면 다 빨라요. 100명이 들어오고 1000명이 들어와도 그 컨디션을 유지할 수 있도록 해주는 것이 튜닝이예요. 심지어 1명 기준으로는 오히려 더 느려질 수도 있습니다.

  • profile ?

    안녕하세요 기진곰님.

     

    늘 좋은 답변 정말 감사합니다. 

     

    그렇군요! 제가 MYSQL의 튜닝에 관해 처음부터 잘못 이해하고 있었던 것 같습니다.

     

    저는 웹사이트의 속도를 빠르게 하기 위해 MYSQL의 튜닝이 필요하다고 생각했는데, 실제로는 속도보다 동접자가 늘어나더라도 웹사이트의 속도를 일관되게 유지하게 해주는 작업이라고 생각하면 되겠네요

     

    좋은 정보 정말 감사합니다. 

     

    그럼 실제로 웹사이트의 속도에 영향을 미치는 건 PHP나 NGINX나 , 각종 캐쉬 등 서버에서의 설정보다 웹사이트서 현재 사용하는 JS, CSS의 Minify나 CDN, 이미지나 쿼리 등의 최적화가 더 중요하다고 생각해도 될까요?

     

    감사합니다.

     

  • ? profile

    아, 물론 1명이 접속했을 때도 느린 것이 느껴졌다면 그것부터 고치는 것이 급선무였겠지요. 그러나 일단 1명이 접속했을 때 충분히 빠른 상태가 되었다면 그 다음부터는 동접수의 문제가 됩니다.

    CSS, JS minify 효과는 벤치마크상에나 나타날 뿐, nginx에서 expires를 사용하여 제대로 캐싱해 주고 있다면 체감속도에 미치는 영향은 제로입니다. 오히려 처음 접속했을 때 일일이 압축해 주느라 한참 느려질 수 있습니다. 라이믹스 기준으로 압축보다는 합치기 기능이 더 큰 효과를 내지만, 이것도 처음 접속했을 때 외에는 아주 큰 차이가 나지는 않습니다. CDN의 경우, 일반적으로 사용하는 클플 같은 곳은 눈에 띄게 느려집니다. 이건 트래픽 절약을 위해 사용하는 것이지, 성능면에서는 오히려 역효과예요. (미국에서 유행하는 성능개선 팁 중 절반은 한국에서 해당사항이 없고, 나머지 절반은 오히려 느려질 가능성이 높습니다. 웬만하면 무시하는 것이 상책입니다.)

    신기술을 대량으로 동원해서 아주 약간의 성능 개선 효과를 얻는 것보다는, 사용하시는 레이아웃이나 애드온, 위젯에서 성능을 왕창 깎아먹는 것이 없는지 확인해 보시는 것이 100배는 더 효과적일 거예요. 레이아웃 하나 잘못 썼다가 불필요한 해외 CDN 연동, 웹폰트 로딩 때문에 초기 접속 속도가 몇 초씩 느려지기도 합니다. 애드온 함부로 쓰면 불필요한 쿼리가 수십 개씩 발생할 수도 있습니다. 최신글, 인기글 등을 나열하는 위젯들 중 과반수는 XE 특유의 쿼리 구조와 맞물려서 불필요한 COUNT(*) 쿼리를 유발하는가 하면, 반대로 갯수만 세면 되는데 내용까지 죄다 로딩하는 등 황당한 방식으로 구현되어 있는 것도 은근히 자주 봅니다. 특히 좀 오래된 자료들이 많이 그렇습니다. 동접수가 적을 때는 멀쩡하다가 몇백 명 들어오면 갑자기 기하급수적으로 느려지는 시한폭탄도 있습니다.

  • profile ?
    기진곰님. 다시한번 친절한 설명 정말 정말 감사합니다.

    알려주신 내용이 큰 도움 되었습니다.

    정말 죄송합니다만 마지막에 알려주신 쿼리에 관해 조금 더 여쭙고 싶습니다.

    제 웹사이트를 확인해보니 쿼리가 50개 ~ 200개 정도 실행되는걸 보았습니다.

    발생하는 쿼리를 본 결과 하나 하나의 속도는 Query_time: 0.000131 Lock_time: 0.000042 정도 입니다.

    이 정도 수준의 쿼리가 약 50개정도 발생한다면 0.0000131 X 50 으로 생각하고 수정하면 될까요?

    아니면 그저 무시해도 될만한 문제인지, Query_time이 낮은게 대량으로 발생하더라도 성능에 큰 영향을 끼치는 지 알고싶습니다.

    늘 도와주셔서 정말 감사합니다.
  • ? profile
    RXE 쪽에서 소요되는 시간은 DB 쪽에서 측정한 시간보다 훨씬 길 수도 있습니다. 쿼리 정보를 정리하는 시간, 쓸데없이 많은 데이터를 전송받아서 정리하는 데 드는 시간 등... 디버그 기능을 사용하면 총 소요시간을 좀더 정확하게 알 수 있습니다. 관리자 화면이 아니라 일반 유저에게 보여줘야 하는 메인화면이나 게시판 화면에서 수십~수백 개의 쿼리가 발생한다면 바람직하지 않습니다.
  • profile ?
    기진곰님. 답변 감사합니다.

    오랫동안 혼자 고민해왔던 문제가 최근 몇일사이 기진곰님께서 알려주신 내용을 들으니 어느정도 감이 잡히고 이제야 제가 뭘 해야될 지 알 것 같습니다.

    늘 친절하고 자세하게 설명해주셔서 정말 정말 감사합니다.