KLDP DB 서버 업그레이드를 위한 도움 요청

권순선의 이미지

사이트를 업그레이드하고 나서 속도가 많이 느려져서 여러가지로 불편하신 점이 많을 것으로 생각됩니다. 그래서 우선 하드웨어를 업그레이드하고자 합니다. 현재 사용중인 KLDP 하드웨어는 총 4대로서 안다미로사에서 제공한 서버는 현재 http://kldp.net 을 구동하고 있고 씨디네트웍스사에서 제공한 서버는 http://people.kldp.org 을 구동하고 있으며, HP 코리아에서 제공한 서버 2대가 DB/웹서버로 각각 나뉘어 http://kldp.org 를 구동하고 있는데 이중 DB 서버를 업그레이드하고자 하는 것입니다.

필요한 사양은 P4 3.0Ghz 듀얼 이상, 메모리 4GB 이상, SCSI HDD 30GB 이상입니다. 즉 현재 사용 가능한 x86 호환 서버 중에서 최대한 좋은 사양이 필요합니다. 현재 DB 서버에서 높은 컴퓨팅 파워를 필요로 하는 DB 관련 연산들이 많이 일어나고 있어 속도 향상을 위해 우선 하드웨어부터 업그레이드하려는 것입니다.

혹시라도 도움을 주실 수 있는 개인이나 회사가 있으시면 제 개인 메일(ksoonson (at) gmail.com)로 연락 주십시오. 쉬운 일이 아니라는 것을 잘 알기에 큰 기대는 하지 않고 있습니다만 혹시나 하는 마음에 글을 올려 봅니다. 임대 / 기증 모두 가능하며 이에 대해서 보답으로 하단부 배너 상시 게재 및 그 외 홍보에 필요한 추가적인 활동(예: press release)이 필요하실 경우 적극적으로 협력하겠습니다.

감사합니다...

관리자 주제: 

댓글

익명 사용자의 이미지

글쎄요. http://kldp.org/node/70319 를 본후 하드웨어 문제는 아니지 않나 하는데, 하드웨어 업그레이드하면 나아질까요?

최대한 느린 쿼리를 없애는 방법을 찾아내는 것이 근본적인 문제 해결인 듯 보이는데... 차라리 예전처럼 현상금(?) 걸고 해결해 보는 것이 낫지 않을까 합니다.

lacovnk의 이미지

1. drupal 홈페이지(http://drupal.org/) 가 별로 느리지 않은데.. 이 쪽에 혹시 커스터마이징을 했는지 알아봐도 좋을 것 같습니다.
2. 현상금 걸고 쿼리 최적화를 해보는 것도 좋을 것 같습니다.. 그 결과가 drupal 소스에도 적용되면 좋겠군요 :)

아무튼 잘 해결되면 좋겠습니다. 첫화면은 빨리 뜨는데, 다른 화면들은 좀 버벅거리는 걸 보면 안타깝습니다. (불쌍한 CPU~)

kilhan의 이미지

보통 이런 CMS 나 게시판들이 갖고 있는 특징들은
update 보다는 select query 가 많다는 것입니다.

(update 가 많은 게시판이나 CMS는 실제로 튜닝하기에 매우 힘들거나 시간이 걸리죠^^;)

mysql을 사용하시고 계시기 때문에
mysql 에서 사용하는 replication 기능을 사용하면 간단히 해결될것으로 생각합니다.

물론 drupal 이 replication 기능을 적절히 이용할수 있도록 query 가 구성되어 있을경우에만 가능하겠지요.
뭐 지금 생각이지만 drupal 이 중규모 이상의 site를 만들때 사용한다면 적당히 구성되어 있지 않을까 합니다.
아니라고 한다면 ..(음 지금으로써는 생각하기 싫군요, 좀 귀찮은 작업이 되겠죠)

그런데 replication을 사용하여 query 를 조절하는것이 어렵다고 한다면
mysql query cache 를 추천합니다.
(물론 이것도 drupal 이 쿼리를 이에 걸맞게 작성되어 있어야만 가능하겠지요)

만약 이것도 하실수 없다면 memory 사용을 권장드립니다.
아주 간단합니다

제일 로드가 많이 걸리는 서버를 memory mount 시켜서 사용하고
나머지 용량이 많고 적게 사용하는 서버는 스토리지에 사용합니다.
그리고 모든 데이타는 replication 시켜 실시간 백업 합니다.

이렇게 할경우 메인서버가 memory full 나 죽을경우 모든 DB가 slave에 안정적으로 보관되기
때문에 유실되지 않습니다.

단 memory 의 용량이 커야 서버가 안정적으로 돌것이기 때문에
최소 4G 최대 16G( 64BIT 환경이 되어야 할것입니다) 를 권장합니다.

Anonymous100의 이미지


사용을 해 보셨는지 모르겠습니다만 대다수 분들이 리플리케이션에 대한 환상을 가지고 계서서 한마디 남깁니다.

모 구인구직 사이트를 mysql 리플리케이션으로 몇달 돌려봤습니다.
평소엔 물론 상관이 없지만 부하가 엄청나게 심할 경우..즉 리플리케이션에 할당할 프로세스의 여유분이 거의 없다시피 할 경우 어떻게 되시는지 아신다면 섣불리 리플리케이션을 권하기는 힘드실겁니다.

구인구직 시즌에 테스트 결과 최대 한시간 이후에 데이터가 공유되는것을 확인 했습니다.

그런 문제점들 때문에 mysql 측에서도 리플리케이션이 아닌 클러스터팩을 별도로 개발하는 것으로 알고 있습니다.
리플리케이션은 정말이지 그냥 돈안들고 시스템이 여유작작일때 쓸만한 툴입니다. 그런데 여유작작이면 굳이 리플리케이션을 할 필요가 없으니 결국 어찌보면 쓸모없는 툴 이라고 할 수도 있습니다.

권순선의 이미지

