SQL Server 백업 복원 속도 차이 관련 문의

안녕하세요 

DB 백업 속도가 한 서버는 8분 / 한 서버는 1시간 이상으로 매우 차이가 커서 원인 확인중에 있습니다.

서버 사양은 큰 차이가 없는듯하고, 디스크 I/O 속도 차이로 인하여 이런 차이가 발생되는것으로 판단하고 있습니다.


실제로 5G 미만 저용량 I/O 때는 쓰기 속도가 두 서버 다 180MB/s 정도 나오는데, 

100G 이상 고용량 I/O 때는 느린 서버는 쓰기 속도가 30MB/s로 줄어듭니다.

이런 경험을 해보신 명확한 해답을 알고 계신 분이 혹시 있으신가요?


이런 원인이 어디에 있을까 찾아보고 있는데요, 

디스크는 둘 다 삼성 SSD 850 Pro, 860 Pro로 크게 성능 차이가 없습니다.


그래서 레이드 카드를 비교해보고 있는데, 디스크 쓰기 캐시 설정을 확인해보라는 조언을 들었는데,

확인해보니 빠른 서버의 레이드카드 ThinkSystem RAID 530은 캐시리스라고 하더라고요?

또한 디스크 쓰기 캐시 설정은 MSM에서 해야한다고 하던데, MSM도 지원하지 않는다고 합니다.


결과적으로 빠른 서버의 디스크 캐시 설정이 적용이 안되어있다는 것으로 판단해도 되겠지요?

그렇다면 디스크 쓰기 캐시 차이도 아닌게 맞는거죠?


----------------------------------------------------------------------------------------------------------------

 

ThinkSystem RAID 530 시리즈 내부 RAID 어댑터의 사양은 다음과 같습니다.

  • PCIe 3.0 x8 호스트 인터페이스

  • Broadcom MegaRAID 9440 어댑터 제품군 기반 12Gbps SAS/SATA RAID 컨트롤러

  • 캐시리스(업그레이드 불가)

  • 선택한 어댑터에 따라 최대 4개 또는 8개 또는 16개의 내부 SAS 또는 SATA 드라이브 연결

  • SAS 및 SATA HDD 및 SSD 혼합 지원. 동일한 어레이에서 SAS 및 SATA 드라이브 혼합은 지원되지 않습니다. 동일한 어레이에서 HDD와 SSD의 혼합은 지원되지 않습니다.

참고: MegaRAID CacheCade 및 MegaRAID Storage Manager는 지원되지 않습니다.



IBM ServeRAID M5110e 

  • MegaRAID Storage Manager 관리 소프트웨어 가능

태그가 없습니다.

7개의 답변이 있습니다.

0 추천 | 4달 전

처음 글을 보고 RAID 컨트롤러나 스토리지의 Cache 차이일까 생각했는데,

글을 읽다 보니 오히려 빠른 쪽이 캐시리스라면 다른 문제일 가능성이 있겠네요.

서버의 메모리, RAID 카드 종류 등을 비교해서 동일한 상황으로 만들어 놓지 않으면

정말 찾아내기 쉽지 않은 경우입니다. 

Reply

댓글 남기기

답변을 보시려면 로그인이 필요합니다.

로그인 회원가입

0 추천 | 4달 전

디스크 문제는 예상보다 여러 이슈가 있습니다.

수치로 안나오는 노후화문제도 있고. RAID구성이 어떻게 되어있냐도 영향을 미치더군요.

그런걸 감안해도 8분과 1시간의 차이는 납득하기 어려운 수준인데.

전문 엔지니어가 직접 분석하지 않으면 찾기 쉽지 않겠네요

Reply

댓글 남기기

답변을 보시려면 로그인이 필요합니다.

로그인 회원가입

0 추천 | 4달 전

하드웨어 문제보다는 데이터베이스 자체의 문제로 보이는대 동일 데이터를 서버를 서로 바구어 테스트 해 보심이 

Reply

댓글 남기기

답변을 보시려면 로그인이 필요합니다.

로그인 회원가입

0 추천 | 4달 전

아마도 디스크 l/o차이가  있을수 있는데 컨트롤러를 동일 한걸로 교체해서 사용해보세요

Reply

댓글 남기기

답변을 보시려면 로그인이 필요합니다.

로그인 회원가입

0 추천 | 4달 전

저도 데이터 용량이 궁금한데요.

제 느낌(경험)상 하드웨어 문제는 아닐것 같습니다.

스토리지의 캐쉬가 나가는 경우가 아니라

레이드카드의 캐쉬는.. 서버가 수년 넘어가기 시작하면 레이드카드 캐쉬 뱃더리가 제일먼저 나가는데 별 문제 없더라구요.


용량이 부담 없다면

A 서버의 백업본을 B 서버에 복구해서 똑같은 하드웨어에서 백업 복구 테스트를 해보시는게 확실할것 같네요.

디스크 용량이 부족하다면,

백업본을 다른 용량 큰 유휴서버에 부어서 백업 복구 테스트를 해보시면

서버 물리적인 문제인지 SQL 논리적인 문제인지 우선은 확인이 되실거에요.

Reply

댓글 남기기

답변을 보시려면 로그인이 필요합니다.

로그인 회원가입

0 추천 | 4달 전

Disk I/O문제는 아닌것 같고

그렇다고 raid controller 문제도 아닌것 같아요

두 서버에서 동일하게 구성을 했을 테니까요

DB 용량에서 파일 문제 인것 같아요

백업시 디렉토리별 백업을 해보세요

잔파일이 많다면 그만큼 오래 걸립니다

Reply

댓글 남기기

답변을 보시려면 로그인이 필요합니다.

로그인 회원가입

1st 5stars

0 추천 | 4달 전

비슷한 사양인데 하나는 8분, 다른 하나는 한시간 이상... 차이가 많이 나네요.

동일한 백업 데이터를 양쪽 서버에 복원하는 것인가요?

DB 특성도 속도에 영향을 줄 수 있을 거라 생각되는데... 동일한 DB 백업 자료라면 고려하지 않아도 되겠지만 다른 종류의 DB 자료라면 검토해봐야 할 거라 생각되고요.

RAID Controller가 서로 차이 있는 가 보네요.

디스크에 데이터를 복원하는 작업이기 때문에 디스크 성능에 영향을 많이 받을거라보여지고요.

RAID 구성에 따라서도 디스크 I/O 성능에 영향이 있겠고요.

데이터를 한번에 읽고, 쓰기하는 데이터 처리 단위도 영향을 줄 수 있겠고...

RAID 컨트롤러의 성능도 영향을 줄 수 있겠고...

추가적으로 서버에 작동되고 있는 다른 서비스 소프트웨어 등의 소프트웨어 문제도 검토해 봐야 할 거라 보여 지네요.

Reply

댓글 남기기

답변을 보시려면 로그인이 필요합니다.

로그인 회원가입

답변 달기

답변을 보시려면 로그인이 필요합니다.

로그인 회원가입

스토리지/백업 카테고리의 다른 질문들...

  • 약 한 달 전
  • 댓글 : 약 한 달 전
  • 약 한 달 전
  • 댓글 : 약 한 달 전
  • 약 한 달 전
  • 댓글 : 약 한 달 전
  • 약 2달 전
  • 댓글 : 약 2달 전
  • 약 2달 전
  • 댓글 : 약 2달 전
  • 약 2달 전
  • 댓글 : 약 2달 전