일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 |
- 나경원
- 570e
- 인터넷
- 검색 조작
- 공정성
- 인터넷TV
- 케이블TV
- 박원순
- 안드로이드
- 블로거
- 삼성
- 영화
- IPTV
- 샵n
- 불법복제
- 네이버
- 나는 꼼수다
- 포털
- 구글
- 경쟁력
- 나꼼수
- 770z
- 선관위
- 아이폰
- 망중립성
- 리눅스
- 블로그
- 구글 트렌드
- 네이버 트렌드 연감
- IT
- 2022/03 (6)
- Today
- 23
- Total
- 3,579,424
미닉스의 작은 이야기들
SSD 이야기 7. SSD와 서버: SSD 본문
7. SSD와 서버: SSD 스토리지 클라우드를 구성하는 장비 내부는 결국 하드디스크들의 블럭 쌓기입니다. 거대한 클라우드도 한 개의 디스크로부터 출발합니다. SSD가 성능이 뛰어나기는 하지만 단순히 하드디스크를 SSD로 교체한다고 해서 전체 시스템의 성능이 그 만큼 좋아진다고 말할 수 없습니다. 아직은 가격, 용량, 특성에서 하드디스크가 장점이 더 많기 때문에 SSD가 잘 할 수 있는 분야를 찾아내는 것이 중요합니다. 이제 서버 분야에서 디스크 블럭을 SSD로 교체 하려면 어떤 전제가 필요한지 알아 보도록 하겠습니다. 7.1 SSD는 하드디스크에 최적화된 현재의 시스템 구성으로 사용되어서는 안 된다. 컴퓨터 디바이스와 프로그램들은 하드디스크의 느린 액세스 타임을 이해하는 소프트웨어의 도움을 받아 여러 가지 방법으로 최적화 되어 있습니다. 버퍼, 캐시, NCQ, TCQ등이 이 것입니다.. 하드디스크에 작업을 요청하는 프로세스가 많아질수록 각각의 서비스 품질은 저하됩니다. 그러나 버퍼 캐시의 도움을 받은 상태에서 요청들을 재배열하여 최적화할 수 있기 때문에 전체적으로는 높은 대역폭을 낼 수 있습니다. 동시에 여러 프로세스가 다량의 데이터 요청을 하는 서버에서는 특히 이런 효과가 극대화됩니다.
SSD는 아무런 스케줄링을 하지 않는 것이 최고의 성능을 낼 수 있는 방법입니다. SSD를 위한 디바이스 드라이버를 만들어 이런 스케줄링을 회피할 수 있게 하는 것이 한 방법이지만 블럭 디바이스 루틴과 연계되어 있기 때문에 현재로서는 운영체계 소스 코드 수준의 변경이 있어야 가능합니다. 오픈 소스가 아닌 윈도우에서는 마이크로소프트가 이 일을 해 줄 때까지 기다려야 합니다. SSD 특정 업체와 MS가 SSD에 맞춘 운영체계 새 버전을 준비하고 있다는 기사들이 나오고 있는데 대단한 작업을 하고 있는 것처럼 보이지만 알고 보면 그들이 할 일이란 "SSD 일 때 최적화 없음"으로 돌리도록 설정하는 것일 뿐입니다. MS가 하드디스크와 블럭 디바이스의 최적화 설정 변경 기능을 제공했다면 업체들이 자체적으로 성능 향상을 위해 이 값을 변경해 볼 수 있었겠지만 그들은 타 업체에게 이런 자율권을 준 적이 없습니다. 샌디스크 같은 업체들이 비스타가 SSD에 최적화 되어 있지 않다고 비난하는 이유가 여기에 있습니다. 마치 멀쩡한 XP를 버리고 비스타 판매를 늘이기 위해서 다이렉트X 10을 비스타에만 사용가능하도록 만들었던 때와 같이 마이크로소프트는 SSD에는 "하드디스크 최적화 루틴 사용하지 않음"이라는 설정 변경을 다음 버전 윈도우의 주요한 기능으로 포장하기를 원할지도 모릅니다. 그렇게 되면 사람들은 SSD를 제대로 쓰고 싶어서 앞다투어 새버전 윈도우를 구입할 것이며 너도나도 벤치마크를 돌리며 달라진 결과에 행복해 할 것입니다. 언제나 그렇듯 기술은 마케팅을 이길 수 없습니다. 다행히 커널 소스가 공개된 리눅스에서는 이런 부분을 SSD에 맞게 변경할 수 있습니다. 어렵게 커널 소스를 고칠 필요도 없습니다. 간단한 플래그 세팅만으로도 하드디스크 최적화 루틴을 건너뛸 수 있습니다. 현재 리눅스에서 제공하는 블럭 디바이스 스케줄링 알고리즘은 다음과 같습니다. Complete Fair Queuing(CFQ), 이 중 3개는 하드디스크에 최적화된 블럭 디바이스 스케줄링 알고리즘이며 no-op는 스케줄링을 하지 않도록 하는 옵션입니다.
현재의 스케쥴링 방식하에서는 SSD가 제 성능을 낼 수 없습니다. 지금 현재 리눅스는 간단한 설정 변경으로 SSD에 최적화를 시킬 수 있으며 윈도우도 차기 버전에서 SSD용 드라이버를 사용하고 블럭 디바이스 드라이버 설정 변경으로 SSD에 최적화 될 것입니다. 어떤 경우든 앞으로는 SSD를 하드디스크와는 다른 방식으로 처리해야 할 것입니다.
비정상적인 종료, 갑작스런 정전 등에도 SSD는 스토리지로서의 기능을 상실합니다. 이렇게 된 SSD는 전용 프로그램으로 초기화하지 않으면 인식조차 되지 않습니다. 특히 노트북의 슬립 기능이 잘못되었을 때 SSD에게는 치명적인 손상이 발생 합니다. 노트북을 사용하다가 끄지 않고 슬립 상태로 이동하는 경우에 어떤 이유로 슬립이 되지 않을 경우가 있습니다. 이 상태로 밀폐된 가방에 넣으면 노트북은 다운되기 전까지 온도가 올라갑니다. 뒤늦게 이 것을 발견하여 열을 식히고 나면 다른 부분은 정상으로 되돌아 오지만 SSD만 고장 나 있을 가능성이 높습니다. 고온에서 낸드플래시와 SSD 컨트롤러가 비정상 동작을 하게 되고 그에 따라 데이터가 손상 당하기 때문입니다. 전기적인 특성은 특히 많은 문제를 일으킵니다. 아날로그로 움직이는 기계적인 부분이 있는 하드디스크는 전원이 불량하면 동작 속도가 느려지는 식으로 적응을 하지만 SSD는 기동에 필요한 전압과 전류가 충분하지 않으면 정상 동작조차 하지 못하며 좀 더 심각해지면 잘못된 동작으로 데이터까지 날아가 버립니다. 호환성 부분도 문제가 심각합니다. 수십 년간 사용된 하드디스크 인터페이스에 맞추는 일은 SSD 입장에서 보면 아직 갈 길이 멀기만 합니다. 운영체계, 인터페이스, 사용 전압에 따라 제 각각인 방식에 적응하여야 하며, 칩셋 업체, 레이드 모드가 바뀔 때마다 문제가 발생하며 그 때마다 그 모든 경우에 대응할 수 있는 해결책을 내 놓아야 합니다. 여태까지 테스트 한 모든 업체의 SSD는 전부 이런 문제가 있었으며 버전업 하면서 겨우 하나씩 해결되어 왔습니다. 하드디스크와 동등한 SSD가 되기 위해서는 아직도 많은 시간이 필요할 것으로 생각됩니다.
서버쪽에는 데이터가 날아가도 상관없는 영역에 한정하여 SSD를 사용하는 것이 최선입니다. 이중화된 캐시 서버, 동일한 데이터를 가지고 서비스하는 웹서버, 원본이 따로 보관된 스트리밍 서버, 읽기 전용의 검색용 인덱스 서버 등이 그 영역입니다. 메인 데이터베이스 서버 등에 사용하게 되면 심각한 문제가 있을 수 있다는 점을 명심해야 할 것입니다.
PATA와 SATA1을 지원하며 읽기 쓰기가 150MB/s 이하의 1세대 SLC SSD가 출현한 후로 SATA2를 지원하고 읽기 쓰기 속도가 300MB/s에 육박하는 2세대 제품들이 쏟아져 나오고 있습니다. 넷북에서는 자체 인터페이스를 채택하여 하드디스크 모드가 아닌 버스에 바로 연결되는 형태도 있으며 ExpressCard 방식도 출현하였습니다. I-RAM과 같은 방식으로 PCI-Express 카드 형태로 나와 경이적인 속도를 내는 제품도 있습니다. 이 모든 제품들은 속도 경쟁을 통해 자신들이 최고라고 주장하고 있습니다.
하드디스크의 드럼에 비해 낸드 플래시의 셀들은 안정적이지 못합니다. 낸드플래시는 내부에 여분의 블럭을 내장하고 있으며 베드블럭이 발생했을 때 에러 난 블럭의 데이터를 읽어서 문제 없는 블럭으로 대피시켜서 에러를 감춥니다. 이런 내부 동작 때문에 바빠서 일시적으로 응답을 하지 않는 낸드 플래시가 있으면 그 순간 성능이 급격히 떨어지게 됩니다. 다수의 낸드 플래시를 관리하는 컨트롤러는 여러 가지 상황을 처리해야 하는데, 특히 데이터가 많아져서 낸드 플래시에 여분의 공간이 적어지고 디스크 단편화가 진행되면서 컨트롤러가 데이터를 여러 블럭에 나누어 저장해야 할 때 문제가 발생합니다. 현재와 같이 SSD 용량이 작은 상황에서는 대부분 SSD에 데이터를 거의 꽉 채운 상태로 쓰기 마련인데 이럴 때가 가장 심각한 상황입니다. 단편화된 파일시스템에 데이터 쓰기는 한 번에 여러 블럭에 걸친 쓰기가 필요해집니다. 블럭 방식 SSD는 다수의 블럭 단위 읽고 쓰기로 성능이 저하되며 페이지 방식 SSD는 쓰레기 수집에 많은 시간이 걸립니다.
SSD에 4KB 파일을 채웁니다. cp 4KB-file >a00001; cp 4KB-file >a0000N 무한 반복 이제 짝수 번째 파일을 지웁니다. rm a00002 a0004… SSD의 파일시스템은 4KB의 데이터와 4KB의 빈 공간이 교차하는 상태가 됩니다. 이렇게 이빨 빠진 상태에서 다시 7KB 파일을 채웁니다. cp 7KB-file >b0001; cp 7KB-file >b000N 무한 반복 다시 짝수 번째 파일을 지웁니다. rm b0002 b0004… 이제 파일시스템에서 연속된 빈 영역은 최대 4KB이며 대부분은 3KB, 2KB, 1KB짜리 조각들입니다. 이 상태에서 벤치마크를 실행합니다.
SSD의 낮은 랜덤쓰기 성능을 외부 프로그램으로 해결할 수 있다는 주장이 있습니다. MFT(Managed Flash Technology) 프로그램이 그 것입니다. SSD 쓰기 요청을 가로채 SSD 특성에 맞게 블럭을 재조정함으로써 최대 성능을 내도록 해 준다고 합니다. 쓰기 최적화는 낸드 플래시의 수명도 늘여주는 효과까지 있다고 합니다. 실제로 사용해 보면 작은 파일 쓰기에 문제가 많은 MLC 버전 SSD에서 상당한 성능 향상을 얻을 수 있습니다. 그러나 MFT의 효과 대부분은 SSD만을 위한 전용의 버퍼캐시를 설정했기 때문에 생기는 것입니다. 작은 파일 쓰기가 많을 때 이 것들을 버퍼에 모았다가 한 번에 쓰기 때문에 생기는 향상입니다. MFT는 이를 위해서 SSD의 파일 시스템 페이지 재조정까지 감행하여 가능하면 작은 파일들이 SSD 쓰기 단위와 같은 크기의 블럭에 모이도록 설정합니다. 성능은 증가할지 모르지만 이런 이중의 개입은 또 다른 문제를 일으킵니다. 전원이 나가면 필요 이상으로 많이 설정된 버퍼캐시에 있던 데이터가 사라져서 파일 시스템 안정성에 문제가 발생합니다. 버퍼와 캐시를 무효화하도록 운영체계에 요청하여 직접 저장장치를 접근하는 데이터베이스 프로그램들은 그들이 예측한대로 시스템이 동작할 것이라고 믿고 데이터를 처리합니다. 그러나 버퍼 캐시 무효화 요청을 무시하고 독자적인 알고리즘에 따라 SSD를 처리하는 MFT가 중간에 끼여 있을 때 심각한 데이터 손상이 올 수 있습니다. 쓰기 성능을 올려 준다고 해서 이런 프로그램을 서버에서 사용해서는 안됩니다. 시스템의 안정성을 특별한 프로그램의 동작에 맡기는 행위는 결코 해서는 안 되는 일입니다.
7.4.1 SSD의 쓰기 성능 리눅스 /usr 디렉토리에서 일부 하위 디렉토리를 지워서 1.5GB로 만듭니다. 파일 수는 55,000개인데 이 때 파일 평균 크기는 27.27KB가 됩니다. 이 데이터를 램디스크에 올린 다음 각각 SSD, SATA에 복사 테스트를 합니다. cp –a /ramdisk/usr /ssd/usrN 이런 프로세스를 1개에서 128개까지 증가시키며 테스트를 진행합니다. 1개에 가까울수록 순차쓰기 성격이 높으며 128개에 가까울수록 랜덤쓰기에 가깝게 됩니다.
대용량 메일 서버는 엄청난 양의 메일을 주고 받는데 일단 보낼 메일 데이터를 큐에 쌓아 놓고 순차적으로 전송합니다. 부하가 많이 걸리면 메일 전송에 장애가 생기므로 큐를 효율적으로 관리해야 합니다. 생성하는 파일 수가 늘어나면서 파일 처리에 드는 오버헤드가 큰 비중을 차지 합니다. 현재는 큐에 너무 많은 메일이 쌓이지 않도록 부하가 늘어나면 메일 큐 전용 서버를 늘려서 문제를 해결하고 있습니다. 그러나 필요하다고 무한정으로 서버 수를 늘릴 수가 없습니다. 만약 하드디스크를 SSD로 대체하여 시간당 메일 처리 량을 높일 수 있다면 큐 서버를 줄일 수 있을 것입니다. TCO 관점에서 관리해야 할 서버를 줄일 수 있다면 SSD를 사용하지 않을 이유가 없습니다. 또한 메일 데이터는 잠시 쓰였다가 전송 후에 사라지는 데이터이기 때문에 SSD가 에러가 생겨도 상관없습니다. 극단적으로 무책임하게 이야기하자면 메일은 기본적으로 복제 되어 보내지기 때문에 전송되지 않아도 상관없습니다. 꼭 필요한 메일이라면 다시 보내게 됩니다. 어쨌든 보낸 메일함에서 원본을 찾을 수 있으니까요. SSD 적용 가능성을 보기 위해 대용량 메일 서버의 메일 큐 시물레이션 테스트를 합니다. 100만개의 File을 생성하는 Thread 10개를 실행합니다. 이 중 8개의 Thread는 10 Kbytes, 2개의 Thread는 100 Kbytes로 랜덤한 내용의 파일을 만듭니다. 한 편 생성된 파일을 리스팅하고 삭제하는 Process를 10개 동작시킵니다. 큐에 쌓는 프로세스와 메일을 전송하고 지우는 프로세스를 흉내 낸 것입니다. SATA 하드디스크
SSD
7.4.2 SSD의 읽기 성능
위의 표는 인텔이 규정한 서버 테스트 워크로드 중에서 파일서버 액세스 패턴입니다. 대부분의 테스트 프로그램은 이 값을 기준으로 서버를 비교 테스트합니다. 여기서 정의한 대로 테스트를 실시합니다. 다만 표에서는 읽기/쓰기 80/20 비율이지만 여기서는 읽기 100%로 했습니다.
특히 SSD의 안정성 측면에서 볼 때 읽기 전용은 위험 부담이 적습니다. 물론 이중화를 해서 SSD의 에러에 대한 대책을 수립해 놓고 있어야 하지만 쓰기에 비해 읽기 안정성은 쉽게 확보할 수 있으므로 크게 걱정할 필요는 없습니다. 읽기 전용 서버에 SSD를 도입했을 때 어떤 성능 향상이 있는지 실전 테스트 결과를 놓고 이야기 해 보기로 합니다. 7.5 실제 파일 서버에 SSD를 도입하여 성능 개선 시키기
부하가 몰리는 시간 대에 운영팀들은 비상 대기를 하면서 필요한 조치를 즉각 취하는 형태로 유지 관리를 합니다. 어느 한 서버가 에러가 나면 다른 쪽으로 트래픽이 몰려 나머지 서버들도 차례로 죽기 때문에 서비스 품질이 급격히 떨어집니다. 업체들은 여러 가지 방법으로 최적화를 하고 성능과 안정성을 확보하려고 노력하지만 쉽지 않은 일입니다. 이런 분야에 SSD가 한가지 대안이 될 수 있습니다. 7.5.1 실제 서비스 하는 하드디스크 시스템의 성능 네트웍 스위치는 서버들이 네트웍으로 주고 받은 데이터량을 로그로 남겨 둡니다. 이 값을 받아서 그래프를 그릴 수 있는데 이것을 MRTG(Multi Router Traffic Grapher)라고 합니다. MRTG를 통해서 파일 서버의 네트웍 트래픽을 보면 그 서버의 서비스 상태 경과를 알 수 있습니다.
600KB/s 정도의 속도인 ADSL 사용자 70명 : 182KB/s(평균 데이터 전송 속도) 이 때의 sar를 통해 본 시스템 정보는 다음과 같습니다.
위와 같은 상황에서 SSD를 사용하면 상황이 어떻게 변하는지 알아봅니다.
하드디스크 서버와 같은 조건에서 SSD 서버가 낼 수 있는 성능은 최대값 기준으로 571.5Mb:2551.0Mb로 약 4.5배 정도의 성능 향상이 있다고 말할 수 있습니다. 7.5.3 SSD 서버의 스케줄링 제거 효과 4.5배 향상도 훌륭한 성능 개선입니다. 그러나 아직 여러 가지 튜닝 요소가 남아 있습니다. 위 결과들은 스케줄링 제거인 no-op 옵션을 사용하지 않은 것입니다. No-op를 적용한 상태에서 같은 테스트를 다시 했습니다.
이 때 sar를 이용한 서버 정보는 다음과 같습니다.
약 12배 정도의 성능 향상은 SSD와 하드디스크의 가격대 성능비를 따져도 SSD가 밀리지 않습니다. 더구나 SSD 서버 한 대 도입으로 12대의 하드디스크 서버를 줄일 수 있기 때문에 관리의 이점도 있습니다. 줄어드는 데이터 센터 공간 사용료 또한 무시하지 못할 요인입니다. SSD를 도입한다면 최대 성능뿐만 아니라 각각의 커넥션에 대한 서비스 품질도 최대한으로 높일 수 있습니다. 그러므로SSD는 잘 튜닝된 형태의 읽기 전용 서버에 가장 적합한 솔루션입니다. 7.6 SSD: 진정한 캐시 서버의 구현 하드디스크의 느린 성능을 메우기 위해서 메모리를 통한 캐시가 있어왔지만 서버들 간에 이런 기능을 할 수 있는 것은 없었습니다. 캐시 서버라고 불리는 것들은 사용자가 많이 요청하는 데이타를 미리 찾아 놓거나 같은 데이터를 가진 서버를 여러 대 준비하여 부하를 분산하는 정도가 고작이었습니다. 캐시 서버들은 원본 데이터를 가진 서버에 비해 성능이 뛰어나지 않았기 때문에 L4 캐시 서버와 같이 데이터에 접근하는 경로를 줄여 주는 프락시 기능은 부하가 걸릴 때 전체 서비스를 마비시키기도 했습니다. 따지고 보면 여태까지 진정한 의미의 캐시 서버는 존재한 적이 없다고 말할 수 있습니다.
같은 데이터가 담긴 서버 수를 늘리는 캐싱에서 적은 수의 고성능 SSD 서버 캐싱으로 변경함으로써 유지 관리가 편해지고 비용이 줄어듭니다. 인기 데이터를 제거한 파일 서버들은 적정한 규모의 접속을 안정적으로 서비스 할 수 있습니다. 만약 갑자기 일반 파일 서버의 특정 파일에 대한 요청이 몰린다면 실시간으로 이 파일을 캐시 서버에 옮겨서 문제를 해결할 수 있습니다.
그러나 현실의 어려움 때문에 아무도 이런 말에 귀 기울이지 않습니다. 산처럼 쌓인 SSD 테스트 결과는 휴지 조각이 되고 SSD를 위한 수 많은 튜닝 노하우는 쓸모 없는 지식에 불과하게 되었습니다. 앞으로의 전망도 어둡습니다. 불황에 더해서 극심한 경쟁까지 기다리고 있습니다. 아아 위태로운 SSD 비즈니스, 도대체 희망은 어디에 있는 것일까요? 김인성. |
'김인성의 삽질기 > 3. SSD 이야기' 카테고리의 다른 글
SSD 하드디스크 사용자들께 경고 드립니다. (27) | 2018.05.04 |
---|---|
노트북에 1.8인치 SSD 달기 (14) | 2009.01.06 |
SSD 이야기 7. SSD와 서버: SSD (36) | 2008.12.26 |
SSD 이야기 6. SSD와 서버: 서버 (24) | 2008.10.14 |
SSD 이야기 5.SSD와 데스크탑 (8) | 2008.07.18 |
SSD 이야기 4. SSD와 휴대용 장치들 (9) | 2008.06.03 |
SSD 이야기 3. 액세스 타임을 줄여라 (5) | 2007.08.17 |
SSD 이야기 2.액세스 타임이란 무엇인가? (12) | 2007.08.01 |
SSD 이야기 1. 하드디스크와 SSD의 비교 (11) | 2007.07.26 |
- 이전 댓글 더보기
-
mag44 2008.12.29 00:55 항상 좋은 정보를 제공해 주셔서 감사드립니다.
-
blueiur 2008.12.29 01:28 감동받았습니다.
이런 엄청난 정리를! -
perftune 2008.12.31 16:18 잘읽었습니다.
엑세스타임, DMA, 클라우딩 그리고 오늘의 비즈니스 현실까지.
대장정의 마무리 축하드립니다.
또 다시 새로운글 기대 합니다. -
미닉스 김인성 2009.01.05 14:40 신고 읽어 주셔서 감사드립니다. 연초에 차를 몰고 강원도-경상도-전라도-충청도로 한 바퀴 돌고 왔습니다. 마이산도 잘 있더군요. 새해에는 좀 더 많이 좀 더 빨리 쓰려고 합니다. 2009년에는 몸조심하시고 좋은 날을 볼 수 있기를 바랍니다.
-
미닉스 김인성 2009.01.05 14:41 신고 그리고 고딩! 방학인데 공부는 열심히 하고 있겠지? :-P
-
최완우 2009.01.07 18:18 공부는 열심히 하고 있지요 ㅋㅋ
-
free7942g 2009.02.05 00:58 글 잘 읽었습니다.
감사합니다. -
미닉스 김인성 2009.02.05 16:25 신고 잘 읽으셨다니 저도 기쁩니다.
-
마컬 2009.02.10 11:35 잘 읽었습니다 ^^
읽는 것 만으로도
미닉스님이 힘들게 얻으셨던 정보들 일부나마
느낄 수 있었던 것 같아서 정말 감사드립니다 -
미닉스 김인성 2009.02.11 10:50 신고 그런 자료도 이젠 별로 쓸모가 없습니다. 쓸쓸한 일이지요.
-
ESET 2009.02.14 13:16 좋은 글이네요. 덕분에 재미있게 읽을수 있었습니다. (감동)
P-RAM이 양산되어 SSD에 적용될때까지는 아직인가 봅니다. -
미닉스 김인성 2009.04.17 17:07 신고 SSD쪽과 관련있는 일을 하지요. 어디서 개발하고 계신가요?
-
미닉스 김인성 2009.04.17 18:31 신고 어쩐지 그 쪽 사이트가 유입경로에서 뜨더라니...... 어쨌든 캄사합니다. 엠트론, 인디링스, 미디언 이런 업체들 따지고 보면 결국 다 그 쪽 출신들이지요. 저도 신입사원 연수만 받고 도망쳐 나왔던......
-
김규원 2009.05.14 03:42 잘 봤습니다. SLC가 대안이군요. 테스트 옵션을 아주 자세하고 간단하게 적어주셨네요. 해보고 싶진 않지만요.
하지만 용량을 꽉 채운상태에서의 테스트를 인텔 모델에서만 수행한 것이 좀 아쉬워요.
다른 모델도 동일한 테스트가 있었다면 어떤 회사의 SLC를 구입해야할지 제게 좀 더 도움이 되었을텐데요.
또, 대부분 그래프는 세로축이 MB/s인데, random read에서 성능이 떨어지는 것을 보여주실 때만 IOPS를 쓰셨는데요. 동일 그래프의 세로축을 MB/s로 해서 표현해본다면 이해하는데 좀 더 도움이 될 것 같아요.
그리고 http://juni7.net/g4/bbs/board.php?bo_table=Mobile&wr_id=34
이쪽 리뷰와는 뉘앙스가 다르네요. 한 번 보세요.
감사합니다.
아 그리고 위에 IOPS로 된 그래프의 세로축을 MB/s로 바꿔서 그려봤는데요. 제대로 그린건지 모르겠네요.
http://www.playwares.com/xe/?document_srl=4112075&mid=freeboard -
미닉스 김인성 2009.05.26 18:36 신고 제 글은 일반인을 대상으로 하고 있기 때문에 모든 테스트 결과등을 일일이 보여 주지 않습니다. 그러나 그 한 개의 테스트 결과 화면에는 수 많은 다른 테스트 결과의 총합입니다. 알고 보면 보이겠지만 제가 올린 사진들도 모두 범상하지 않은 것들입니다. 어디서도 구할 수 없는 제품에 대한 사진들이 휙휙 지나가기 때문에 정신 차리지 않으면 제 글의 진정한 맛을 느끼기 어렵지요. 물론 대충 읽어도 재미있도록 쓰려고 노력한 글이지만......
-
나그네 2010.11.04 04:33 현재까지 등장한 3세대 SSD에서도 한계용량까지 데이터를 채우고, 지우고, 쓰기를 반복했을때 기본제품성능과는 한참 떨어진 결과를 보게 되실겁니다. SLC든 MLC든 마찬가지고, 그래서 트림 기능을 쓰려고 혈안이 되어있지요. 물론 트림또한 임시방편에 지나지 않는 기술입니다.
-
김규원 2009.05.17 19:23 펌웨어가 새로 나왔는데 위와 같은 테스트를 다시 해보면 좋겠다는 생각이 들어요.
-
미닉스 김인성 2009.05.26 18:32 신고 별로...... 해보고 싶진 않군요. 최근에 나온 인디링스 것도 마찬가지입니다. 페이지 방식 SSD의 숙명인 것 같습니다.
-
김규원 2009.07.07 13:25 "아직 신뢰할 수 없는 MLC는 서버 스토리지 장치로 사용해서는 안됩니다"라고 하셨는데요.
위 테스트로는 왜 MLC가 문제가 되는지 알 수 없을 것 같은데요.
엠트론 SLC와 MLC를 비교하거나 아니면 인텔 SLC와 MLC가 비교되어야 MLC가 문제다라고 할 수 있겠지만, 같은 회사의 MLC, SLC의 비교가 아니라서 MLC가 문제가 있다고 이야기하기는 어려울 것 같아요.
SLC, MLC문제라기 보다는 각 회사의 컨트롤러 때문이라고 생각할 수 있잖아요. -
미닉스 김인성 2009.07.07 15:03 신고 컨트롤러 회사의 추천 낸드플래시 목록표를 보셨으면 이런 이야기를 못하실 것입니다.
굴지의 낸드 플래시 제작 회사 연구소 사람들은 신기해하고 있지요. 낸드로 특히 MLC로 하드디스크를 대체한다는 것을......
"그게 되냐???" 라고 하더군요.
MLC 낸드를 위해서 컨트롤러가 얼마나 많은 닭짓을 하고 있는지 아시는지 모르겠습니다.
완곡하게 표현한 내용을 님께서 건든다고 해서 제가 더 나갈 수는 없습니다. 님은 그냥 건드는 것이지만 저는 잘못하면 큰일 나니까요. -
김규원 2009.07.07 13:31 그리고 의견 하나를 이야기하자면요.
최악의 상황을 고려하는 것이 중요한데, 그런 최악의 상황이 얼마나 자주 나타나는 일인지 언급이 되면 좋을 것 같습니다.
이를테면, 비행기 여행에서 최악의 상황은 추락인데요. 추락이 빈번하게 일어난다면 추락했을 때 안전성이 가장 중요한 선택의 요소가 되겠지만, 아주 드물게 일어난다면 속도가 중요한 선택의 요소가 될 것 같거든요. -
미닉스 김인성 2009.07.07 15:30 신고 서버 스토리지에 대한 경험이 있으신가요? 잘 모르고 엉뚱한 비유를 들어 말씀하시지 않으시는 것이 좋겠네요. 위에 제가 보여드린 자료들을 잘 좀 보셨으면 좋겠습니다.
국내 최대 웹하드 중 하나의 최대 부하시 전송 테스트, 현재 서비스 중인 정상급 검색 포탈 검색 서버 데이타 갱신 트래픽 변화량등...... 서버 스토리지는 언제나 추락 상황입니다. 모든 액세스가 랜덤 액세스지요.
잘 모르고 글을 쓰셔서 답답해서 쓴 답글인데 혹시라도 논리적, 상업적, 감정적, 문제가 생길 여지가 보인다면 전혀 저의 의도가 아님을 밝힙니다.
오해정부의 시대이므로 제 글이 문제가 있다면 전적으로 그렇게 읽은 분의 오해임을 밝히며...... -
박래웅 2009.08.30 16:35 구글링하다가 이곳으로 들어왔는데 글 잘 읽었습니다. 당연히 외국의 기사를 번역한 글이라고 생각하면서 읽었는데 맨 마지막을 보니 김인성 님이 직접 쓰신 글이군요. 전문적인 평가에 깊이 감동했습니다. 제가 지금 진행하고 있는 연구 중 하나가 약물부작용을 자동적으로 찾아내는 자동화 시스템을 개발 중에 있습니다. 테이블은 몇십개 정도지만, 어떤 테이블은 레코드가 1억건정도 되고 전체 DB크기는 200G정도 됩니다. 이를 이용해서 무지막지한 쿼리를 반복적으로 수행해야 합니다. 아직 계산해 보지 않았지만 탐색공간이 상당히 클것으로 예상됩니다. 꼭 이 연구를 위한 것은 아니지만 내년 초에 146노드 규모의 리눅스 기반 클러스터 서버 도입을 추진하고 있습니다. 여기에 기본 스토리지 이외에 위에서 언급한 연구를 위하여 500G~1T 규모의 SSD를 붙이려고 계획하고 있습니다. 단순히 HDD대신에 SSD를 붙이면 된다고 생각했는데, 김인성님 글을 읽어보니 전혀 그렇지 않군요. 실제 일을 추진하는 단계에서 김인성님의 전문가 자문을 받았으면 합니다. 허락해 주시면 실제 실행단계가 될 때 다시 연락드리도록 하겠습니다. 감사합니다. veritas@ajou.ac.kr
-
미닉스 김인성 2009.08.31 12:32 신고 연구 하시는데 도움이 되셨기를 바랍니다.
-
서경식 2011.08.17 10:30 좋은 글 잘 읽었습니다. 2년이 넘은 지금 봐도 그 내용이 OLD 하지 않고 깊이가 있는 것 같습니다.
-
민아 2011.11.06 04:08 좋은글 잘 봤습니다..^^
-
미닉스 김인성 2011.11.07 16:48 신고 감사합니다.
-
임시닉네임 2018.06.06 20:25 2018년 미래에서 왔습니다.
"인텔을 포함한 업체들은 차후 SATA와 같은 하드디스크 인터페이스를 제거하고 SSD를 바로 CPU와 메모리가 연결된 버스에 붙여서 최대 성능을 내도록 하려고 제안을 하고 있습니다. 이런 식으로 SSD를 사용하는 것이 대세가 될 것으로 예상합니다."
소름돋았습니다. 기업은 CPU에 바로 연결된 PCI-Express를 사용하는 NVMe를 개발했고, 아직 가격이 비싸기는 하지만 시제품이 나왔습니다. -
미닉스 김인성 2018.06.06 20:46 신고 제가 그런 제품 쓰고 있습니다.^^