drupal.org 는 4.7 버전을 사용하여 운영 중이며 위에 제가 적은 사양의 서버를 DB 서버로 두고 2-3대의 웹서버를 round robin으로 돌리고 있습니다. 현재 KLDP에서 사용중인 DB 서버는 Xeon 3Ghz 듀얼에 메모리가 2G이고 SATA HDD를 사용중입니다. 그다지 나쁜 사양은 아니지만 메모리나 SATA HDD가 업그레이드되면 더 좋은 성능을 기대할 수 있을 것으로 생각합니다. 하드웨어의 성능이 좋아지면 처리 속도는 당연히 줄어들 테니까요.

SW 적인 튜닝 역시 가능하면 병행하려고 합니다. 다만 튜닝을 위해서는 실제로 DB 서버로 로긴을 해서 확인하는 작업도 필요하고 DB 서버의 설정을 변경하여 테스트하는 작업도 필요할 것이므로 불특정 다수가 참여할 수 있는 공모전의 형식으로 진행하기에는 어려움이 있을 것 같습니다.

drupal 자체의 성능을 향상시킬 수 있는 패치를 메인 소스트리에 반영할 경우에 대한 현상금 혹은 그에 상응하는 보답은 가능할 것으로 생각됩니다. 좋은 방안이 있으면 의견 주세요...

dormael의 이미지

저두 최근에 일하면서 db와 관련된 튜닝(mysql 전문 업체의 도움을 받았습니다) 작업을 했었던 적이 있는데 여러가지 요소를 고려해야 하는것 같습니다.

우선 현재 DB서버의 로드가 어느쪽에 가장 많이 걸리는지가 관건인데 보통 빈번한 억세스가 있는 큰 테이블이면 IO가 제일 심하겠죠. 저의 경우도 실제로 그랬구요. 뭐 제 경우야 스토리지가 워낙 빠방했어서(지금까지 저의 경험 안에서) 여기서는 더이상 업그레이드 할만한 요소가 없었고, 그래서 서버 메모리를 처음 2G에서 16G로 늘렸습니다. 물론 이를 제대로 쓰기 위해 하드웨어, OS를 다 64비트로 옮겼구요. 그리고 버퍼 메모리를 한 8기가 정도로 잡은것 같습니다.

row의 사이즈가 그리 크다고 할 순 없지만 그래도 갯수가 천만건 정도 되는 상황이었거든요.

select도 많지만 insert, update, delete가 많은 상황이어서 테이블 타입도 innodb로 바꿨습니다.

글고 무시 못할것이 insert, update, delete가 많은 경우 bin로그도 장난이 아니더군요. 그래서 binlog를 로컬 스카시 하드로 옮겼구요. 참, 테이블 스페이스는 광채널을 EMC장비에 물려 쓰는데 저는 본적이 없어서 어떤식으로 구성된건지는 잘 모르네요. ^^

슬로우 쿼리에 가장 많이 등록되는 쿼리를 찾아서 쿼리 튜닝 혹은 아예 그 쿼리를 다른 방식으로 바꿔 쓰는 방법을 썼습니다.

그 후에 전문 업체의 도움으로 쿼리 튜닝, 인덱스 최적화 등을 했고, 현재는 많은 퍼포먼스 향상이 있어서 아직은 서비스가 잘 돌구 있습니다.

여담이지만 mysql 5.0.20 이전 버전에서는 헤비로드시 binlog가 flush시(다음 로드파일로 넘어갈때 포함) 데드락 걸리는 버그가 있었습니다. 이것땜에도 한참 고생했던 기억이.. ㅋㅋ

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

소타의 이미지

drupal이 pgsql도 지원하던데 -.-;
예전 bbs.kldp의 수십만건의 자료들이 모두 이전되어 데이터 사이즈가 클것인데요
이럴 경우 pgsql의 비트맵 인덱스와 Partial인덱스가 큰 성능 향상을 줄 것입니다.. 특히 복잡한 쿼리에서는 다른 DBMS에 비해 좋은 성능을 보여줍니다
현재 drupal은 플러그인의 종류에 따라 답글이 많이 달린 게시물 조회시 쿼리를 거의 백번 가까이 할 수도 있다고 들었습니다; 하드웨어 성능도 좋아야 하겠지만 소프트웨어 적인 튜닝 없이는 데이터가 늘어나면 앞으로 같은 문제가 야기될 것 같습니다 -.-

1day1의 이미지

하드웨어 업그레이드 뿐만아니라 DB 자체의 튜닝도 필요할 듯 합니다.
소타님 말씀처럼 pgsql 로 이전 (전문가의 손이 필요하겠지만) 도 고려해 볼 수 있을 것 같습니다.

F/OSS 가 함께하길.. (F/OSS서포터즈,F/OSS서포터즈그룹)

F/OSS 가 함께하길..

김정균의 이미지

DB 에 관한한 가장 문제가 되는 부분은 inner join 의 남발 입니다.
순선님 말씀대로 H/W 업데이트도 도움이 될 겁니다. 하지만 가장 중요한 것은 DB migration 입니다. DB 에서의 문제는.. query 를 백번 하는 것도 문제가 되지는 않습니다. 중요한 것은 inner join 을 하는 쿼리는 site 를 막고 혼자 널널하게 던져도 4초 정도가 걸리는 질의 들이 있다는 것이죠.

Drupal site 와 비교를 많이 하시는 듯 한데, drupal 과 kldp 의 상황을 비교하는 것도 무리이고, drupal 에서 kldp 에서 사용하는 모듈들을 그대로 사용하느냐도 문제가 될 수 있습니다. 현재 가장 문제가 되는 부분은 forum list page 쪽과 글 등록 부분이니까요.

다만.. 4.7 에서는 성능이 좀 좋아지기는 한 듯 싶습니다. 4.6 에서 도저히 견디지 못해서 막아 놓은 기능이 4.7 에서는 현재 풀려서 작동 중인데, 4.6 처럼 부하가 걸리지는 않고 있으니까요.

DB 서버의 부하 때문에 발생하는 문제는 아니지만, 널널한 상태에서의 query 가 4초 정도 걸려야 한다면, 서버성능을 올림으로서 migration 을 할 수 있는 부분이기도 합니다. 업체에서 이런 일을 할 경우라면, 돈을 바른다는 표현을 쓸 수 있을 것이고, KLDP 의 입장에서는 돈을 바르기도 힘들고, db tunning 을 해 주겠다는 분도 나타나지 않으므로 순선님 입장은 좀 난감할 것 같습니다. (제가 해 드리고 싶지만.. 저도 DBA 수준은 아니라서.. ^^)

