KLDP의 속도개선을 위해 한 작업 + 추가 개선 정보 수집
우선 현재까지 진행한 작업을 1차로 여기서 마무리 하려고 합니다.
이에 대한 내용은 kldp-drupal.txt 파일로 첨부했습니다.
아래는 처음에 적은 내용입니다.
------------------------------------
우선 쿼리와 관련해서 한 작업은 아래와 같습니다.
comment.module의
SELECT COUNT(cid) FROM comments WHERE pid = ? AND status = ?
쿼리의 응답속도 개선을 위해 아래 인덱스 추가
ALTER TABLE comments ADD INDEX index_comments_count(pid, status);
tracker.module의
모든 최근글 보기 쿼리 수정
$sql = 'SELECT DISTINCT(n.nid), n.title, n.type, n.changed, n.uid, u.name, l.last_comment_timestamp AS last_post, l.comment_count FROM {node} n INNER JOIN {users} u ON n.uid = u.uid INNER JOIN {node_comment_statistics} l ON n.nid = l.nid WHERE n.status = 1 ORDER BY last_post DESC';
에서
$sql = 'SELECT n.nid, n.title, n.type, n.changed, n.uid, u.name, l.last_comment_timestamp AS last_post, l.comment_count FROM {node} n INNER JOIN {users} u ON n.uid = u.uid INNER JOIN {node_comment_statistics} l ON n.nid = l.nid WHERE n.status = 1 ORDER BY last_post DESC';
로 수정
나의 최근글 보기 쿼리 수정
$sql = 'SELECT DISTINCT(n.nid), n.title, n.type, n.changed, n.uid, u.name, l.last_comment_timestamp AS last_post, l.comment_count FROM {node} n INNER JOIN {node_comment_statistics} l ON n.nid = l.nid INNER JOIN {users} u ON n.uid = u.uid LEFT JOIN {comments} c ON n.nid = c.nid AND (c.status = %d OR c.status IS NULL) WHERE n.status = 1 AND (n.uid = %d OR c.uid = %d) ORDER BY last_post DESC';
$sql_count = 'SELECT COUNT(DISTINCT(n.nid)) FROM {node} n LEFT JOIN {comments} c ON n.nid = c.nid AND (c.status = %d OR c.status IS NULL) WHERE n.status = 1 AND (n.uid = %d OR c.uid = %d)';
$sql = db_rewrite_sql($sql);
$sql_count = db_rewrite_sql($sql_count);
$result = pager_query($sql, 25, 0, $sql_count, COMMENT_PUBLISHED, $uid, $uid);
에서
$sql = 'SELECT * FROM ( SELECT DISTINCT(n.nid), n.title, n.type, n.changed, n.uid, u.name, l.last_comment_timestamp AS last_post, l.comment_count FROM {node} n, {node_comment_statistics} l, {users} u, {comments} c WHERE c.uid= %d AND n.nid=c.nid AND l.nid = n.nid AND u.uid=n.uid UNION SELECT DISTINCT(n.nid), n.title, n.type, n.changed, n.uid, u.name, l.last_comment_timestamp AS last_post, l.comment_count FROM {node} n, {node_comment_statistics} l, {users} u WHERE n.uid = %d AND l.nid = n.nid AND u.uid=n.uid)zz ORDER BY last_post DESC';
$sql_count = 'SELECT COUNT(*) FROM ( SELECT DISTINCT(n.nid), n.title, n.type, n.changed, n.uid, u.name, l.last_comment_timestamp AS last_post, l.comment_count FROM {node} n, {node_comment_statistics} l, {users} u, comments c WHERE c.uid=%d AND n.nid=c.nid AND l.nid = n.nid AND u.uid=n.uid UNION SELECT DISTINCT(n.nid), n.title, n.type, n.changed, n.uid, u.name, l.last_comment_timestamp AS last_post, l.comment_count FROM {node} n, {node_comment_statistics} l, {users} u WHERE n.uid = %d AND l.nid = n.nid AND u.uid=n.uid )zz';
$sql = db_rewrite_sql($sql);
$sql_count = db_rewrite_sql($sql_count);
$result = pager_query($sql, 25, 0, $sql_count, $uid, $uid);
로 수정, 하지만 mysql 버전이나 dbms에 따라 적용 불가능할수 있음.
그리고 디비 서버의 my.cnf에서 쓰레드에 할당되는 버퍼값(소트,조인등과 관련된 값)들을 늘렸습니다.
임시 테이블이 생성될때 디스크를 긁는걸 방지하기 위한 수정입니다.
하지만 디비 서버는 아직 최적화가 되었는지는 알 수 없으므로 계속 테스트가 필요합니다.
현재 자주는 아니지만 table lock, system lock등이 종종 발생합니다.
그리고 이건 제 생각인데 PostgreSQL의 전환도 고려해 볼 만한 상황입니다.
단, 테스트가 확실히 되고, 누군가 도움을 주실분이 계시다는 가정하에서 입니다.
이것저것 drupal사이트를 뒤져보았는데, 대부분은 mysql 시스템 튜닝에 대한 글만 있네요.
그리고 누군가의 글에서 위에 제가 수정한 쿼리들을 저렇게 쓴 이유를 적어 놓았는데 제가 잘 이해하지는 못했습니다.
암튼 단기적으로는 속도 개선을 보았지만 어차피 게시물들이 계속 늘어나는 상황에선 또다시 문제가 발생할 수 있습니다.
어차피 한정된 하드웨어 자원에서는 한계가 있겠지만 그래도 가능하면 그 안에서 최대의 효과를 보도록 해야하지 않을까요?
회사라면 장비 늘리는게 제일 속편하겠지만 KLDP는 비영리 목적으로 운영되고 있으니까요. 이용자들이 힘을 모아야 할거 같습니다.
어제 하도 답답한 관계로 drupal사이트를 돌아다니며(개선작업은 정보도 없이 막 했다는 뜻입니다. ㅋㅋ) drupal의 api를 조금 보았는데 정확히 이해했다고 보긴 어렵지만 디자인 자체가 개선의 여지를 줄 수 있도록 많이 고려되어 있는것 같습니다.
저는 우선 밀린 일도 해야하고 정신도 가다듬을겸 휴식도 취해야 할거 같습니다.
업무에서 일탈해서 새로운걸 해보는 것도 좋은데 너무 달리면 안될것 같아서.. ㅋㅋ
| 첨부 | 파일 크기 |
|---|---|
 kldp-drupal.txt | 9.87 KB |
