2틀 전부터 사이트 접속 속도가 엄청나게 느려졌다가 정상적으로 됐다가 비정상적인 모습이 보였습니다.

그러다가 어제 23일 접속하는데만 10초가량 걸렸습니다.

 

처음에는 접속자가 몰려서 그런가? 하고 상황파악을 하고 있었습니다.

(일 접속자 5천 이상, 동시 접속자(봇포함) 50이상)

 

AWS 라이트세일에 접속해서 CPU를 보는데 부하가 엄청나게 심하더군요.

AWS 서비스는 CPU가 창렬이라는 얘기를 들은 적이 있어서 그것 때문에 그런지 질문도 남겼었죠.

 

https://xetown.com/questions/1513846

 

서버 이전을 고려하던 중 오토씽님 도움을 받아 일 접속자 파악하기 위해 켰던 인증DB세션을 끄고 DB엔진 MyISAM을 InnoDB로 변경하는 작업까지 완료하였으나, 잠깐 빨라지고 다시 느려지는 현상이 지속적으로 발생하였습니다.

 

람보님께서 서버이전보단 내부적으로 뭐가 문제인지 파악하는게 우선이라며, 기진곰님께 서버점검 의뢰를 추천해주셨습니다.

최종적으로 기진곰님께서 서버점검 및 튜닝(서비스)까지 해주셔서 지금은 안정화를 찾은 상태입니다.

캡처.JPG

캡처1.JPG

CPU버스트 용량도 천천히 쌓이고 있습니다.

 

CPU 부하가 심했던 이유는 의외인곳에 있었습니다.

 

1. 전체공지 애드온

- 잘못 작성된 쿼리로 인해 CPU 과부하 발생

- 기진곰님께서 쿼리수정 해주셔서 정상작동 됨

https://xe1.xpressengine.com/?mid=download&package_srl=22753508

 

2. 모바일 작성 표시 애드온

- 화면에 뭘 표시하지도 않으면서 페이지마다 2~3초씩 지연 시킴

- 애드온을 끄고 사용 안하는 걸로 해결함

https://xetown.com/index.php?mid=point_contents&search_keyword=%EB%AA%A8%EB%B0%94%EC%9D%BC&search_target=title&document_srl=22126

 

3. 라이믹스 캐시 방식 변경

- PHP에 apc 확장모듈을 설치

- 라이믹스 캐시 방식을 file에서 apc로 변경

 

위 2개의 애드온을 사용중이신분들은 사용을 고려해봐야 할 것 같습니다.

 

처음 사이트를 운영할때 접속자가 별로 없으니 좋을 것 같은 모듈, 애드온 등을 덕지덕지 붙여서 사용을 했었습니다.

접속자가 별로 없으니 아무런 문제가 없었으나, 사이트가 성장함에 따라 서버에 부하도 커지고 있었던 겁니다.

 

이번 일을 계기로 모듈, 애드온은 꼭 필요한 것과 있으면 좋은 것을 제대로 구분하기로 마음 먹었습니다.

 

+