dormael의 이미지

저도 DBA는 잘 모르지만...

inner join 하는 쿼리들이 돌때 디스크에 임시 테이블을 만드는 상황인가요?
join을 위해 쓰레드(혹은 프로세스)들에 충분한 크기의 메모리가 할당되어야 할 상황인지 궁금하네요.

혹시 김정균님께서 그 가장 문제가 되는 쿼리를 돌릴때 상황을 자세히 알려주시면 누군가 도움이 될 수 있지 않을까 생각이 됩니다. 물론 이미 다 체크해 보셨을수도 있지만요.. 혹시라도...

만일 디비에 할당된 메모리에서 테이블 버퍼를 줄이고 저 쓰레드들의 버퍼를 늘이면 어떨까 해서요..

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

김정균의 이미지

4.7 상황에서는 query 분석을 해 보지 않아서 잘은 모르겠습니다만 4.6 상황에서는 inner join 시에 임시 테이블을 만들 정도는 아니었습니다. (메모리에서 처리가 가능한 사이즈로 보입니다. 메모리가 4G 정도 되니..)

또한 해당 쿼리는 primary index 를 타지는 않지만 분명히 index 는 타고 있는데 별 효과가 없는 것 처럼 보이더군요. 제가 DBA 에 관한 지식이 깊지 않아서 이부분은 좀 이해를 못하겠습니다. 제가 index 를 타는 것으로 오해를 하는 것인지.. 분명 help 로 query 를 날려 보면 index 를 타는 것 처럼 나오기는 하는데 말이죠.

또한, join 을 하면 memory caceh 를 타지 못하기 때문에, 이 또한 성능 저하에 많은 기여를 할 수 밖에 없을 것이라 생각을 하기는 합니다. ^^;

그래서 DBA 분들의 도움을 받았으면 하는거죠. hint 를 이용하거나 (mysql 에서 hint 가 지원되는지는 모르겠지만..^^)

ydhoney의 이미지

통화한데로..:-)

연락은 다음주중에 다시 한번 하도록 하죠 ^^

ydhoney의 이미지

현재 문제가 되는것들이 DB I/O쪽인지 쿼리 부분 문제인지 트랜젝션 문제인지를 어느정도 정리를 해 주세요.
각 요구사항에 따라서 분명 사양이 달라질테니까요.

소타의 이미지

올.. 야동꿀님이 장비 대주는겨?
하긴! bbs 시절에 하드 마니 까먹었을터 ㅋㅋㅋ

김정균의 이미지

DB query 문제인 듯 싶습니다. 트랜젝션은 뭘 의미하는 거죠? db 트랜젝션 은 아닌 듯 하고, 머 MyISAM 을 사용하니 db 트랜젝션 은 사용하지 않고.. 어떤 트랜젝션을 말씀 하시는 것인지요?

리소스 사용률상으로 문제가 되어 보이지는 않습니다. cpu 나 memory, I/O 부분의 부하도 거의 없는 편입니다.

시스템 업그레이드로 기대하는 효과는 부족한 리소스를 보충하기 위함이 아니라, 처리 속도의 향상으로 인한 단축을 기대하고 있습니다. 이건 제 개인적으로 시스템 업그레이드의 필요성을 주장해 보는 것이고, 순선님의 생각은 어떠한지는 모르겠습니다. 어쩌면 순선님이 보는 부하의 방향이 저와 다를 수도 있기 때문에.. 또한, 순선님하고도 이 부분에 대해서 제대로 대화를 하지 못한 점도 있습니다. ^^;

P.S
아.. 혹시 서버에 remote console 기능 같은 것을 지원해 주실 수 있으면 백골난망 하겠군요. IDC 가려면.. 너무 힘들어서.. -.- 무서워서 리부팅을 못하겠다니까요 T.T

dormael의 이미지

제가 전에 같이 작업한 DBA분께 물어볼수 있게 간단한 자료라도 주실 수 있을까요?
쿼리랑 EXPLAIN결과정도면 될지 모르겠는데.

우선 그 응답이 많이 느리다는 쿼리 하나만이라도 확인해 보겠습니다.

EXPLAIN결과가 데이터 양에 따라서도 변해서 가능하면 덤프 데이터가 있으면 좋겠지만 그게 안된다면 EXPLAIN 결과 만으로라도 의심하시는 부분을 확인해 보겠습니다.

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

권순선의 이미지

소타/ pgsql보다는 mysql에 익숙하신 분들이 더 많기 때문에 도움을 받을 수 있는 확률도 그만큼 높아지고, 무엇보다도 drupal에서 아직 pgsql을 mysql만큼이나 잘 지원하고 있는 상태가 아니랍니다... 모듈들만 봐도 mysql에서만 테스트되는 경우가 대부분이거든요. '정말로' mysql이 한계라는 결론이 난다면 그때 가서 다른 대안으로 pgsql도 같이 고려하겠지만 당장은 어려울것 같습니다. 감사합니다...

김정균/ 예 맞습니다. 기본적인 처리 속도의 향상을 기대하는 것입니다. 현재 사용중인 서버의 리소스가 부족한 것 같지는 않습니다. remote console기능은... 이번 LWCE에 다즐링님이 부스 지킴이로 오실 텐데 그때 확인해서 넣을 수 있도록 하겠습니다. IDC에 잠시 다녀오는 것도 한 방법이 되겠죠... 저도 리부팅을 하고 싶을 때가 있는데 겁이 납니다. -_-

dormael/ 감사합니다. 정확히 어떤 데이터를 어떻게 뽑아서 드리면 될까요? explain???

그리고 첨부는 현재 KLDP DB 서버에서 사용중인 mysql 설정 파일입니다. (김정균님 작성) 현재 KLDP DB 서버의 사양은 Xeon 3G dual / 2GB RAM 입니다. 이점 참고하셔서 혹 성능 향상을 위해 수정할 수 있는 부분이 있다면 어디를 어떻게 수정해야 하는지 알려 주시면 대단히 감사드리겠습니다.

