Nvme block storage 는 현재 US 데이터센터에서만 지원한다는 것 같습니다.
기존 block storage로 DB저장 폴더를 옮겨서 운영해보신 분 계실까요?!
램은 많이 필요하고 인스턴스 내의 ssd는 별로 필요없어서 high memory 플랜으로 가고싶은데
DB용량때문에 SSD 크기가 20GB를 초과해서 너무 아쉽네요...
조회 수 792 추천 수 0 댓글 13
-
Lv24 
Lv4 아 그렇군요 역시...
리노드 문서를 읽어보니까 기존 block storage는 HDD랑 SSD를 혼용해서 쓴다고 하더라구요..
DB랑 라이믹스 사이에 apcu등의 캐시가 완충작용을 해주더라도 지금보다는 크게 느려진다는 말씀이시군요 ㅠㅠ 감사합니다 -
Lv4
Lv24 디비자체가 외부를 거치거나 HDD라면 아무리 캐싱을 잘 해주더라도 실제 디비 쿼리에 시간이 들어가는 시간이 있기 때문에 그 것으로 인한 성능은 느려질 수 밖에 없다고 생각하셔야 합니다. -
Lv30 서버의 스토리지 외 블록스토리지에 db는 물론이고 php 파일도 사용하지 않는게 좋습니다.
과거 블록스토리지(물론 SATA HDD 였습니다.)에 라이믹스 설치위치까지 모두 마운트해서 잠시 사용한 적 있었습니다.(그때 컨셉은 OS와 DB만 본서버에서 돌리고 나머지 첨부부터 모두 블록스토리지로 돌리자..)
결과는 블록스토리지 컨디션에 따라서 사이트 자체가 완전히 느려서 첨부파일 쪽만 블록스토리지로 마운트하는 것으로 변경했습니다.
물론 이때 db는 당연히 빠른 본서버 SSD에 위치해 있었지만 php들이 블록스토리에서 돌아가니 블록스토리지가 여러사람이 쓰고 네트워크쪽 영향도 심하다보니 1~2초 까지도 응답지연이 수시로 발생해서 그냥 첨부파일 정도 저장하고 불러와서 쓰는 용도 외에는 사용하면 안될 것 같더군요.
리노드는 아니고 국내 호스팅 VPS의 사례 입니다. -
Lv30 db가 20G가 넘어버렸다면 뭔가 데이터가 큰게 계속 저장되는 것 같은데 혹시 링크파싱 모듈이나 비슷한 자료를 사용하시나요? 해당 자료의 경우 섬네일을 출력해주기 위해 굉장히 큰 원본이미지를 그대로 db에 data 형태로 저장합니다. 혹시 맞다면..... -
Lv30
Lv4 가상머신이어서 운영체제 자체의 크기 + DB크기까지 합치니까 20GB가 넘어가는것 같습니다.
현재 문서가 343,291개 / 댓글이 1,656,756개 되네요 ㅠㅠ -
Lv37 타 업체에 비하면 상당히 빠르긴 하지만, 그래도 DB는 로컬에서 돌리는 것이 좋습니다.
-
?
Lv2 문서가 343,291개라면 이렇게 관리하는건 어떠실지요
아마 모든글에서 조회수가 잘 나오거나 리액션이 나오거나 그렇진 않을건데
오래된 글을 별도로 관리하고 댓글 막아서 블록스토리지에 별도 관리하게끔 바꾸는겁니다.
오래되었거나 자주안쓰는 DB내용을 row별로 json형태로 블록스토리지에 import해서 불러오게끔 바꾸고 수정을 제한해서 읽기모드만 가능하게 변경?
근데 이렇게 만드는게 서버 업글보다 힘들지도요 -
?
Lv10 일반적인 상식과는 다르게 놀랍게도 벤치마크에 따르면 디비성능에 스토리지는 별로 영향을 주지 않습니다 중요한건 램 용량입니다 램 용량이 충분하다면 디비 성능은 스토라지에 전혀 영향을 받지 않습니다 램 용량이 부족할때 성능곡선이 하향하는 기울기가 차이날뿐인데 애초에 그 상황이 되면 스토리지가 ssd든 hdd든 중요한게 아닙니다 왜냐면 어느쪽이든 드라마틱하니까요 절대로 램이 모자란 상황 자체를 만들면 안됩니다 반대로 말하면 램만 많으면 하드에서 디비 돌려도 무방합니다
-
?
Lv10 적절한 메모리를 버퍼로 할당하기 위해서 아래 문서를 활용하세요
https://dba.stackexchange.com/questions/27328/how-large-should-be-mysql-innodb-buffer-pool-size
스토리지에 전혀 영향을 안받으려면 디스크에 존재하는 모든 테이블과 인덱스 파일의 크기를 더한 것보다 60~70% 정도 더 많은 메모리가 필요합니다. 20GB의 DB를 가지고 계시다면 34GB 정도의 램을 버퍼로 할당하셔야 할 것 같네요. 차후 DB가 더 커질거라면 거기에 맞춰 더욱 충분한 여유가 필요할거구요. 그리고 반드시 innodb를 쓰셔야 합니다. 왜냐면 myisam 엔진의 경우 인덱스만 램으로 올리고 테이블은 램으로 안올린다고 합니다.그리고 램용량을 늘리는건 DB성능을 끌어올리는 가장 가성비 좋은 튜닝방법입니다. 램용량이 부족할때 DB성능은 드라마틱하게 하강합니다. 제가 말하는 충분한 메모리 사이즈에서 조금만 모자라더라도 성능은 팍팍 떨어지고 그 성능 하락을 스토리지 속도나 CPU 속도로 벌충하는건 너무 가성비가 안맞는 일입니다. 충분한 램용량을 지금까지 할당하지 않고 쓰고 계셨다면 CPU를 낭비하고 계셨던겁니다.
-
?
Lv10
Lv37 이론상으로는 그렇지만, 리노드를 비롯한 대부분의 클라우드 플랫폼에서 34GB의 램보다는 20GB의 고성능 스토리지를 택하는 편이 훨씬 경제적이지요. ㅎㅎ
SELECT 쿼리 속도는 램만 충분하면 디스크의 영향을 거의 안 받지만, INSERT/UPDATE/DELETE 쿼리는 트랜잭션을 커밋할 때 디스크에 flush해야 하기 때문에 디스크 속도를 완전히 무시할 수 없습니다. 동접수가 많은데 디스크가 따라오지 못하면 심지어 글의 조회수를 변경하는 간단한 쿼리가 병목현상을 일으키기도 합니다.;;;
SSD가 아니라면 DB로 쓰기엔 힘드실거예요. 하드인지 SSD인지 잘 확인해보시고 SSD이라도 다른 서버에 통신하여 연결되는 시스템이라면 버리세요..