너무너무 수고
너무너무 수고 많으셨습니다...
pgsql로의 전환은 신중하게 결정해야 할 것 같습니다. 여러가지 복합적인 요인들이 많아서요...
drupal.org 에서 pgsql /
drupal.org 에서 pgsql / mysql 에 대해서 설문조사를 한 것이 있네요. 예상대로 mysql이 압도적이었습니다. http://drupal.org/node/37268
그런데 내용 중에 pgsql이 제대로 동작하지 않거나 문제가 될 수 있다는 부분들이 좀 있네요. 모듈은 물론이고 코어에 대해서도 문제가 있다는 언급이 좀 보이는데 mysql을 가장 많이 쓰다 보니 어쩔 수 없는 현상인 듯 합니다.
따라서 이 내용으로 판단하여 본다면 pgsql을 선택할 경우 단순히 db 단에서 튜닝만 해서 되는 것이 아니라 php 코드 자체에도 손을 대어야 할 경우가 생길 것이 예상되므로 pgsql로의 전환은 아주 오랜 기간이 지나야 가능할 것으로 생각됩니다.
앗, 그렇군요. 다른
앗, 그렇군요. 다른 정보를 찾은게 있는데.
http://dev.mysql.com/books/hpmysql-excerpts/ch06.html
The two most important global buffers are the MyISAM key buffer (key_buffer_size) and InnoDB's buffer pool (innodb_buffer_pool_size). The MyISAM key buffer is where MySQL caches frequently used blocks of index data for MyISAM tables. The less often MySQL needs to hit the disk to scan a table's index, the faster queries will be. If possible, consider making the key buffer large enough to hold the indexes for your most actively used tables?if not all your tables. By adding up the size of the .MYI files for the tables, you'll have a good idea how large to set the buffer.
MySQL doesn't cache rows for MyISAM tables?only indexes. InnoDB, on the other hand, caches index and row data together in its buffer pool. As you'll recall from Chapter 4, InnoDB uses clustered indexes. Because it stores the index and row data together, it's only natural to cache the index and row data in memory when possible.
이거 MyISAM 테이블은 전체 row가 Key Buffer에 안들어 가고 InnoDB는 들어간다는 얘기 같은데 맞나요?
지금 Key Buffer가 많이 놀구 있는데, 만일 대부분의 테이블 내용이 버퍼로 들어가게 하면 어떨까요?
1. InnoDB로 테이블 타입을 바꾼다.
2. MyISAM테이블의 인덱스를 바꿔서 버퍼링 되게 한다.
둘중에 하나가 나을텐데 1번이 더 나아 보입니다.
깔끔하게 끝내지 못해서 일에 집중이 안됩니다. ㅡ,.ㅡ
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
drupal.org 에 일단 이
drupal.org 에 일단 이 내용을 포스팅하여 두었습니다.
http://drupal.org/node/65269
반응을 봐서 패치를 올리죠. dormael님의 이름으로 제가 올리겠습니다.
좋은 결과 있길~
네, 근데 불안합니다.
네, 근데 불안합니다. ㅡ,.ㅡ
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
3개의 답글이
3개의 답글이 올라왔군요. 셋다 모두 drupal에서 매우 잘 알려진 사람들이고 특히 한개는 drupal의 원개발자인 Dries네요!
따라서 DISTINCT를 제거한 것은 문제를 일으킬 수 있다 하니 다른 방법을 찾아보면 좋을 것 같고
인덱스를 추가한 것은 패치로 올리고, 쿼리를 수정한 것은 벤치마크 결과와 함께 패치를 따로 올려서 패치가 accept되게 하면 좋을 것 같습니다.
그리고 memcache라는 것에 대해 이야기를 들었습니다. http://drupal.org/node/44220#comment-121952 를 알려 주었는데 한번 적용해 봐야겠습니다.
아, 두번째 수정한
아, 두번째 수정한 쿼리도 DISTINCT와 같이 다르게 작용할 수 있습니다.
현재 KLDP의 데이터 상에서만 문제가 안보일수 있는거죠.
즉, 두 쿼리의 수정에 대한 다른 방법을 찾아야 할 것 같습니다.
^^
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
/*Add these functions to
/*
Add these functions to bootstrap.inc and replace the original include_once './includes/session.inc'; with a call to
drupal_memcache_init. $conf['memcache_use'] and $conf['memcache_session'] are switching memcache usage.
$conf['memcache_session_server'] is an array of host:port strings.
*/
아래 함수를 bootstrap.inc 에 추가(위 코멘트 밑에 있는 함수 두개. bootstrap.inc는 includes디렉토리에 있는거죠?).
include_once './includes/session.inc';
이 코드(이게 아마 bootstrap.inc에 있는건가 봅니다. 어디에 있다고 말 안한거 보면)를
drupal_memcache_init();
이걸로 바꾸라는 얘기 같구요.
마지막의 $conf['memcache_use'], $conf['memcache_session'], $conf['memcache_session_server'] 이 세개는 환경설정 같은데요.
$conf['memcache_use'] = 1; (true? php는 확실치 않아서요. ^^)
$conf['memcache_session'] = 1; (세션도 이걸 이용해야 더 빠른거겠죠?)
$conf['memcache_session_server'] = 'memcache.kldp.org:1234'; (이런식으로 memcache서버가 설치된 주소랑 포트같네요. memcached라고 말한걸로 봐서요.)
settings.php인가 거기에 들어가는거 같습니다.
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
음... memcache라는 것이
음... memcache라는 것이 무엇인지를 좀더 알아본 뒤에 적용해 보겠습니다. 감사합니다... 혹시 이미 써보신 분이 계시면 좋으련만...
집에서 dbms만으로
집에서 dbms만으로 직접 테스트 했습니다.
펜티엄4 1.4(윌라멧), SDRAM 256MB*3, IDE HDD, WINDOWS XP SP3, Mysql 5.0.21
InnoDB로 모든 테이블을 바꾸고
InnoDB Buffer Pool의 크기를 512MB, query_cache_type=OFF 했습니다.
처음 쿼리가 실행되면 하드를 마구 읽어대더니, 다음부턴 완전히 메모리만 사용해서 실행되었습니다.
즉, drupal 원래의 최근글 리스트 쿼리가 최초 실행시에는 매우 길게 나왔지만, 두번째 실행부터는 4초가량으로 줄어 들었습니다.
CPU와 메모리의 차이를 생각하면 지금 운영되는 서버에서는 훨씬 더 빠르게 실행될거라고 생각합니다.
물론 비슷한 환경에서 테스트를 해봐야 더 확실해 질겁니다.
그렇게 되면 drupal의 디자인을 건드리지 않고도 많은 속도향상이 있습니다.
단, 변환하고 나니까 테이블스페이스가 3기가가 넘더군요. 변환 시간도 상당히 오래 걸렸습니다. 2-3시간정도..
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
table type 을 바꾸었을
table type 을 바꾸었을 때 별다른 side effect는 없을까요? 보통 모듈들을 설치할 때 테이블을 새로 추가하는 경우에는 myisam타입으로 설치되는데 하나의 db안에 어떤 테이블은 myisam, 어떤 테이블은 innodb... 다르게 되어 있어도 문제는 없겠지요?
그런데 innodb가 좋다면 왜 기본 타입을 innodb로 하지 않을까요... 문득 그게 궁금해 지는군요. 테이블 크기가 늘어나는 것은 별 문제가 안된다고 봅니다. 속도만 빨라진다면야 변환할 때 잠깐 사이트 닫아 놓으면 되죠뭐. :-)
무조건 좋은게
무조건 좋은게 아니라, 메모리로 데이터들을 충분히 캐싱할 수 있을만큼 메모리 양이 많을때만 좋은 상황이 됩니다.
제가 위에 적었듯이 MyISAM은 키만 캐싱하지만 InnoDB는 row를 캐싱하기 때문에 메모리만 충분하면 거의 대부분이 메모리 작업이 되니까요. 물론 변환시의 side effect같은것은 충분히 테스트 해야 한다고 봅니다. 제가 집에서 해본건 모든 테이블을 InnoDB로 바꾸고 단지 응답이 아주 느린 쿼리만 여러번 돌려본거라서요. 물론 쿼리캐시는 0으로 해놨습니다. 쿼리가 캐싱되면 응답시간이 거의 0이 나올테니까요.
기본적으로 아무리 잘 설계되어 있어도 단순하고 기능이 적은것 보다 빠르지는 않겠지만 현재 KLDP와 같은 상황에선 디스크가 발목을 잡고 있기 때문에 많은 성능 향상을 기대할 수 있다고 봅니다.
현재 디비서버의 2G 메모리중에 mysql이 약 600M정도를 쓰고 있고 이중에 키버퍼, 쿼리버퍼 같은 것들이 쓰는게 500M도 안됩니다. 시스템의 대부분 메모리가 놀구 있는 상황이죠.
전 디스크에 임시 테이블 만드는 것에서만 병목이 있다고 봤는데 제가 해본 테스트로는 임시테이블에 조인을 위해 각 테이블의 데이터를 읽어오는 것도 있었습니다. 제가 지식이 부족해서. 간과한게 있었네요. ^^
지금 생각해보면 디스크 임시 테이블을 쓰지 않는데도 프로세서 4개중에 1개를 99프로 점유하고 있을때 의심했어야 했는데..
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
두번째 쿼리도
두번째 쿼리도 잘못된게 확실합니다.
제가 아무것도 모르는 상황에서 수정을 해서 오류가 있었네요. ㅡ,.ㅡ
속도는 많이 좋아졌지만 제대로 가져오는게 아닌게 99.999퍼센트 확실합니다.
아니라면 현재 KLDP의 데이터가 어떻게 운이좋게 맞게 되어 있는거구요.
우선 수정과 관련해서는 전체 시스템을 최대한 효율적으로 활용하도록 변경한 후에 drupal을 더 이해하고 작업을 하는게 맞을거 같습니다. 공부가 필요합니다. ㅋㅋ
그리고 저 mysql이나 php 잘 모릅니다. mysql도 튜닝작업 dba와 함께 한번 한게 전부니까요. ^^
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
그렇군요. 그렇다면
그렇군요. 그렇다면 인덱스 추가하는 것만 빼고는 모두 원 상태로 되돌려야 한다는 말씀 같고요....
코드 수정 없이 일단 db 단에서 좀더 최적화할 수 있는 방법이 innodb를 적용하거나 memcached를 돌리거나 둘 중 한가지가 되겠네요. 둘다 쿼리 결과를 메모리에 담아 둔다는 측면에서 비슷할 것 같은데 innodb로의 전환에 문제가 없다면 innodb로의 전환을 먼저 시작하는 것이 좋을 것 같습니다.
drupal code를 수정하는 것은 저 역시 처음부터 그다지 내키지 않았던 일이라... db 단에서 최대한 뽑을 수 있을 만큼 뽑아내는 것에 100% 동의합니다. :-)
개인적으로 돈만
개인적으로 돈만 많으면 64비트 머신에 메모리 충분히(16기가 정도?) 달고 스카시 raid로 innodb로 바꿔서 돌리면 정말 행복하겠지만요... ㅋㅋ
아마 몇년 정도는 전체 테이블이 메모리로 올라오지 않을까요?
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
아직 완전히 확정된
아직 완전히 확정된 것은 아니지만 서버를 업그레이드하는 것에 대해 이야기가 진행 중입니다. 그 중 한군데에서 64비트 제온 CPU에 3G RAM이 장착된 머신을 줄 수 있을 것 같은데 좀 사용하다가 메모리를 13G 더 달면 되겠죠. :-)
업그레이드 할 수
업그레이드 할 수 있으면 좋겠네요. ^^
우선, 테스트 할 곳이 없다면 운영이 마루타가 되어야 합니다. 서버 내리고, 기존 데이터 백업하고 InnoDB로 변환하고 버퍼값등 메모리 값들 수정해 준 후에 올려서 해보고, 잘 안되면 원래 폴더로 원복하는 방식이 어떨까요?
운영이 마루타가 되야 하나요?
저도 가능하면 비슷한 환경에서 테스트 먼저 하는게 좋지만 안되면 이 방법밖에 없겠네요.
권순선님은 어떤 방법을 생각하고 계신가요?
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
서버 업그레이드가
서버 업그레이드가 확정되면 그때 함께 적용하는 것이 좋을 것 같습니다. 그렇지 않으면 두번 일을 하게 될테니까요. (현재 사용중인 서버에서 한 번, 새 서버에서 또 한 번)
오늘이나 내일 중으로 결정이 될 것으로 생각되니 그동안에 myisam --> innodb로의 전환시 가능한 side effect가 어떤 것이 있는지, drupal.org 에서 innodb로의 전환 외에 다른 db 튜닝 정보는 더 없는지 확인해 보는 것이 좋을 것 같습니다.
리눅스에서는 남는메모리를 디스크캐시로 쓸텐데요?
리눅스에서는 남는 메모리를 디스크캐시로 쓸텐데요?
디스크캐시보다 메모리에 올리는 것이 그렇게 효과가 좋은가요?
-------------------------------------------------------------------------------
이 댓글(comment)의 수정 및 삭제를 위해 이 글에 답글(reply)을 쓰지 말아 주십시요.
의견이 있으시면 원 글에 댓글(comment)로 써 주세요.
저도 디스크 캐싱이
저도 디스크 캐싱이 어떻게 되는지 잘 모르겠지만 아마 원하는 되로 되었으면 지금보다는 상황이 나았을겁니다.
가능하면 mysql에서 특히 innodb 버퍼 풀로 쓰는게 확실해야 하니까요.
디스크 캐시가 원하는 테이블들의 데이터가 있는 디스크 블록을 캐싱한다는게 보장이 안되니까요.
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
권순선님 궁금한게
권순선님 궁금한게 있습니다.
KLDP사이트가 응답 속도가 느려진게 drupal 4.7로 업그레이 하고부터 인가요, 아니면 phpbb에서 drupal 4.6으로 전환한후 부터인가요? drupal사이트에서 보면 여러 인덱스 패치가 되서 4.7에서는 꽤 쓸만한 성능이 나올꺼 같은데 좀 이상하네요.
솔직히 제가 제안한 방법은 좀 무식한 방법이긴 합니다. 대부분 쿼리들이 인덱스를 잘 타고 조인시 임시테이블이 만들어 지더라도 사이즈가 충분히 작다면 이렇게 느리지는 않을텐데요. 다른 큰 사이트들이 MyISAM으로도 충분히 잘 돌고 있는지 확인할 길이 없어서 막막하네요. ㅡ,.ㅡ
혹시라도 phpbb에서 전환이나 버전 업그레이드에서 생긴 특별한 문제인가 해서요.
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
제 경우는 phpbb를
제 경우는 phpbb를 사용하고 있을 때도 매우 느렸습니다. 4.6으로 전환하고 나서 더 느려졌고요... 그때 느렸던 이유는 일부 추가 모듈들이 비효율적으로 동작했기 때문이며 그 모듈들을 제거하고 나서는 속도가 많이 향상되었습니다만 그래도 여전히 느렸습니다. 4.7로 업그레이드하고 나서도 제 개인적으로는 '약간' 빨라진 듯한 느낌을 받긴 했습니다만 4.6과 비교해서 상대적인 것이고 여전히 느렸습니다.
다른 drupal site들이 어떻게 동작하는지는 잘 모르지만, db 단에서 하드웨어가 받쳐줄 경우 최대한 튜닝하는 것은 기본적으로 다 했을 것 같습니다. KLDP는 그 작업을 하지 못했던 것이고요. :-)
정확하게 말하자면,
정확하게 말하자면, phpbb 나 drupal 이나 모두 KLDP 가 감당하기에는 버거운 것들입니다. 하지만, phpbb 가 drupal 보다는 훨씬 가볍게 작동 했습니다.
둘다, 설계상 KLDP 가 감당할 만한 구조는 아니었으며, phpbb 의 경우 drupal 보다 좀더 단순하여, 문제가 되는 부분을 phpbb 에서 따로 떼어내서 background cron job 으로 대체함으로서 (search table clean job / rss feeding rutine..) 가볍게 만들 수 있었지만, drupal 은 좀 더 복잡해서 저도 삐리리 하고 있었습니다.
phpbb 에서 drupal 로 이전하기 위한 논의에서 저외에도 몇몇 분들의 주장은 더이상 기존의 application 으로는 KLDP 를 운영하기에는 한계가 있다는 것이 주장이었으나, 고양이 목에 방울을 달 자신(시간) 이 없었기 때문에, 일단 drupal 로의 전환을 지원한 것입니다.
MyIsam 이 성능이 나빠서 innodb 로 변경을 한다고 해서 크게 나아지리라 생각이 되지는 않습니다. 또한, 이보다 더한 site 에서도 전 MyIsam 으로 운영을 한 적이 있으니까요. 실제로 중요한 것은 table 간의 관계를 얼마나 효율적으로 만드는 것이냐에 대부분의 성능이 좌우된다고 보여집니다. 특히 .. KLDP 와 같이 장비로 땜빵할 수 있는 사이트가 아니라면 더더욱 중요한 문제가 되겠죠.
물론.. 도움이 되지 않는 말만 잔뜩 적어 놓아서 죄송합니다만.. phpbb 와 drupal 의 비교를 묻는 것에서.. 운영적인면을 제외한다면, 성능이나 효율면에서는 둘다 영 db 설계가 아니올시다라는 느낌을 받았으며, phpbb는 좀더 쉽게 극복할 수 있었던 반면 drupal 은 훨씬 그 과정이 어려울 것이라 생각이 됩니다. 또한, MyIsam -> innodb 까지 가야 하는 문제도 발생을 시킨다는 것이죠. 최소한 phpbb 에서는 위의 tunning 후에, MyIsam 에서도 널널 그 자체 였습니다.
DB시간 17:03분쯤 제가
DB시간 17:03분쯤 제가 위의 글 올리려고 하던때에 상태가 매우 안좋았었군요, 대부분 슬로우 쿼리들이 2-3초인데 갑자기 10초대에 가까운 것들이 늘어났네요.
누군가 포럼 페이지에서 새로고침을 자주 누른게 아닌가 싶네요. ㅋㅋ
# Time: 060525 17:12:24
# User@Host: junseo[junseo] @ [210.118.94.78]
# Query_time: 98 Lock_time: 0 Rows_sent: 0 Rows_examined: 12455618
SELECT t.word AS realword, i.word FROM search_total t LEFT JOIN search_index i ON t.word = i.word WHERE i.word IS NULL;
이거 엄청나네요. 록이 안걸려서 다행이긴 한데.. 시간도 시간이지만 Rows_examined: 12455618
검색 인덱스가 엄청나군요. ㅡ,.ㅡ
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
아
아 그러네요.
http://drupal.org/drupal-4.7.1
4.7.1이 나와서 이것저것 버그픽스를 보고 있는데 지금 어디까지 패치가 되어있나요?
가장 큰건 보안 패치인거 같긴 한데 다 보진 못했지만 인덱스 변경도 있어 보입니다.
혹시나 해서요..ㅋㅋ
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
좀 이상하네요.
좀 이상하네요. 아침에 mysql 관련한 security patch 공지가 떠서 패치를 했는데 위의 url을 보니 그것 말고도 패치할 것이 한가지 더 있어서 방금 패치를 했습니다.
그런데 정작 4.7.1과 4.7.0의 tarball을 받아서 비교해 보니 mysql 관련한 security patch는 4.7.1에 적용되어 있지 않은 것 같네요. 어쨌든 두가지 패치 모두 적용해둔 상태입니다.
인덱스 변경은 어디에 있나요? 없는 것 같은데...
이상한 요청을
이상한 요청을 하시는 분이 계시네요 ㅡ,.ㅡ
이게 맞는 건가요?
별루 상관 없는거 같긴 하네요..
죄송합니다. 미관을 흐트려놔서.. 이거 어케해야 할까요?
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
구글 데스크탑
구글 데스크탑 프로그램과 구글 rss 리더가 rss를 긁어갈 때 base_url을 제대로 인식하지 못해서 그렇습니다. drupal에서 base_url을 상대 경로로 하지 말고 절대 경로로 선언해 주면 잘 되는 것인데 4.7에서도 고쳐지지 않았습니다. 원칙적으로는 rss 리더가 잘못하고 있는 것인데 어쨌거나 아직 해결이 되지 않았습니다.
아래 주소에서
아래 주소에서 봤습니다.
http://drupal.org/project/cvs/3060/?branch=DRUPAL-4-7
24일 패치에
/database/updates.inc 에서 한줄이 패치되었습니다.
아, 이건 정식 패치에는 안들어 가는 건가요?
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
아니군요, 제가
아니군요, 제가 비교를 잘못 했습니다. 인덱스 등에서도 변화가 있었네요. 그냥 패치 두개만 적용했었는데 전체적으로 업그레이드해야겠군요. -_-;
p.s. dormael님, 제 답글에 대해서 답글을 다실 때 제 답글 아래에 있는 '답글' 버튼을 클릭하셔서 답글을 올려 주세요... 그래야 글타래가 형성됩니다. 답글 보기 형식을 '묶어보기'로 바꾸어서 보시면 확인하실 수 있습니다. :-)
아, 이런기능이
아, 이런기능이 있었네요. ^^
넵, 알겠습니다.
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
몇가지 테스트 해본 결과..
테스트시 쿼리 캐싱을 막고 했습니다.
1. 우선 가장 느린 쿼리는 역시 tracker.module의 '모든 최근글 보기'와 '나의 최근글 보기' 입니다.
문제가 되는 이유는 몇개의 테이블을 조인하면서 임시 테이블을 생성하는데 이때 임시 테이블의 크기가 매우 큰 관계로 디스크에 임시 테이블이 만들어질 가능성이 큽니다.
우선 최대 메모리 임시 테이블의 크기를 64M로 했을때는 '모든 최근글 보기'가 메모리 상에서 만들어져 결과가 나왔습니다.
(최근까지 메모리 임시 테이블이 64M였고 이 글을 쓰기 조금전에 온라인상으로 128M로 늘려놓은 상태입니다)
하지만 '나의 최근글 보기'는 64M에서도 디스크 임시 테이블을 사용해 응답 속도가 매우 느렸습니다. 그래서 128M로 메모리 임시 테이블 크기를 늘려 보니 디스크 임시 테이블을 사용하지 않았습니다.
이를 변경하기 위해 적용한 값이, 아래의 두가지 입니다. 그외의 버퍼값들은 크게 영향을 받지 않는것 같습니다. 디스크 임시 테이블의 로드가 다른것에 비해 아주 크기 때문에 그런것 같습니다.
이는 쓰레드 마다 할당되지는 않지만 실시간 요청이 많을 경우엔 전체 메모리에 부담이 될수는 있습니다.
2. InnoDB로 테이블 타입을 변경하고 테스트 한 결과. 1번과 동일한 테스트 입니다.
innodb의 buffer_pool의 크기를 512M혹은 1024M 정도로 놓고 테스트 했습니다.
두 쿼리와 포럼 모듈의 느린 쿼리들을 실행한 결과 최대 0.5초 정도의 빠른 응답을 보였습니다.
물론 최초 실행시에는 많은 row를 메모리로 버퍼링 하는 관계로 응답이 느렸지만 두번째 실행 부터는 일정한 정도로 빨라졌습니다.
3. drupal, mysql 사이트 들에서 자료들을 찾아 본 결과.
http://drupal.org/node/51263
5). Performance sites should use InnoDB for most tables particularly tables such as node that get a lot of writes and reads. MyISAM exclusive table locks for updates before selects versus InnoDB's row level locking can mean MyISAM blocks reads if there are many writes. Convert from MyISAM to InnoDB.
실제 제가 한 1, 2의 테스트에선 select만을 확인해 본거지만, 위의 글에서는 node테이블이 읽기뿐만 아니라 쓰기도 자주 일어나므로 InnoDB를 추천하는것 같습니다. 제 개인적인 의견으로는 최소한 1, 2 테스트에서 사용된 쿼리상의 테이블은 다 바꾸어야 하지 않을까 생각됩니다.
4. 장기적으로 현재 kldp의 데이터 양은 꽤 많은것으로 판단됩니다. 최소한 drupal.org의 forum보다 많더군요. drupal.org에 kldp의 상황을 정확히 알리고 최대한 지원을 받으면 좋을거 같습니다. ㅋㅋ
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
인덱스 추가 했습니다.
몇 ms라도 아끼기 위해.. 쿼리는 정확히 기억이 안나네요. ㅡ,.ㅡ
아마 최근 5명의 가입회원 목록을 가져오는 쿼리 였던거 같습니다.
모두 쓰는 내용도 아니고 개선도 아주 작아서 눈에 보일만큼 빨라지진 않습니다.
그런데 임시 디스크 테이블이 계속 생기는게 이상하네요. 128메가 메모리 임시 테이블이 작아서 그런것 같지는 않은데.
동시 사용자가 많은 상황에서 메모리가 부족할때 생기는건지.. 그렇다고 하기엔 너무 자주, 많이 생기는것 같네요.
user_block의 아래 쿼리 였네요.
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
innodb의 테이블 스페이스 변경
하나의 파일로 되어있던 innodb의 테이블 스페이스를 각각의 테이블에 따로 지정하도록 변경했습니다.
작업 시간은 약 1시간 20분쯤 소요되었으며, 원래는 20분 정도면 끝날 내용이었으나 제가 무지하게 헤매는 바람에 시간이 오래 걸렸습니다.
죄송합니다. ㅡ,.ㅡ
주된 원인은 기존 테이블의 데이터를 덤프한 후 다시 db에 넣을때의 캐릭터 인코딩의 차이로 인해 들어간 데이터 중 문자열 데이터가 모두 깨지는 현상이었습니다. 운영체제의 경우 euckr을 쓰고 있었고 데이터베이스의 테이블들은 utf8을 쓰고 있어서 여러 해결방법을 찾던중 단 한줄을 덤프파일 맨 위에 추가해 주는 방법으로 제대로 된 데이터를 넣을 수 있었습니다.
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
디스크 임시 테이블 생성이 잦은 이유.
확실한 건지는 모르지만 CREATE TEMPORARY TABLE 쿼리에서 테이블 타입을 정확히 명시해 주지 않을시에 임시 테이블이 MyISAM 타입으로 디스크에 생성되는것 같습니다.
TYPE=HEAP 이라고 정확히 명시해 줄때는 임시 디렉토리에 .frm파일만 생성이 되었습니다.
의문시 되는건 Created_tmp_disk_tables status가 두 경우 모두 늘어나지는 않는다는 거네요.
회사 개발서버에서 한거라 정확한건지는 모르지만.
그러면 대체 어디서 Created_tmp_disk_tables의 크기가 늘어나게 되는건지.
혹시 알고 계시는 분 없으신가요?
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
여기다 다는게 맞을꺼 같아서..
드루팔에 대해 아시는 분의 조언이 필요합니다.
http://api.drupal.org/api/4.7/group/hooks
제 생각이 맞을거 같긴 한데 혹시나 해서요. drupal이 노드나 코멘트 기타 등등 코어에서 일어나는 특정 액션에 대해 사용자가 정의한 모듈에서 이벤트(?)를 받을 수 있는 구조가 맞는건가요?
만일 그게 가능하면 현재 로드가 제일 심한 tracker.module을 위한 테이블을 만들어 놓고 저 액션을 통해 특정 row들을 업데이트 해줄수 있는 상황이 될듯한데요.
물론 누가 만드느냐?의 문제는 남아 있긴 한데, 가능해 진다면 현재 kldp의 응답 속도에 꽤 희망적인 내용이 아닐까요?
제가 drupal을 전체적으로 보고 있지 못해서 오해일 수도 있습니다. ㅋㅋ
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
http://drupal.org/node/36756
http://drupal.org/node/36756 를 참고해 보세요... 다른 방법으로 tracker를 구현한 것입니다...
네, 그러네요. ^^
확장 기능의 tracker 같습니다.
근데 돌려볼 곳이 없어서 확인은 불가능 하네요 ㅡ,.ㅡ
속도 개선이 있을지도 의문입니다. 거의 쿼리가 비슷한거 같아서요.
제가 걱정되는게 hook을 이용해서 모듈 개발자가 임의로 만든 테이블에 억세스 하고 전체 drupal시스템과 잘 맞물려 돌아가게 해야 하는데 지식이 부족한 관계로 이게 가능할까 의문이 듭니다.
대부분 모듈들이 제가 확인하기에는 적은수의 hook만 이용하는거 같아서요.
그런데 drupal 보면 볼수록 재미있게 설계된거 같네요..ㅋㅋ
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.