권순선의 이미지

음... 속도가 조금 빨라진 것 같지 않나요? 제가 뭔가 작업을 좀 했는데 웬지 빨라진 것 같아서 테스트 겸 써 봅니다.

1day1의 이미지

느낌상인지 모르겠지만, 조금 속도가 향상된 것 같습니다.

F/OSS 가 함께하길.. (F/OSS서포터즈,F/OSS서포터즈그룹)

F/OSS 가 함께하길..

ydhoney의 이미지

확실하게 정리할 것 한가지..

서버를 완전히 신규도입을 하시기를 원하시는건가요?
아니면 있는거에서 사양만 어떻게 좀 더 올려보자는건가요?

원래 제가 생각하던건 신규도입이긴 한데..
왠지 후자가 더 싸게 먹힐듯 해서;; -_-

아무래도 싸게 먹히면 동일한 금액이라고 생각하고 보자면 아무래도 신규 서버 도입보다는
좀 더 높은 사양으로 올리는것이 가능하지 않을까 하는 생각이 드네요.

뭐 DB서버를 두대를 운용하겠다면야 상관은 없겠지요.
(DB서버 LB할려면 좀 골치아픈게 생기겠지만;;)

권순선의 이미지

신규도입을 고려하고 있습니다. 기존 것을 업그레이드하면 메모리 업그레이드 정도밖에 안될 것 같습니다. 1u 서버라 업그레이드/부품교체의 여유가 그다지 충분하지 않을 듯 합니다.

ydhoney의 이미지

왜 종종 여러번 다시는 분들이 계신가 하고 보니가 댓글쓰기 눌러도 아무반응 없을때가 있군요 -_-

권순선의 이미지

반응이 없는 것이 아니라 오래 걸리는 것입니다. 그래서 db 서버 업그레이드가 필요한 것이죠. :-)

dormael의 이미지

네, 제가 느끼기에도 조금 빨라진것 같습니다.

아 권순선님 우선 김정균님이 말씀해주신 로드가 없을때도 3-4초 걸린다는 쿼리가 있다면 그 쿼리의 EXPLAIN결과부터 알려주셔야 합니다. 그렇게 심한 쿼리가 자주 불리면 다른곳에 영향을 많이 줄 테니까요.

문제가 한가지가 아닐수도 있지만 로드가 제일 심한것을 제거하면 슬로우 쿼리들이 많이 없어지기도 하거든요.

그리고 가능하면 시스템 모니터 한 정보를 알 수 있으면 좋겠네요. 너무 두리뭉실한 얘기이긴 하지만 상세하면 할수록 좋습니다.
저같은 경우는 mysqladmin의 processlist에서 Sleep만 제거하구 5초단위로 캡쳐해서 체크했습니다.
그리고 김정균님께서 OS 모니터 하신 결과도 있으면 좋습니다. 우선 응답이 느릴때 TOP의 load average와 vmstat결과 값이 정보가 될 것 같습니다.

글고 mysql모니터 하는 툴이 있으면 버퍼(캐시)히트를 알 수 있으면 좋겠지만 없으면 show status결과도 도움이 될것 같습니다.

경우에 따라서는 더 많은 정보 혹은 접근 가능한 계정이 필요할 수도 있구요.

근데 개인적으로 김정균님 말씀을 듣고 생각 나는게 혹시 processlist에서 lock을 wait하는 것들이 많은가요?
시스템 자원 wait이 별로 없는 상황에서 지연이 발생하는 거라면 가능성이 있어보여서요.

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

1day1의 이미지

관리자 분께서 DBA 가 아닌관계로 구체적인 명령도 같이 알려주시는 것이 좋을 듯 합니다.

F/OSS 가 함께하길.. (F/OSS서포터즈,F/OSS서포터즈그룹)

F/OSS 가 함께하길..

권순선의 이미지

예... mysql에 대해서 전혀 모르는 사람이 조작한다고 생각하시고 설명하여 주시면 감사드리겠습니다. 아니면 아예 이 작업을 위한 짧은 강좌(?)를 하나 쓰시는 것도 좋을듯...그러면 다른 분들도 참고해볼 수 있겠지요. 이런 경우는 많을 테니까요. 제목은 "mysql 튜닝을 위한 점검 사항 및 점검 방법" 정도면 되지 않을까요. :-)

김정균의 이미지

대표적인 경우는

# Time: 060521 1:58:48
# User@Host: junseo[junseo] @ [210.118.94.78]
# Query_time: 4 Lock_time: 0 Rows_sent: 19 Rows_examined: 542501
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 = 0 OR c.status IS NULL)
WHERE n.status = 1 AND (n.uid = 7289 OR c.uid = 7289) ORDER BY last_post DESC LIMIT 0, 25;

와 같고요. 이 부분은 drupal 소스와 같이 보셔야 할 듯 싶습니다. 어떤 기능에서 이런 query 를 사용하고 있는지.. 등등 과 연관이 될 수 있겠죠.

위의 explain 결과는 다음과 같습니다.

+----+-------------+-------+--------+-------------------------------------+---------+---------+--------------+-------+---------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+--------+-------------------------------------+---------+---------+--------------+-------+---------------------------------+
| 1 | SIMPLE | l | ALL | PRIMARY | NULL | NULL | NULL | 70132 | Using temporary; Using filesort |
| 1 | SIMPLE | n | eq_ref | PRIMARY,status,uid,node_status_type | PRIMARY | 4 | junseo.l.nid | 1 | Using where |
| 1 | SIMPLE | u | eq_ref | PRIMARY | PRIMARY | 4 | junseo.n.uid | 1 | Using where |
| 1 | SIMPLE | c | ref | lid | lid | 4 | junseo.n.nid | 6 | Using where; Distinct |
+----+-------------+-------+--------+-------------------------------------+---------+---------+--------------+-------+---------------------------------+

저도 소스를 보지 못한 상태라. 이 query 가 단순히 slow 가 된 경우인지, 항상 slow 를 유발하는 경우인지는 확인은 못했습니다. ^^;

