예전에 정리한 문서지만 공유차원에서 올려봅니다.^^

 

데이터베이스와 밀접한 관련이 있는 데이터 저장매체 인 디스크구조 및 동작방식에 대해 알아보자.

 

디스크는 자기 디스크 플래터로 구성돼있으며 데이터를 트랙에 자기적으로 저장한다.

디스크 안팎으로 움직이는 전기자에 끝에 부착된 헤드가 회전하는 디스크를 읽고 쓰는데

플래터당 하나의 헤드가 존재해 플래터 집합인 디스크는 여러 헤드(전기자에 부착된)

가질 수 있다. 또한 헤드와 전기자는 모두 연결돼있어 모든 헤드는 데이터를 동시에 트랙에

읽고 쓴다.

디스크 헤드가 섹터의 데이터를 읽기 위해서는 섹터가 헤드 바로 아래에 있어야 하는데,

디스크는 항상 회전하므로 섹터가 그 위치에 올 때까지 기다려야 한다. 이때 디스크가

데이터를 읽을 수 있는 위치로 회전하는데 걸리는 시간이 회전 대기 시간(Rotation latency)이다.

보통 15000rpm 디스크의 평균 회전 대기 시간은 약 2ms 정도이다.

위 회전 대기 시간외에 헤드가 데이터가 존재하는 곳 즉 디스크 전기자가 요청된 데이터를

가지는 실린더로 이동하는 시간을 탐색시간(seek time)이라 한다.

(실린더는 디스크 플래터들의 동일한 트랙 집합이다.)
disk_1.jpg disk_2.jpg

 

디스크 동작을 완료하는데 걸리는 시간은 다음의 총합이며

-데이터를 가지는 트랙으로 이동하는데 걸리는 탐색시간(Seek Time)

-데이터를 헤드 아래로 회전시키기 위해 필요한 회전 대기시간(Rotational latency)

-디스크 드라이브에서 디스크 컨트롤러로 데이터를 전자적으로 전송하기 위해 필요한 시간

 

I/O 완료는 여기에 시스템 오버헤드(매우 포괄적인)를 더한 시간이다.

디스크I/O완료에 걸리는 시간은 요청된 I/O가 순차 방식인지 임의 방식인지에 따라 영향을

받으며 순차적 I/O성능은 트랙간 탐색 시간에, 임의I/O성능은 평균 탐색시간에 의해 좌우된다.

 

순차적 I/O(Sequential I/O)

디스크의 인접한 데이터의 액세스로 임의 I/O보다 트랙간 탐색 시간이 빨라 더 많은 양을

보다 빨리 처리할 수 있다.

 

임의 I/O(Random I/O)

디스크의 서로 다른 부분으로부터 액세스될 때 발생하며, 임의의 헤드이동이 발생해 성능을

감소시킨다.


Posted by 고희수

댓글을 달아 주세요

[프로세서 사용 계획 및 메모리 사용 계획]


프로세서 사용 계획: 백그라운드 서비스(스레드를 좀더 길게 사용하여 단일 프로그램의 효율을 높이기 위할 때 사용)

메모리 사용 계획: 프로그램(OS 시스템 영역 보다는 그 위에 올라가는 App 위주로 사용). MSSQL이나 IIS등도 OS 입장에서는 App 이다.

 

[네트워크용 파일 및 프린터 공유 등록 정보]


제일 밑에 있는 네트워크 응용 프로그램을 위해 데이터 처리량 최대화 선택

 

[참고 URL]

http://technet.microsoft.com/en-us/library/cc784562(WS.10).aspx

Posted by 안보갑

댓글을 달아 주세요


mstsc 명령으로 터미널을 붙어서 자주 사용하는데
언제 부터인가 console 옵션이 먹지 않는 문제가 있었습니다.

찾아봤더니 mstsc 6.01부터는 console 옵션이 admin 옵션으로 변경 되었다고 합니다.
아아아악~~ ㅠ_ㅠ

그래서 mstsc /console 이 안될때는 mstsc /admin 으로 사용하시면 동일하게 원격연결을 할 수 있습니다.

요즘 너무 휑~ 한거 같아서 간단한 팁으로 올립니다.
다들 수고하세요~ ^^

하만철 / Ha Man cheol
넥슨 DB 팀 ( http://nexondbteam.tistory.com )
Posted by 비회원
TAG mstsc

댓글을 달아 주세요

요즘 서비스에 들어가는 디스크 장비를 어떻게 구축하는 것이 가장 이상적이고 좋은 것인지에 대한 고민을 하고 있다~

로그는 따로 분리하는 것이 좋은것인지???

전체 박스를 하나로 묶고 내부적으로 나눠야 하나?

아니면 물리적으로 분리해서 나누어야하나? 등등의...

이런 고민들이 많이 된다...

물론 엄청 좋은 스팩의 장비를 들여오면 되지만...

좀더 제대로된 이해를 바탕으로 운영할 수 있어야 되지 않을까 싶다~

Posted by 안보갑

댓글을 달아 주세요

  1. 송혁 2007.11.11 23:32  댓글주소  수정/삭제  댓글쓰기

    음..분명 SQL Server 뿐만 아니라 일반적인 DBMS들도 IO문제로 인해 성능적인 이슈가 많은것 같습니다.
    보다 많은 디스크를 하나의 RAID로 구성하면 보다 나은 성능이 보장되겠지만 수도 없이 많은 디스크를 RAID로 묶는다고 해서 DISK수에 비례해서 성능이 늘어나지는 않기에 이러한 부분에 대해서는 테스트 또는 스토리지 전문가와 상의 할 수 밖에...

    개인적인 생각으로는 로그 파일의 경우는 여유가 된다면 무조건 분리하는것이 좋을 것 같네요~
    로그를 물리적 디스크로 플러쉬를 해야지만 commit가 되기에 다른 데이터 영역의 프로세스 작업으로 인해 로그가 디스크로 플러쉬 되는 시점이 늦어진다면, 데이터를 늦게 읽어오는 문제보다 더 문제가 될 가능성이..크니~

    아마 2~3년이 지나면 이러한 IO에 대한 문제가 SSD로 인해..많이 좋아질것 같은데~ 우리도 SSD를 도입을 고려해보는 건 어떨까요?ㅎㅎ