도움주신 오토씽님, 람보님, 기진곰님 감사드립니다.

  • profile
    저는 여기서 한가지 의문점이 있습니다.
    전체공지 애드온 비슷한 동접에서 많이들 사용하고 합니다. 그런데 문제가 발생하지는 않는 정도인데요.
    운영하시는 사이트도 갑자기 동접이 엄청 늘어난 것도 아닙니다.

    그럼 제가 생각하는 의문은 지금 생각하시는 동접외 엄청난 접속이 어딘가에서 일어나고 있는게 아닌가 하는 의심입니다.

    그래서 다른 곳보다 더 심한 부작용이 나타난건 아닌지.. 물론 기진곰님께서 이상 접속이 있는지는 봐주셨을 것 같아서 의문점이라고 표현했습니다.

    특히 공지게시판의 조회수를 보면 이상할 정도로 조회수가 높은 이유가 뭘까 궁금해지고요. 물론 의도적으로 거기만 뻥튀기 해 놓으신게 아니라면요....
  • profile profile
    기진곰님께서 이상 접속도 봐주셨습니다.
    구글봇이 어마어마하게 들락거린다고 하더군요.

    구글봇도 영향을 미치긴 했겠지만, 위 3가지 조치 후 안정화를 찾았습니다.
    그래서 구글봇은 그냥 놔두기로 했습니다.

    잡다한 크롤러들도 다 차단해주셨습니다.
    조회수는 중복이 가능해서 뻥튀기 된 겁니다.
  • profile profile
    아.. 조회수는 실제가 아니군요. 구글봇 정도 감당이 안되면 그건 문제가 있긴 하죠. 그런데 이상하긴 하네요. 그정도로 CPU가 성능이 안좋다는건지... 보통 다른 VPS는 해당 자료 사용으로 문제가 될 정도는 아니니까요.
  • profile profile
    기진곰님께서 말씀해주시기로 AWS CPU가 안 좋다고 해도, 잘못 만들어진 애드온 + 크롤러의 콜라보가 아니면 동접 수십 명 수준에서 문제가 생길 만큼 만만한 사양은 아니라고 합니다.

    다른 곳과 비교 했을때 안좋을 순 있겠지만 제가 사용하기엔 나쁘진 않아보입니다.
  • profile profile

    네. 당연하구요. 제가 보기엔 잘못 만들어진 애드온 + 크롤러의 콜라보 의 문제로 문제가 될 정도의 엉망인가 해서요. 말씀하신 잘못 만들어진 애드온 + 크롤러의 콜라보 는 저희서버 말고도 라이믹스 XE 사이트에서 흔하게 지금 일어나고 있거든요. 전체공지 애드온만 예를 든다면요.

    서버의 파일캐시가 약해서 더 문제가 된게 아닌지 하는 생각이 들어서요.

  • profile profile
    프로파일링할경우 해당 부분에서 로딩시간이 길다면 그 애드온이 문제인거죠 ㅎㅎ 그런 동작 하나하나 모여서 cu점유율을 차지하는것이니까요.

    서버마다 설정한 값에 따라 애드온이 내부적으로 어떻게 돌아가는지 본다면 그게 문제가 될수도 아닐수도 잇는거죠.

    근데 결과론적으로 문제가 발생되니 그 부분을 먼저 우선 잡고 시작한거죠 ㅎㅎ
  • profile profile
    네. 당연히 문제가 되는 것을 잡고 가는건 맞는데 작성해주신 내용에 애드온의 잘못된 쿼리 보다는 서버 설정에 문제가 있어서 잘못된 쿼리의 영향이 너무 크게 가해진가 아닌가 해서요.(실제적으로는 서버문제)

    기본적은 서버에서 apc 캐시 설정 조차도 안되어 있는 상태라서 이런 생각을 가진거구요.
    지금 상태에서 애드온을 다시 예날 쿼리도 돌려도 문제가 안생길 가능성이 높지 않냐 하는 의견입니다. 왜냐면 다른 비슷한 서버에서 해당 자료를 기존부터 지금까지 많이 쓰고 있잖아요.

    뭐 전체적으로 점검해 주신분 께서 정확하게 아시겠지만 지금 공개해주신 정보를 바탕으로 제 추측이나 의견을 적은 것입니다.
  • profile profile
    제가 전문가가 아니다 보니 문제가 되었던 1,2,3번 중 각각 몇%씩 서버부하에 영향을 미쳤는지는 알 수 없습니다. 웹지기님 댓글을 보니 apc캐시 설정이 70% 이상 영향을 미쳤을 수도 있겠단 생각이 드네요.

    하지만 위 2개의 애드온이 문제가 있다면 수정이 되어야 할 것 같습니다.
  • profile
    그리고 전체공지 게시판의 잘못된 부분 수정할 내용이 공개되었으면 좋겠네요.
  • profile profile
    잘못 된 부분 수정은 기진곰님께서 서비스로 해주신거라 저는 어디를 수정했는지 알지를 못합니다. ㅠ_ㅠ
    아마 이 글을 보신다면 기진곰님께서 답변을 주시지 않을까 생각 됩니다.
  • profile profile

    추출 갯수 기본값이 2000개로 되어 있습니다. 쿼리할 때 LIMIT 2000; 이 들어가요. 그런데 현실적으로 대부분의 사이트는 전체공지가 10개도 안 되죠. 실제 추출하는 갯수와 쿼리에서 요구하는 갯수의 간극이 이렇게 크면 어느 순간 MySQL 쿼리 옵티마이저가 "쳇! 삐뚤어질 테야!" 라고 가출선언을 해 버립니다. 온 동네를 다 둘러봐도 작대기라고는 3개밖에 없는데, 매일 2000개씩 물어오라고 시키면 댕댕이가 얼마나 자괴감에 시달리겠어요...ㅠㅠ 그러면 PK로 검색하는 쿼리임에도 불구하고 엉뚱한 인덱스를 타게 되어 속도가 수백 배 느려집니다. 모든 사이트에서 항상 그런 것은 아니고, 서버 부하 수준과 게시판 접근 패턴에 따라 어느 순간 갑자기 삐뚤어집니다.

    공지글은 페이징도 필요없으므로, 애드온 소스와 XML 쿼리 파일 양쪽에서 list_count, page_count, page 변수를 모두 삭제 또는 주석처리해 주니 성능이 정상으로 돌아왔습니다.

    MySQL 쿼리 옵티마이저는 무척 까칠한 녀석이예요. 상식적으로 인덱스만 걸어 놓으면 쿼리가 빨라질 것 같지만, 현실은 훨씬 복잡합니다. 최근에도 깃허브에서 인덱스 성능과 관련된 논의가 오간 적이 있으니, 모듈 개발자 등 관심있는 분들은 참고하시면 좋겠습니다. https://github.com/rhymix/rhymix/pull/1560

  • profile profile

    <navigation>
    <index var="sort_index" default="list_order" order="order_type" />
    <list_count var="list_count" default="2000" />
    <page_count var="page_count" default="10" />
    <page var="page" default="1" />
    </navigation>

    위 내용중


    <list_count var="list_count" default="2000" />
    <page_count var="page_count" default="10" />
    <page var="page" default="1" />


    이부분을 지우면 될까요?

     

    어 근데 list_count 는 몇개의 공지를 띄울지 설정에서 필요한거 아닌가요?

  • profile profile
    넵.
  • profile profile
    어 근데 list_count 는 몇개의 공지를 띄울지 설정에서 필요한거 아닌가요?
  • profile profile
    전체공지 갯수가 너무 많아서 제한할 필요가 있다면 적당한 숫자를 써넣으셔야겠지요.
    2000개는 너무 비현실적이니까요.
  • profile profile
    네. 그럼 애드온 설정에서 적당한 숫자를 넣으면 될것 같고 2000이라는 숫자를 변경해야 하는 거겠네요.
  • profile profile
    정보 공유해주셔서 감사합니다
  • profile
    역시.. 점검 받으면 깔끔하게 해결되죠 :)
  • profile

    최근 구글봇이 특정 사이트를 갑자기 왕창 긁어가는 일이 자주 발생하고 있습니다. 평소 긁어가던 것은 다 까먹은 건지...? 평소 동접수가 상당히 많은 중대형 사이트에서도 부하 상승이 눈에 띌 정도이니, 소형 사이트라면 구글봇이 전체 페이지뷰의 대부분을 차지할 수도 있습니다.

    구글봇 때문에 부하가 갑자기 증가하여 CPU 점유율이 AWS에서 정한 "지속 가능 영역"을 초과하게 되었고, 버스트 CPU를 사용하여 몇 시간은 버틸 수 있었겠지만 그것마저 바닥나면 사용할 수 있는 CPU의 비율이 급격하게 줄어듭니다. 평소에는 그럭저럭 쓸만하던 애드온들도 이제 3초, 5초씩 딜레이를 일으키기 시작합니다. 갑작스런 딜레이 때문에 쿼리 옵티마이저가 헷갈려하기 시작하고, 쿼리는 더 비효율적이 되고, 서버는 더 느려지는 악순환이 이어지지요. 쿼리를 수정하거나 애드온을 꺼서 악순환의 고리를 끊어주면 버스트 CPU가 회복되면서 서서히 정상으로 돌아옵니다.

  • profile profile
    CPU 점유율이 AWS에서 정한 "지속 가능 영역"을 초과하게 되었고

    --> 이게 AWS에서 가하는 제한 때문에 발생하는 독특한 현상인거네요??

    할당된 자원을 독자적으로 본인 서버가 뻗던 말던 보장해주는 방식과 그렇지 않은 AWS 방식의 차이로 읽혀지네요.

    잘 이해했나 모르겠습니다.

    라이트세일은 CPU면에서 보면 정말 취약한 구조네요.
  • profile profile

    하이브리드 자동차와 비슷한 방식입니다.

    내연기관 엔진이 일정량의 파워를 무조건 보장합니다. 급가속하거나 오르막을 올라가기 위해 그 이상의 파워가 필요하면 전기모터를 돌려서 힘을 더 낼 수도 있습니다. 그러나 전기모터를 계속 돌리면 배터리가 금방 바닥납니다. 한동안 정속주행을 하거나 회생제동을 통해 배터리를 충전해 주기 전까지는 꼼짝없이 내연기관만으로 버텨야 합니다. 시내 운전만 한다면 큰 문제가 없지만, 한계령 고갯길이라도 올라가려고 하면 힘이 딸리는 것이 느껴지겠지요.

    AWS에서 무조건 보장하는 CPU 점유율은 서버 사양에 따라 10%~50% 정도입니다. 원글의 그래프에서는 30%로 나오네요. 나머지는 서버 부하가 낮을 때 "남는 CPU"를 사용해서 충전하여 쓰는 배터리 같은 개념이예요. 이미지서버나 백업서버로는 괜찮지만 실제 사이트를 운영하려면 이게 참 걸리적거립니다. 그냥 AWS 1코어 = 일반 서버 1/8~1/4코어와 같다고 생각하고 예산을 짜면 편합니다.

    오라클 클라우드, Vultr 등 대부분의 클라우드 플랫폼에서 제공하는 저사양 서버는 다 마찬가지입니다. 실제로 100%가 보장되는 CPU라면 Dedicated라든지 리얼코어라는 식으로 광고를 하지요.

  • profile profile
    네. 제가 주로 리얼코어 상품만 써서 CPU 사용율이 10% 정도에 머물렀던거네요 ㅋ 제가 가진 CPU 2개랑 비교도 안되겠습니다. 그동안 50% 이하로 봐야 한다는게 어떤 이유인지 몰랐는데 이번 사례와 이 설명으로 충분히 이해가 갑니다. 50%가 아니고 20% 성능도 못낼 경우도 흔하겠네요.

    잘못된 쿼리로 인해 충분히 문제될 만한 CPU 컨디션인 상태가 자주 연출될 수도 있겠습니다.
    전 앞으로도 리얼코어만 쓰기로 ㅋㅋ
  • profile

    덧붙여서, 모바일 작성 표시 애드온은 2021년 현재 큰 의미가 없다고 생각됩니다. 대부분의 사용자들이 모바일로 접속하니까요. 모든 글에 모바일 딱지를 붙여준다면 어느 글에도 붙여주지 않는 것이나 마찬가지지요.

     

    위젯이 많은 메인화면 같은 곳에서는 이 애드온이 수백 개의 쿼리를 발생시키기도 합니다. 하나하나의 쿼리는 빠르지만 수백 개의 실행시간을 합치면 만만치 않아요. 심지어 웅돌프님 사이트에서는 게시판 스킨 특성상 모바일 작성 아이콘이 보이지도 않고 있었습니다. 보여주지도 않을 데이터를 계속 불러오고 있었던 거죠... ㅠ

  • profile profile
    엌!! 기진곰님 말씀처럼 게시판 스킨에서 보여주지 않고 있었네요.
    댓글에서 표시가 되길래 잘되는지 알었는데... 어차피 저한텐 필요 없는 애드온 이었네요.

    이번 계기로 필요 없는 모듈, 애드온 정리할 명분이 생겼습니다.^^
  • profile profile
    라이트세일에서 탈출하셔야 할 것 같네요. 지금 노말한 경우에서도 문제가 생길 정도네요. CPU 사용 제한을 들어보니 말입니다.