processlist 에서는 4.6 상에서는 lock 이 되는 경우는 거의 없었고, 4.7 상에서는 검색 기능이 들어가면서, search_total 에 update 를 할 때 오랜 시간 lock 이 되는 경우가 있습니다. 그래도, 보통 processlist 가 5개 내외로 리스팅 되기 때문에 부하를 유발할 일이 있지는 않을 듯 싶습니다.

inner join query 가 들어올 경우에는 Sending data 나 Copying to tmp table 과 같이 임시 테이블을 생성하는 경우가 보이기는 하지만, 이 작업도 금방 끝날 경우가 많습니다. 모든 join 이 문제가 된다는 얘기는 아니겠지요.

저 역시 mysql 무지한 편은 아니지만, 현재의 문제는 drupal 의 설계 문제이므로, 아무래도 db 차원에서 제가 할 수 있는 단계를 넘어서는 지라.. 저도 좀 막막합니다. ^^;

일단 가장 확실한 방법은, drupal 의 모듈을 이용하여, sql time 을 측정하여, 문제가 되는 query 부분을 확인하여 db 쪽에서 확인하는 것이 답일 듯 싶습니다.

순선님.. 예전에 sql time 측정하던 기능을 dormael 님 계정에서 출력 하도록 해 주시고, db query 분석을 할 수 있는 방법을 제시해 주는 것이 어떨까요? db 는 read only 권한으로 http://dbgw.kldp.org 의 Web interface 를 이용하도록 하시면 될 것 같은데요.

권순선의 이미지

dormael 님과 김정균님에게 매 페이지마다 db 쿼리 상세 정보를 보실 수 있는 권한을 부여해 드렸습니다. 이게 devel 모듈인데 아직 4.7용으로 릴리즈가 안된 놈이라 좀 꺼림칙해서 사용하지 않고 있었는데 지금 보니 큰 문제 없이 잘 돌아가는 것 같습니다. :-)

익명 사용자의 이미지

만일 동일하거나 거의 동일한 쿼리가 자주 발생한다면, 어플리케이션 층에서 간단한 캐시 기능을 넣으면 최초 1회만 느리고 그 이후는 빠르게 응답하도록 할 수도 있습니다. 구체적으로 느리다고 생각되는 쿼리들의 예와 언제 그 쿼리들이 발생하는지 알수있나요?

ydhoney의 이미지

단순히 이럴 것 같다 가 아니라 서로간에 뭔가 좀 더 명확하게 알 수 있는 정보가 필요하면 요청하고,
알려줄 수 있는게 있으면 알려주고 해서 명확한 원인을 얼른 찾아냈으면 좋겠습니다.

저야 뭐 오라클밖에 몰라서;; =3=33

ydhoney의 이미지

아 지금은 또 다시 반응이 많이 느리군요;; -_-

stadia의 이미지

mysql 의 로그 중에 slow-query 로그에 자주 등장하는 놈들을 잡아서
디비 콘솔에서 explain 그쿼리 해서 나오는 결과값을 dormael 님에게 전해드리면 되겠네요.

gbkwon의 이미지

동접이 많은 경우 그리고 select, insert, update, delete 등이 빈번하게 일어나면..

일반적으로 테이블 타입은 InnoDB를 사용하는게 좋을 듯합니다.

MyISAM 은 insert, delete, update 시 혹은 select 시에도 테이블 전체에 락이 걸릴수 있어

간단한 쿼리인데도 불구하고 다른 쿼리의 락킹 때문에 간단한 쿼리가 slow query 가 되어 버리곤 합니다.

정확히는 이 경우에 맞다고 할수는 없으나(저도 drupal을 사용해 보지 않아서..)

제 경험상 이런 부분이 충분히 있을 수 있다고 봅니다..

100개의 select 만 있다면 문제 될것이 없으나 100개의 select 랑 1개의 insert 가 있음면 insert 뒤에 온 select는 insert 가

끝날때 까지 모두 기다려야 된다는게 현재의 MyISAM이라고 알고 있습니다.

low level lock 를 사용하기 위해서는 InnoDB 타입의 테이블을 사용해야 한다고 알고 있습니다.

dormael의 이미지

지금 바로 눈에 보이는 쿼리가 있습니다.

Using filesort

이렇게 되면 소트시에 임시파일을 사용하기 때문에 io오버헤드가 발생합니다.
쿼리가 아닌 db서버상으로 이 문제를 해결하려면 sort_buffer_size 값을 늘려줘야 합니다.

Using temporary도 약간 의심은 되지만 위의 설정을 우선 늘린후에(테스트 서버 하나 두고 데이터 그대로 덤프 뜬 후에 값을 늘려가며 테스트 하면 됩니다.)

Using temporary도 약간 의심은 가지만 우선 filesort는 절대 일어나지 않게 해야할 것 같습니다.

제 생각에도 권순선님, 김정균님과 빠르게 연락할 방법을 찾아서 바로바로 진행할 수 있었으면 좋겠습니다.

근데 지금 글 쓰는 시간을 보시면 아시겠지만 제가 주말에는 야행성이라 시간이 잘 맞으면 좋겠네요.
아님 월요일날 회사에서라도.^^

연락처나 메신저 주소같은걸 dormael at gmail dot com 으로 보내주시면 제가 일어나는대로 연락 드리도록 하겠습니다.

저녁형 인간이라 죄송합니다. ㅡ,.ㅡ

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

dormael의 이미지

MyISAM의 테이블수준 락 때문에 업데이트(insert, update, delete)가 빈번한 테이블이라면 InnoDB도 충분히 고려대상입니다.
저의 경험에서 심지어는 돌고있는 서버에서 인덱스가 깨져서 리빌드 한다는 메시지도 보았으니까요.
하지만 MyISAM이 지원하는 모든 기능을 InnoDB도 지원하는 것이 아니라 바꾸기 전에 확인해야 할 사항들이 있습니다.

우선 제가 아는것만 해도 조건없는 COUNT(*)의 부담과 Fulltext Index의 미지원이 있습니다.
COUNT(*)함수가 실제 모든 row를 세는 작업을 하기 때문에 row의 갯수가 계속 늘어나는 환경에서 이 함수를 많이 사용하면 오히려 더 역효과가 발생합니다.

