Wordpress Database Slow-InnoDB로 전환해야합니까?

10K가 넘는 게시물이있는 WordPress 사이트가 있으며 게시물을 추가하고 편집 할 때마다 속도가 매우 느려집니다. 페이지는 관리자의 게시물 목록과 함께 사용자에게 훌륭하고 빠르게로드되지만, 쓰기 또는 업데이트가 발생하면 서버가 100 % CPU로 이동하고 시간이 오래 걸립니다 (PHP의 60 초 초과).

MyISAM의 테이블 수준 잠금과 관련이 있다고 생각하고 이것을 InnoDB로 전환하려고 생각합니다. 이 작업의 의미는 무엇입니까?

일부 통계 :

select  - per hour ~22k
update  - per hour ~7.6k
set option  - per hour ~7k

내가 할 수있는 다른 최적화가 많이 있다는 것을 알고 있지만 이것이 가장 큰 영향을 줄 수 있다는 느낌이 듭니다.

감사

편집 : 나는 속도 저하를 일으키는 주요 문제 중 하나를 발견했으며, 매번 "관련성"을 재생성하는 것은 YARPP (Yet Another Related Posts Plugin)였으며, 이는 우리가 가지고있는 2k + 태그 때문인 것으로 보입니다. "태그 고려"옵션을 해제했는데 속도가 상당히 빨라졌습니다.

또한 일을 재생성하는 다른 플러그인은 일부 XML 사이트 맵 플러그인과 같은 이러한 종류의 문제를 일으킬 수 있습니다.

따라서 Wordpress의 InnoDB vs MyISAM에 대한 좋은 답변을 여전히 듣고 싶지만 즉각적인 문제가 해결되었습니다!

실제로 InnoDB로 전환하고 싶습니다. 많은 사람들이 테이블 잠금 / 행 잠금에 대해 오랫동안 논의 해 왔습니다. 저는 항상 InnoDB 핸드 다운을 선택합니다. 그러나 InnoDB ... CACHING을 선택해야하는 또 다른 깊은 이유가 있습니다.

대부분의 사람들은 MyISAM이 읽기 속도가 더 빠르다는 것을 자랑하지만, 대부분의 사람들은 키 캐시 (key_buffer_size로 설정 됨)라고하는 MyISAM의 많은 캐시가 .MYI 파일의 색인 페이지 만 캐시한다는 사실을 잊어 버립니다. 데이터 페이지를 캐시하지 않습니다. 32 비트 시스템에서 공식 최대 4GB입니다. 64 비트의 경우 8GB가 가장 좋습니다.

InnoDB 버퍼 풀은 데이터 및 인덱스 페이지를 캐시합니다. 보유한 서버에 따라 RAM의 전체 데이터 세트를 캐시 할 수 있습니다. InnoDB를 최대 80 %의 RAM과 10 %의 DB Conenction에 맞게 조정하고 10 %는 OS에 남겨 둘 수 있습니다. 다른 운영 체제에서도 마찬가지입니다 .

Drupal 고객 에게 놀라운 성공을 거두었습니다. Wordpress에도 적용됩니다 . WordPress를 사용하여 클라이언트에 DB 지원을 제공했습니다. 같은 개선.

더 많은 MyISAM을 사용할 수 있도록 항상 InnoDB에 대한 메모리를 보다 효과적으로 구성 할 수 있습니다. 성능 요구에 맞게 InnoDB를 tweek 하는 방법은 항상 있습니다 . 데이터가 커짐에 따라 결국 요구 사항이 될 것 입니다.

InnoDB는 아마 당신에게 도움이되지 않을 것입니다-페이지 / 행 레벨 잠금은 경합을 완화시키는 데 도움이되지만 그것이 문제가되는 것처럼 느껴지지는 않습니다.

일반적인 블로그 시나리오에서 MyISAM이 InnoDB보다 느리다는 것을 암시하는 많은 것들이 있습니다 (쓰기보다 많은 읽기).

전환하기 전에 최소한 다음을 수행해야합니다.

• mysqltuner를 실행하면 구성 조언을 얻을 수 있습니다 (완전하지는 않지만 모든 것을 알 수는 없습니다)
• 느린 쿼리 로깅을 켜고 하루 정도 그대로 둔 다음 로그를 탐색하고 쿼리를 설명하여 진행 상황을 확인하십시오.

개인적인 경험을 통해 wp_comments의 색인화되지 않은 필드에 색인을 추가하면 내 특정 상황 (10 명 정도의 사람들이 동시에 댓글을 달 수있는 폭발적인 주석 달기)에 큰 도움이되었으며, 알아낼 수있었습니다. 어떤 쿼리가 느리게 실행되고 있으며 왜 문제에 대한 이해를 높이고 REAL 솔루션을 제공합니까?