그리고 튜닝(쿼리+시스템) 작업이라는게 문제점을 찾아 하나하나 조절을 해야하는 것이라서 지금 당장 방법을 올리기는 어려울것 같습니다. 제가 DBA는 아니라 경험이 부족하거든요.

우선 작업은 제가 할수 있는 부분은 제가 하고 더이상 어려운 상황이라면 제가 알고있는 DBA분께 부탁하도록 하겠습니다.

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

김정균의 이미지

운영적인 입장에서는 (성능을 제외한..) innodb 의 사용은 자제하고 싶습니다. innodb 는 db 를 전문적으로 관리를 해 주실 분이 있을 경우에나 생각하고 싶습니다. ext3 의 성능이 어정쩡 하지만 가장 무난하다는 이유로 ext3 가 가장 널리 사용되는 것 처럼, MyIsam 이 innodb 보다 성능이 못할지는 모르겠지만, 제가 db 전문가가 아닌 입장에서 innodb 보다 MyIsam 의 관리/운영/튜닝에 대한 정보를 더 많이 가지고 있기 때문에 MyIsam 이 선호되는 이유 입니다. ^^;

dormael의 이미지

김정균님 밑에 쿼리중에 좀 심하다 싶은것을 확인해 보니 cache, comments 테이블이 모두 들어가 있습니다.

우선 comments테이블에 (pid, status)로 잡힌 인덱스가 있는지 확인해 주세요. 순서도 일치해야 합니다. 뒤에 더 붙어도 상관 없구요.

그리고 현재 cache, comments 테이블의 row갯수도 필요합니다.

drupal 관리에 캐시설정같은게 있나요?

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

권순선의 이미지

cache 의 역할은 익명 사용자로부터 오는 쿼리 결과를 담아 두는 것입니다. 따라서 익명 사용자가 접속하게 되면 새로 쿼리를 날리는 것이 아니라 기존에 쿼리 결과를 그대로 사용하는 것이며, 이 기능은 현재 사용 중입니다. 만약 사용하지 않음으로 설정하면 익명 사용자가 접속해서 돌아다닐 때에도 모든 쿼리를 일일이 날려서 결과를 가지고 옵니다. 이 기능은 익명 사용자에게만 해당되며 등록 사용자는 cache 를 사용하지 않습니다.

4.6에서는 이 기능을 단순히 사용할 것이냐, 사용하지 않을 것이냐 두가지 선택만 있었는데 4.7에서는 최소 캐쉬 수명을 지정할 수 있어 지정한 시간 동안은 무조건 cache에 있는 것을 사용하게 됩니다. 방금 최소 캐쉬 수명을 15분으로 연장하여 설정하였습니다.

감사합니다....

atie의 이미지

node_comment_statistics 테이블에서 정렬에 사용되는 last_comment_timestamp와 (join을 하지 않기 위하여) comment_count 두 컬럼을 node 테이블에도 넣어 저 sql처럼 ORDER BY last_post를 -동적으로 node와 node_comment_statistics를 join하여 정렬하는 것을- 없애겠습니다. 테이블의 이름을 봐서는 node에 comments가 쓰여질 때 1:M의 관계를 유지하고 통계에 대한 것은 node_comment_statistics로 따로 쓰는 것 같은데 위의 두 컬럼을 node에도 항상 최근 것으로 업데이트 하는 방식을 택하면 위의 문제가 되는 sql에서는 node에 있는 두 컬럼을 가지고도 인덱스를 쓰는 정렬을 할 수 있으니 성능 개선이 있을 듯 합니다.

따라서, 위에 정균님이 이야기 한 것이 언뜻 공감이 되는군요.
----
I paint objects as I think them, not as I see them.
Ubuntu Dapper user / Ubuntu KoreanTeam / Lanuchpad karma 16289

----
I paint objects as I think them, not as I see them.
atie's minipage

dormael의 이미지

김정균님

그리고 EXPLAIN결과 자세히 보니 node_comment_statistics 테이블에서 아무 키도 타지 않네요.
이 쿼리가 최근글보기 목록 같은데 실행속도가 정말 많이 느리네요.
우선 위에 말씀드리 소트버퍼를 늘려주고 쿼리도 체크해 봐야 할것 같습니다..

가능하면 쿼리에는 손을 대고 싶지 않았는데. ㅡ,.ㅡ
제가 경험이 많은게 아니고 drupal 업데이트 시에 또 문제가 발생할 수가 있어서요.

글고 무엇보다 쿼리 최적화(쿼리수정 혹은 인덱스 변경/추가)는 여러가질 바꿔가며 테스트 해봐야 해서요.
작업 시간도 오래걸리고 운영중인 서버에선 할 수 없는 작업이라서요.

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

dormael의 이미지

제가 걍 하루 제낄거 같아서 우선 권순선님께 메일로 전화번호를 남겼습니다.
김정균님은 메일을 보낼수 없다고 나오네요. ㅡ,.ㅡ

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

권순선의 이미지

메일 잘 받았고요... ^^;

김정균님에게도 포워딩해 드렸습니다. 제가 지금 아기 보러 처가집에 다녀와야 해서 지금부터 밤까지는 인터넷에 접속할 수 없습니다. dormael님께 계정을 아예 하나 발급해 달라고 요청드렸는데 서버 관리를 정균님께서 하시기 때문에 적절히 판단하실 것입니다. 저도 방금 깨서 지금 나가는 중이고, 정균님도 지금은 주무시고 계시지 않을까 합니다. 정오때까지 연락이 없으면 제게 전화 주세요. (016-535-7282)

그럼... 저는 이만 나갑니다.... 와이프가 빨리 나오라고 성화네요. -_-;;

kkj의 이미지

리플리케이션이랑 클러스터링은 용도가 다르죠.
웹사이트 db를 리플리케이션보다 클러스터링으로 돌리겠죠
정상적이라면

dormael의 이미지

김정균님 제가 인덱스 추가/변경 테스트를 하려면 운영에서는 안될것 같고, fulldump뜬 데이터를 가져와서 해야하거든요.
그냥 전체디비 풀 덤프 뜨신후에 그 파일에 제 계정으로 읽기 권한을 주시면 제가 가져와서 테스트 해보도록 하겠습니다.

위에 주신 쿼리가 disk 임시 테이블이 아닌 memory 임시 테이블에서 돌도록 임시 테이블 사이즈를 늘렸습니다.

다른 부분의 로드는 거의 없는데 이 쿼리가 돌면 /tmp 에 46메가 짜리 임시 파일이 생겼다 없어지더군요.
이게 프로세스 점유율을 많이 잡아먹는것 같습니다. 메모리에서 돌도록 해도 점유율은 마찬가지네요. ㅡ,.ㅡ

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

mirr의 이미지

물론 Mysql에서의 리플리케이션기능이 만족스럽지 못하고 미비한건 사실이나,
상용 디비 및 최상의 버젼의 Mysql이 아닌 상태에선 (대략 4.0정도버젼대)
그나마 한숨 덜어주는건 사실입니다.
리드, 라이트 디비를 두고 거기서 또 리플리케이션을 이루면 (최소 약 3대정도)
하루 페이지뷰 백만이 넘으며(잘못써서 수정합니다 ㅡ.,ㅡ::) 회원수가 600만이 넘는 사이트도 큰 무리 없이
웹서비스를 이용 할 수 있습니다.

물론 insert, update 등의 쿼리를 자주 요청 하는 싸이트에서도 적용 되는 내용이지요...

하지만 결과적으로 가장 좋은 방법은 클러스터링의 기능이 정확하게 지원되는 것이 안전하고 좋겠죠..
현재 Mysql의 리플리케이션은 단지 동기화, 및 실시간 복제서비스의 개념이 더 강하니 말이죠...
그나저나...KLDP에서도 디비문제로 고민중이신데, 저희 회사역시도 디비량이 엄청나지면서
디비 튜닝쪽으로 골머리 앓고있습니다...계속 주시해 가면서 많이 배워갈 수 있음 좋겠네용...
저또한 도움이 될 수 있으면 좋겠구요....^^

내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.

내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.

dormael의 이미지

ALTER TABLE comments ADD INDEX index_comments_count(pid, status);

위의 인덱스를 추가해서 게시물 읽기 페이지의 딜레이를 줄였습니다.
문제가 되었던 쿼리는 SELECT COUNT(cid) FROM comments WHERE pid=? AND status=? 였습니다.

현재 최근글 목록 쿼리(위에 김정균님께서 explain 해주신)를 가능하면 쿼리에 손 안대고 인덱스만으로 최적화 해야 하는데 저 쿼리가 무조건 임시 테이블을 만들어 버리네요. ㅡ,.ㅡ

혹시 도와주실 분 계신가요? 도와주셈~~~~~~~^^

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

dormael의 이미지

한참 헤메다가 생각해 봤는데 DISTINCT(n.nid) 이거 그냥 n.nid로 바꿔도 되지 않을까요?

n.nid는 PK인데. ㅡ,.ㅡ

그냥 DISTINCT만 빼고 돌리니 인덱스 잘 타고 그래서 속도 빠릅니다. 어찌해야 할까요?

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

dormael의 이미지

쿼리 돌린 결과랑 http://kldp.org/tracker 웹페이지 결과랑 같은거 같은데. ㅡ,.ㅡ

DINSTINCT한 이유가 뭘까요? ㅡ,.ㅡ

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

익명 사용자의 이미지

> 쿼리 돌린 결과랑 http://kldp.org/tracker 웹페이지 결과랑 같은거 같은데.
> DINSTINCT한 이유가 뭘까요? ㅡ,.ㅡ

inner/left join 결과 중복이 발생할 수 있기 때문이겠죠. 만일 중복이 발생하지 않는다면(운이 매우 좋은 경우), 없어도 되겠죠.

dormael의 이미지

그냥 저 쿼리가 있는 tracker.module이라는 파일을 찾아서 쿼리 수정했습니다.
ㅡ,.ㅡ

모든 최근글에만 해당됩니다.

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

mirr의 이미지

이런 엄청난 체감속도 향상 효과는 뭐죠????
글쓰기도 꽤나 빨라졌군요....
제가 지금 KLDP에 와있는거 맞는거죠? :)

내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.

내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.

dormael의 이미지

drupal이 4.7만 그런건지 모르겠지만 디비 스키마나 tracker모듈쪽의 쿼리들이 현재 KLDP정도의 규모에선 잘 돌기 힘든 상황으로 판단됩니다.

이제 '나의 최근글 목록'을 손봐야 할것 같은데, 자꾸 손 댈수록 위의 의문이 듭니다.

첨에 최근글 보기 쿼리의 응답시간이 12초가량 걸렸는데, 몇개 테이블 풀스캔후 임시 테이블에 넣고 소트하는 과정에서 디스크 임시 파일을 이용합니다. 최악이었죠.
그래서 우선 메모리 임시 테이블의 크기를 늘렸더니 4-5초 정도의 응답시간이 나왔습니다. 이에 만족하지 못하고 결국 일을 저질러 버렸죠. 쿼리 수정. ㅡ,.ㅡ

빨라진건 임시테이블을 쓰지않고 인덱스 따라 돌기 때문입니다.

현재 KLDP의 DB서버 시스템 자원은 아~~~~~~~주 널널한 편입니다. 생각보다 동시 접속자가 적습니다.

흑...

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

dormael의 이미지

아, 위에 김정균님께서 올려주신건 나의 최근글 목록이었군요.

중복이 발생하겠네요.

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

익명 사용자의 이미지

결국, drupal의 db 설계와 application에서 db를 사용하는 방법 사이에 문제가 있는 듯 하군요. production 시스템에서 계속 여기저기 손대는 것 보다는 동일하거나 유사한 환경으로 테스트 머신 셋팅해서 수정하여 문제가 모두 해결된후 production 시스템에 적용하는 것이 좋을 것 입니다.

이같은 문제는 하드웨어가 좋더라도 언젠가 발생할 수 있는 문제이므로 db설계 and/or application의 db 사용 방법을 수정하는 것이 맞는 듯 한데, 문제는 시간과 돈이 겠네요. 잘 해결되길 바랍니다.

권순선의 이미지

제가 아직 dormael님이 올리신 글을 모두 읽어보진 않았는데 속도가 많이 향상된 것 같습니다!

변동사항을 잘 기록해 두었다가 drupal.org 에 보고해서 다음 버전에 적용될 수 있도록 하는 것이 꼭 필요하겠습니다. 대강 정리가 되면 dormael님과 김정균님 등과 함께 미팅을 한번 가지고 무엇이 문제였고, 무엇을 고쳤으며 side effect 등은 없는지 등에 대해서 확인한 뒤에 drupal.org 에 보고할 내용을 추려서 보고할 수 있도록 했으면 합니다.

dormael님, 김정균님, 대단히 수고 많으셨습니다. 부디 좋은 결과 있기를~~~

wariua의 이미지

페이지 뜨기를 기다리며 지뢰찾기 하는 즐거움이 있었는데 dormael님과 김정균님 덕분에 그 즐거움이 사라져 버렸습니다 :-)

평일의 피크 시간대에도 이 정도의 성능이 나올지는 내일까지 기다려 봐야 알 수 있겠지만, 지금으로선 굉장히 쾌적하고 또 쾌적합니다. 이제 새로운 모듈 추가나 기능 활성화를 고려하는 데 있어서도 상당한 여유가 생기겠네요. dormael님과 정균님, 벌꿀님, 순선님, 모두 짝짝짝입니다~
----
$PWD `date`

$PWD `date`

dormael의 이미지

나의 최근글 가져오는 쿼리입니다.
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 = 0 OR c.status IS NULL)
WHERE (n.status = 1 AND n.uid = 2264) OR (n.status = 1 AND c.uid = 2264) ORDER BY last_post DESC LIMIT 0, 25;

이걸 아래와 같이 바꾸어 봤는데. 결과는 일치하는것 같습니다. 응답도 바로 나옵니다. 문제는
db버전이 바뀌거나 다른 디비로 바뀌었을때 잘 돌것이냐? 입니다. 제가 JOIN과 UNION에 대해서는 완전 무지하다고 보셔도 됩니다.
욕해주세요. ㅋㅋ

답글 달아주세요..

ALTER TABLE comments ADD INDEX uid(uid); // 코멘트에 인덱스 필요해서 추가후

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=2264 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 = 2264 AND l.nid = n.nid AND u.uid=n.uid
)zz ORDER BY last_post DESC LIMIT 0,25;

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

stadia의 이미지

합쳐 버릴 2개의 셀렉트에서 컬럼을 명시했는데 합친 결과를 뽑는 부분에서는 * 로 해버려서 약간 아쉬운 감이.

dormael의 이미지

아 stadia님 제가 저 부분을 어떻게 해야할지 잘 몰라서 우선 *로 했습니다. ^^
alias를 주고 위에서도 그걸로 명시해 줘야 할까요?

지금현재 '나의 최근글보기'도 위의 쿼리로 수정했습니다.

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

권순선의 이미지

음... http://kldp.org/node/70271#comment-332721 에 스팸으로 새로운 글이 올라왔는데 최근글 보기에서는 보이지 않습니다. 이 현상은 크게 두가지 문제가 있습니다.

- 분명히 익명 사용자의 답글은 바로 게재되지 않고 리뷰를 거친 후에 게재되도록 설정되었는데 이부분이 제대로 동작하는지 확인이 필요합니다. 일단 이부분은 익명 사용자가 아예 답글을 달지 못하도록 설정을 바꾸어 버렸습니다.

- 최근글 보기의 루틴이 변경되어 이런 답글을 잡아내지 못하는 것인지 확인이 필요합니다.

권순선의 이미지

한가지 문제가 더 있는 것 같습니다. 분명히 읽은 답글인데 최근 글 보기에서는 읽지 않은 새 답글로 표시되는 경우가 있습니다. 저만 그런가요?

ydhoney의 이미지

저는 그건 예전부터 종종 있었던것 같은데요?

nonhyo의 이미지

가장앞선 생각 전라도 네트워크 전라넷 운영자입니다.

제가 아는 지식을 보태 볼까 합니다.


효율적인 하드웨어의 구성은

응답 딜레이를 적게 즉 빠른 응답속도에 있다고 생각합니다.

머리하나 또는 네개에 손발이 하나씩이면 효율은 몹시 떨어 집니다.

머리는속도가 빠른데 손발은 느리기때문에 지연이 발생 당연히 느려집니다.

이때는 손발은 늘려야 하며 기능에 맞게 작업을 분배해주어야 합니다.

손(하드디스크) 발 (네트워크라인)

보통 한대의 컴퓨터에 네트워크 1~2라인 하드디스크 한두개정도인데

손 3~4개 발 2~3개 정도를 만들어서 운영해주시면 적절한 최소 조건이 됩니다.

운영체제와 서버별 스토리지를 분리함으로써 시퓨의 부하및 지연 대기를 감소시킬수 있
답니다.

운영체제의 주 스토리지영역을 제외한 나머지영역을 개별하드에 분리해주세요.

{{{ 1하드 -> 1디렉토리 개념{{{

예> /swap
/tmp
/home
/var/mysql
/var/ftp
/var/www/html
/usr/share

이영역들을 독립하드에 할당해서 운영해주시면 효율을 보실수 있습니다.

용도별 라인ip대를 분리해주므로서 트래픽을 줄일 수 있답니다.

예> 웹 서버 192.168.0.0 대
ftp 서버 192.168.1.0 대
mysql 서버 192.168.2.0 대

이런식으로 분산해주면 지연시간이 줄게 됩니다.
가상아이피는 권장하지않습니다. 개별랜카드에 부여권장
기가랜 광랜이라하더라도 개별랜카드에 부여권장

서버를 1대의 컴에서 돌릴려면 풀하드4~8대의 하드와 3~4개정도의 네트워크 회선을 권장합니다.

가장앞선 생각 전라도 네트워크 전라넷 운영자입니다..

댓글 달기