go

Parse는 확장성을 향상시키기 위해서 API를 포함한 서비스 일부를 Ruby on Rails에서 Go로 이행했다. 이로써 신뢰성과 배포 시간이 현저하게 개선됐다.

 


Parse 2011, Ruby on Rails 프로젝트로 시작했다. 이 선택에 의해서 Parse의 첫 버전을 소수의 기술자 그룹만으로 단기간에 구현할 수 있었다고 Majors(Parse의 엔지니어)씨는 말한다. 그러나 Parse가 확장되면서 아키텍처 상의 문제가 몇 가지 나타났다.


- 코드 베이스의 확대에 따른 배포나 롤백에 시간이 증가됐다. 게다가 Parse HTTP 서버인 Unicorn의 재 실행이 제대로 되지 않았다. 그 결과 몽키 패치(monkeypatching)에 의존하는 부분이 점차 커졌다.


- Rails의 요구마다 1프로세스 라는 모델이 API 트래픽과 앱 수의 증가에 따라서 붕괴"를 시작했다. 실제로 시간을 요하는 리퀘스트를 많이 수신한 경우 Rails의 워커 풀 사이즈의 자동 확장 기능이 따라가지 못해서, 워커 풀이 쉽게 넘치는 현상이 발생했다. 게다가 이들 워커의 대다수는 단순히 외부 서비스 완료를 기다리고 있는 상태였다.

 


이런 문제로부터 Parse의 엔지니어들은 Rails "요구 당 1 프로세스모델을 벗어나서 진정한 비동기 모델로 이행할 필요성을 인식하기에 이르렀다. Ruby gems의 대부분은 비 동기성이 없고 또 스레드 안전이 아닌 것도 많아서 Ruby는 이러한 처리에 적합하지 않다고 생각한 그들은 다른 언어를 선택하기로 했다. 선택 사항으로서 그들이 검토한 것은 다음과 같다.


- JRuby. 이것은 제외됐다. JVM에는 대규모 병행 처리를 다루는 능력이 있지만 Ruby의 비동기 라이브러리 지원에 문제가 있다는 것에는 변함 없기 때문이다.


- C++. 다른 언어에 비해 생산성이 낮고 HTTP 요청의 처리나 비동기 조작을 돕는 라이브러리가 없음 등을 이유로 이것도 제외됐다.


- C#. 비동기의 Await/Async 모델은 매우 좋은 선택이라고 생각되었지만 “Linux에서의 C# 개발은 주류가 될 수 없다고 생각으로 제외됐다.


- Go. 비동기 작업을 네이티브 지원하고 있고 MongoDB의 지원이 최고 수준, 코루틴 지원 등으로 최종적으로 가장 좋은 선택지로 여겨졌다.


 

Parse 기술자들이 자신들의 EventMachine Go로 구현하고 간단한 테스트를 실시했는데, 노드 당 접속 수가 25~ 150만이라는 결과를 얻었다. 이 결과를 바탕으로 그들은 코어 API를 포함한 모든 서비스를 하나씩, 하위 호환성을 확보하면서 수정 작업에 착수하였다.


 

프로세스의 종료 시에는 노력에 상응하는 결과를 얻었다고 Majors씨는 말한다.

- Parse "신뢰성이 현저히 향상”.

- 가동하는 데이터베이스 수 감소에 따른 API의 취약화에 제동이 걸렸다.

- 테스트 스윗 전체 통합 실행에 시간이 25분에서 2분까지 단축했다.

- API 서버 전체 배포 시간이 30분에서 3분으로 단축됐다.

- API 서버의 정상적인 재기동이 최종적으로 이루어졌다.

 

 

출처: http://www.infoq.com/news/2015/06/parse-moved-ruby-go  

저작자 표시
신고
by 흥배 2015.08.17 08:00

최신 닷넷플랫폼과 Visual Studio 2015에 대해서 간략하게 잘 설명한 글이 있어서 번역해 보았습니다^^




























저작자 표시
신고
by 흥배 2015.08.03 08:00

Go 1.5(2015 6)에서는 GC 지연 감소를 목표로.

구체적으로는 50밀리 초마다 GC 지연을 10밀리 세컨드 이하로 억제.

도달 가능한 값의 최대 2배의 힙을 사용한다.

 

구현 방침은 stop the world(STW)Concurrent GC의 하이브리드. STW에 의한 정지 시간을 50밀리 초마다 10밀리 세컨드 이하로 낮추고, 그 시간 내에 GC가 완료되지 않으면 Concurrent GC로 전환.

이로써 50밀리 세컨드 이내의 응답 시간이 필요한 프로그램이 40밀리 초의 실행 시간을 얻도록 한다. 이 수치는 1000달러 Linux PC 정도를 상정. 이른바 non-generational, non-moving, concurrent, tri-color, mark and sweep 컬렉터를 구현한다.

 

Go 1.6(2016 1) 1.5에서의 피드백을 바탕으로 목표를 결정하게 되지만 아마 bump pointer allocation nursery spaces generational copy를 도입하여 산출량을 향상시킨다.

 

Go 1.5에서 도입되는 새로운 알고리즘에서는 지연은는 크게 짧아지지만 스루풋이 저하된다. 그것을 상쇄하는 별개의 최적화를 하고, 버전을 올림으로써 성능이 악화되지 않도록 한다.

 

 

출처: https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLovrHvvLhK_h0KN8woTO4/edit

저작자 표시
신고
by 흥배 2015.07.30 08:00

Go 1.5 릴리스는 2015 8 1일 예정.

- 5월 시점에서 작업이 끝나 있고, feature freeze에 들어가 있음

- 여기까지 The State of Go에서의 정보

- 끝이 정확한 경우 곧 Release Candidate가 나올 것 같음

 

 

Go 1.5부터 년 2회 릴리스 계획

- 2 1, 8 1일 반년마다 메이저 (1.x) 출시

- 3개월은 개발, 3개월은 testing (feature freeze) 기간을 가진다

- http://golang.org/s/releasesched

 

 

 

Go 1.5에서 주목해야 할 새로운 기능과 변경 부분

출시되지 않았지만 저장소의 릴리스 노트에서 발췌

기대의 새로운 기능

- Shared Library

- Execution Tracing (go trace 명령)

- Concurrent Garbage Collection

- "vendoring"external package

 

신경 쓰이는 변경 부분

- 툴 체인에서 C언어를 배제(Go 1.5의 빌드에 Go 1.4 이상이 필요)

 https://talks.golang.org/2015/gogo.slide#1

 https://golang.org/s/go13compiler

 

 

Go 1.5의 차이

GOMAXPROCS 환경 변수가 기본적으로 CPU 코어 수로 된다

internal package 언어 사용자에게 도입

http://golang.org/s/go14internal

전술 한 바와 같이 출시 계획 변경하여 반년마다 년 2회 릴리즈

언어의 작은 변화

등등

 

 

Shared Library

buildmode라는 명령 줄 옵션이 새롭게 추가되어 shared object 생성이 가능.

$ go build -buildmode = shared ~ ~ 생략 생략 ~ ~

buildmode (go help buildmode의 일부를 짤라서 설명)

- archive : main 패키지 이외 .a 파일로 빌드

- c-archive : main과 필요한 패키지를 C언어용 아카이브로 빌드한다. Go 소스 중에서 "//export funcname" 마크가 필요

- c-shared : c-archive shared library 작성 버전

- shared : main 패키지 이외를 shared library 화 하고, -linkshared 옵션으로 링크 할 수 있도록 한다

 

 

Execution Tracing

fine-grained로 성능 모니터링을 할 수 있게 되었다

감시 할 수 있는 stats : 각각의 시작 시간과 소요 시간

- Heap (GC)

- Goroutine

- 스레드

- Go Processor 마다의 프로필

 시스템 호출 스택 추적



제안 문서에서는 network IO도 대상 이었지만, 패치를 보면 IO 모니터는 확인할 수 없었다

 Go Execution Tracer : http://golang.org/s/go15trace

  Groups 스레드에서는 AMD Code Analyst Intel VTune을 의식한 발언도

 

 

"vendoring"external package

Go언어에서 import (go get) 버전 문제에 대한 실험적 노력

Go 사용자는 아시다시피 Go는 의존하는 외부 라이브러리의 버전을 지정하는 기능을 제공 하지 않는다

- 이를 해결하기 위해 Godep 명령과 같은 hack이 있다

- Go 공식 vendoring (의존 저장소를 자신의 저장소에 포함) 법이 실험적으로 지원된다

https://golang.org/s/go15vendor

 

 

Concurrent GC

GC Stop the world Concurrent GC의 하이브리드를 전부터 채택했다. 1.5에서는 stop the world에서 concurrent collector로 된 GC에 의한 정지 기간을 개선

- GC 지연 시간을 10ms 이하를 목표로 하고있다

GC에 의한 정지 기간을 짧게 하는 대신 CPU 및 메모리 소비가 약간 증가

대부분의 경우 goroutine의 병렬 때 CPU 사용율이 오르는 것 같다

디자인 문서

https://golang.org/s/go14gc

  https://golang.org/s/go15gcpacing

 

 

 

trace 명령어 소개(Execution Tracing)

$go test -‑‒trace=/tmp/trace -‑‒run=BenchName-‑‒bench=BenchName cpu=4

$PATH=trace-‑‒viewer/tracing:$PATH trace -‑‒http=localhost:9876 path/to/ testbinary.test /tmp/trace


 

설명: http://golang.org/s/go15trace

 

 

출처: http://www.slideshare.net/pfi/go15-50328018

저작자 표시
신고
by 흥배 2015.07.27 08:00

서두

Swift Apple 사에서 개발 된 완전히 새로운 프로그래밍 언어이다. WWDC 2014에서 번개처럼 나타난 이 프로그래밍 언어는 순식간에 전세계 모바일 앱 개발자의 주목을 끌었다.

 

Swift는 충격적인 등장 이었기 때문에 갑자기 나타난 기술인 것처럼 볼 수도 있지만, 개발이 시작된 것은 2010 년이었다고 한다. 또한 Swift가 태어난 것은 Apple이 갑자기 새로운 영역에 내 디딘 것이 아니라 오랜 컴파일러 관련 기술 개발에 크게 노력해온 결과이라고 필자는 생각하고 있다.

 

본 문서는 Apple의 컴파일러 관련 기술을 돌아보며 Swift에 어떻게 연결되는지를 설명한다.

 

 

Objective-C와 컴파일러

Apple Steve Jobs의 복귀 이후 BSD 기반의 OS X​​ Intel 아키텍처로의 전환 등 매우 대담한 기술적인 전환을 많이 하였고 성공시켜 왔다. 개발자들은 Apple의 방향성에 추종하면 마냥 좋았다. 그러나 새로운 프로그래밍 언어를 만드는 등의 전환은 Swift가 처음이다. Apple은 왜 새로운 프로그래밍 언어를 만들었을까? Swift에 이르는 길은 Apple의 컴파일러 기술을 돌아보는 것으로 끈을 풀 수 있다.

 

 

Objective-C 2.0에서 Modern Objective-C

Apple WWDC 2006에서 기존의 Objective-C에 큰 변화가 추가 된 Objective-C 2.0을 발표했다. 이 업데이트는 모던 Objective-C 프로그래밍을 지원하는 속성과 클래스 확장, fast enumeration 등이 추가 되었다. 이 때 추가 된 기능은 모두 현재의 Objective-C의 인기에 필수적인 요소이지만, 현재 남아 있지 않는 것이 한가지 있다. 바로 가비지 컬렉션이다.

 

Objective-C는 메모리 관리에 참조 카운트 방식을 채용하고 있다. 특히 iOS 4 이전 정도부터 iOS 앱 개발을 시작한 분들 중에는 경험을 한 사람은 많을 것이다. 그러나 2006 년 시점에서 Objective-C 가비지 컬렉션이 있었는데, iOS 앱 개발에 메모리 관리가 고통인지 의문에 드지않나? 가비지 컬렉션은 OS X 만 지원으로 iOS에서 지원 될 수 없었다. 따라서 iOS 앱 개발에서 메모리 관리는 프로그래머의 책임으로 오랫동안 골치 아픈 문제 중 하나였다.

 

그런 불우한 환경에도 한줄기 광명이 있다. ARC(Automatic Reference Counting) Static Analyzer의 등장이다. ARC는 컴파일 시에 참조 횟수를 증감하는 코드를 자동으로 채운다. Static Analyzer를 사용하면 정적으로 잠재적 인 메모리 누수를 자동으로 감지 할 수 있다. 이러한 기능의 등장은 Apple이 개발한 새로운 C/C++ / Objective-C 컴파일러 인 Clang이 크게 관여하고 있다.

 

기존 Objective-C 컴파일러는 GCC를 이용하고 있었지만, 확장이 어렵기 때문에 Apple Clang을 개발했다. Clang을 내포한 Xcode 4.2의 출시로 프로그래머의 부담은 크게 경감된다. 종래는 프로그래머가 세심하게 메모리 관리를 구현하고 있던 것이 자동으로 관리되도록 대체되어, 메모리 누수 유무 검사는 Leaks (메모리 누수 탐지기) 등을 실행하는 응용 프로그램에 연결하여 실제로 동작하면서 측정함으로써 메모리 누수를 감지하고 있던 것이 자동으로 검사 할 수 있게 되었다. 예를 들면 ARC는 구현에 따라서는 메모리 누수 또는 Static Analyzer에서 찾을 수 없는 메모리 누수가 존재하기 때문에 완벽한 것은 아니지만, 프로그래머의 부담이 크게 줄어든 것은 부인할 수 없는 사실이다.

 

Clang 도입이 가져온 것은 메모리 관리의 부담 경감에 국한되지 않는다. C/C++에 대한 Apple의 독자 확장인 Blocks(클로져와 비슷한 것)이나 Objective-C Modern syntax Apple은 최근 몇 년 WWDC에서 매번 이라고 해도 좋을 정도로 Objective-C에 여러 업데이트를 추가했다. 이 정도까지 Objective-C 자체를 업데이트 할 수 있었던 이유는 스스로 컴파일러를 개발하고 있었기 때문이다. Objective-C 2.0 에서 Modern Objective-C으로의 크게 진화할 수 있었던 주인공이 Clang 인 것은 분명한 사실이다.

 

 

Clang에서 Apple이 목표로 한 것

Clang을 말할 때 뗄래야 뗄 수 없는 관계에 있는 것이 백엔드인 LLVM이다. LLVM은 컴파일과 링크 시 런타임 등 모든 지점에서 프로그램을 최적화 할 수 있는 컴파일러 기반이다. 현재 최신 버전 인 Xcode 6.3.2 컴파일러 프론트엔드에 Clang, 백엔드에 LLVM 조합이 사용되고 있지만, LLVM이 채택 된 당초는 프론트엔드는 GCC가 사용 되고 있었다.

 

Objective-C는 매우 동적인 것이 특징인 언어 중 하나이다. 예를 들어, 실행 시에는 모든 객체는 id 형으로 되기 때문에 실행 시 클래스를 확장하거나 구현을 대체 하는 등 인터프리터 언어처럼 행동 할 수 있다. 물론 메소드의 실행에 관해서도 마찬가지이다. NSObject performSelector: 메서드 등에서는 현저하게 그 특징을 간파 할 수 있다. 이렇게 Objective-C는 동적 기능에 의해 매우 유연하게 프로그램을 작성할 수 있다.

 

하지만 동적 특징은 좋은 것만 있지 않다. 일반적으로 컴파일러 언어는 런타임 비용을 낮추기 위하여 실행 코드를 최적화한다. 그러나 Objective-C에서는 런타임에 많은 것이 정해지기 때문에 컴파일 시 최적화를 실시하기 어렵다는 단점이 있었다. iPhone으로 기세를 되찾았던 Apple에 있어서, 모바일에서의 경험 향상은 가장 큰 과제 중 하나이다. 가능한 한 애플리케이션에 최적화를 하고, 경험을 향상시키고 싶은 싶은 것이 본심이다.

 

LLVM이 제공하는 유연한 최적화는 Objective-C에 있어 매우 편리한 것이었다. 그러나 처음에는 프런트엔드에 사용하던 GCC는 거대한 소프트웨어임으로 족쇄가 되어 Apple이 요구하는 속도로 Objective-C의 성능을 향상하는 것이 어려워졌다.

 

그래서 Apple C/C++ / Objective-C를위한 LLVM 프론트엔드인 Clang을 개발했다. Apple이 단기간에 Objective-C를 대폭 업데이트 할 수 있던 것은 Clang을 개발함으로써 스스로 주도권을 가질 수 있게 된 것이 가장 컸다.

 

Apple 스스로 컴파일러를 개발하는 것은 프로그램 고급 최적화를 하기 위해서도 Objective-C를 더 빨리 진화시키기 위해 필수적인 것이었다. 하드웨어의 기능을 향상시키는 것은 말할 것도 없지만, 그 위에서 동작하는 소프트웨어에 대해서도 기초 기술에서부터 갈고 닦아서 iPhone이 높은 사용자 경험을 지켜 왔다고도 말할 수 있다. LLVM Clang Apple의 제품을 뒷받침하는 중요한 역할을 담당하고 있던 것이었다.

 

 

LLVM Swift

LLVM Clang으로 커밋이 어떻게 Swift으로 이어질까? Apple LLVM Clang에 의해 만들어 낸 환경을 Swift에서도 다시 시도했던 것은 아니다. 사실 Swift Objective-C와 같이 LLVM에서 작동하는 것이다. 왜 이런 일이 가능할까? 비밀은 LLVM의 구조에 있다.

 

LLVM은 다음과 같이 소스 코드를 기계어로 변환 실행한다.

  소스 코드 -> 프런트엔드 -> LLVM Optimizer -> 백엔드 -> 기계어

 

간단하게 설명하면 Clang GCC 등의 프론트엔드가 소스 코드를 받아 최적화를 실시하고 백엔드에 보내어 결국 기계어로 변환되어 실행된다. 여기에서 프런트엔드와 LLVM Optimizer, LLVM Optimizer와 백엔드 간에 각각 LLVM IR(Intermediate Representation) 형식으로 전달된다. 지금까지 감이 좋은 사람은 알아차렸겠지만 프런트엔드만 다른 언어로 대응하면 다른 언어도 LLVM에서 움질 일 수 있도록 설계되어 있다. 사실 GCC에서 컴파일 한 Ada Fortran과 같은 언어를 LLVM에서 작동 할 수 있다(LLVM 프로젝트의 DragonEgg를 참조). , Swift LLVM의 새로운 프론트엔드로 구현되어 있다는 것이다.

 

공식적으로 자세하게 소개 되어있는 것은 아니지만, 컴파일러 옵션 등에서 다음과 같이 LLVM IR로 컴파일 되는 것을 알 수 있다.

  소스 코드 -> Swift AST -> SIL -> LLVM IR

 

소스 코드는 먼저 Swift Abstract Syntax Tree (AST)로 변환된다. 다음 Swift Intermediate Language(SIL)로 변환되어 Swift를 위한 최적화를 실시한 후 LLVM IR로 변환 된 LLVM Optimizer에 보내진다. 또한, 이러한 중간 상태는 Swift 컴파일러에서 직접 검색 할 수도 있다. 컴파일러의 도움말(xcrun swiftc -help )을 보면 출력 방법을 알 수 있기 때문에 흥미 있다면 꼭 시험해 봐라.

 

이렇게 Swift에서도 LLVM 기술은 깊이 관련되어 있다. Swift Objective-C와 공존 할 수 있고 C를 직접 사용 할 수 있지만, 이렇게 할 수 있는 것은 공통 기반으로 LLVM이 있기 때문에이다. 그 덕분에 Objective-C 프로그래머는 조금만 공부하면 Swift를 잘 다룰 수 있고, Swift으로의 전환을 매우 완만하게 할 수 있다. 이것이 바로 Apple의 기술 선택이 매우 잘 빠져 있다는 것을 나타내는 좋은 예라고 할 수 있다.

 

 

 

출처: http://codezine.jp/article/detail/8768

 

저작자 표시
신고
by 흥배 2015.07.20 08:00

지구의 공전과 우리의 달력을 맞추느라 윤년이 존재하는 것처럼 지구의 자전과 시계를 맞추느라 윤초가 있다. 이런 종류의 미세 조정은 원자 시계가 발명되기까지는 문제가 없었다. 예를 들어 원자 시계의 하나인 세슘 시계는 지구 회전에 근거한 시계보다 훨씬 정확히 시간을 측정할 수 있다. 정확성에 의해 2개의 시계는 차이가 생긴다. , 지구의 자전을 기준으로 한 시간과 원자의 시간을 맞추기 위해 윤초가 필요하다.

 

윤초는 협정 세계시(UTC) 23 59 59초에 추가된다. 1초 미만의 시간과 마주 한 사람이나 컴퓨터 프로그램이 윤초에 대응하지 못해 크래쉬가 발생 하지 않는 한, 1초를 알아차릴 사람은 없을 것이다. 그러나 이것은 현실에서 일어날 수 있다. 2012년에 추가된 윤초로 "Reddit" "Gawker Media" "Mozilla"등의 애플리케이션이나 서비스가 다운된 적이 있다.

 

미국 콜로라도 주 볼더에 있는 미국 국립 표준 기술 연구소(NIST)의 물리학자 쥬다리바잉씨는 "이게 문제가 될 주된 이유는 많은 시스템이 제대로 윤초 대책을 못하기 때문입니다"라고 한다. 윤초는 불규칙하게 발생하기 때문에 프로그래머는 수정 프로그램을 테스트하는 것이 어렵다.

 

 

윤초는 어떻게 정해진다?

미국 워싱턴 DC에 있는 미 해군 천문대에서 시보 업무 부문의 선임 과학자에 따르면 "지구는 점점 느려지고 있으나 그 변화는 예측 못하고, 일부 기간에 집중해서 윤초가 발생할 수 있다"라고 한다.

 

국제 지구 회전·기준계 사업(IERS)이 항상 지구를 감시하고, 국제 전기 통신 연합(ITU)에 윤초 추가를 권고한다. 이를 받은 ITU가 추가 최종 결정을 한다.

 

최근 윤초는 2012년에 추가되었지만, 1980년대 초에는 시간 과학자들이 매년 윤초를 추가했다.

 

윤초가 처음 도입된 것은 1972. 워싱턴 DC에 있는 스미소니언 국립 항공 우주 박물관의 지리학자 앤드루 존스턴씨에 따르면 당시 이미 원자 시계와 천문학적 시계의 사이에는 10초의 차이가 있었으며, 전 세계의 천문학적 시계에 한꺼번에 10초를 덧붙였다.

 

 

표준 Windows시스템은 비대응

NIST의 타임키퍼가 윤초를 조정하는 책임을 지고 있다. 시각 조정은 NIST 23 59 59(UTC) 2회 송신함으로써 이루어진다.

 

NIST 본부가 있는 콜로라도 주가 속한 산악부 차관은 UTC보다 7시간 늦기 때문에 6 30일 오후 6시는 스트레스가 많은 시간대가 될 것 같다. "오후 6시 전후는 완전히 패닉 상태가 될 거예요"

 

윤초의 추가가 모두 잘 되어도 다음날 아침 다양한 문제에 관한 대량 메일을 받는 것이 보통이다.

 

Apple의 디바이스는 윤초를 인식하지만 그렇지 않은 것도 있다. Google의 휴대 단말은 보통 원자 시계에 관계하는 인터넷의 시보와 동기 하지만 표준 Windows 시스템을 쓴다면 윤초는 무시된다

 

금융 시장도 윤초를 고려하고 있다. 뉴욕 증권 거래소는 6 30일은 평소보다 30분 빠른 오후 7 30분에 닫고, 시스템 대응에 나설 것 같다.

 

GPS 등의 내비게이션 서비스는 윤초를 채용한 적이 없다. 위치 정보의 계산은 정확한 시간 측정이 필요하기 때문에 내부 시계를 멈춘다면 위치가 부정확하게 되기 때문이다.

 

다만, 엔드 유저가 이를 알 필요는 없다. GPS시스템이 수신기 ―― 아웃도어 용품점에서 입수한 것이나 스마트폰에서 ――에 윤초 정보를 보내기 때문에 디바이스 상에서는 올바른 시각이 표시되기 때문이다. 그러나 진짜 GPS 시각은 일반적인 시각과 16초 안팎 어긋나고 있다

 

 

몇 백년 무시해도 1,2분의 차이

윤초에 고민할 정도면 차라리 전면 폐지하자는 논의도 있다. 윤초 추가를 결정하는 NIST 내에서도 의견이 나뉘어져 올해 안에 다시 논의가 이루어지게 될 같다.

 

스미스 소니언 박물관의 존스턴 씨는 윤초에 "얽매이지 않는다"파이다. 그의 주위에는 폐지를 바라는 엔지니어도 많이 있지만 천문 학계 지인들은 남기고 싶어 하는 것 같다고 한다.

 

"아무래도 세상은 윤초를 없애는 방향으로 움직이고 있어요"라는 존스턴 씨. 그러나 우리는 국제 전기 통신 연합의 최종 판단을 기다려야 한다.

 

"개인적으로는 이런 일 그만두고 버리고 싶어요. 대신 그 대가로 원자 시간이 천문학적 시간에서 점차 멀어지는 것"이라는 리바잉 씨. 그러나 수 백년이 지나도 불과 1,2분 차이 밖에 안 된다.

그것도 나쁘지 않다고 리바잉씨는 생각한다. 윤초를 폐지하면 "내 인생은 더 편하게 될 것입니다"

 

 

출처: http://natgeo.nikkeibp.co.jp/atcl/news/15/b/063000016/

저작자 표시
신고
by 흥배 2015.07.15 08:00

1: svchost.exe

용도:     Windows 서비스의 호스트 프로세스

파일 이름:         svchost.exe

위치:  %windir%\System32\svchost.exe

 

이것은 Windows OS 중에서 동작하는 각종 "서비스"를 호스팅 하는 프로세스이다. Windows OS의 서비스는 작업 관리자의 서비스 탭에서 확인할 수 있다. 이러한 서비스를 먼저 시작하기 위해 사용하는 것이 svchost.exe이다. 서비스 처리 부하가 높아지면 이 svchost 프로세스의 CPU 사용률 값이 상승한다.

 

하나의 Windows 시스템에서 서비스는 수십 개의 동작 하고 있다. 그들은 몇 가지로 그룹화되어 각 그룹마다 svchost.exe 프로세스가 하나씩 시작된다. 따라서 하나의 시스템 중에는 여러 svchost.exe 프로세스가 존재한다.

 

 

2:  TrustedInstaller / TiWorker / msiexec

용도:     Windows 설치 프로그램

파일 이름:         TrustedInstaller.exe / TiWorker.exe / MSIEXEC.EXE

위치:     %windir%\servicing\TrustedInstaller.exe /

% windir%\WinSxS\이하 ( WinSxS 폴더 안에는 여러 버전의 파일을 폴더 별로 나누어 져 저장되어있다 ) /

%windir%\System32\msiexec.exe,

 

이들은 Windows OS에 새로운 프로그램이나 모듈 업데이트 등을 설치하기 위해 이용되는 프로그램이나 그 보조 과정이다. 사용자가 명시 적으로 설치하는 경우뿐만 아니라, 예를 들어 Windows Update에 의한 자동 백그라운드에서 설치 시 등에도 실행 되고 있다.

 

 

3: MsMpEng

용도:     Microsoft Security Essentials의 실행 프로그램

파일 이름:         MsMpEng.exe

위치:     % ProgramFiles%\Microsoft Security Client\MsMpEng.exe

 

이것은 안티 멀웨어 소프트웨어인 Microsoft Security Essentials의 실행 프로그램이다. 시스템이 부팅 직후부터 실행을 시작하고 상시 파일을 검사하여 악성 코드에 감염되지 않았는지 등을 검사 하고 있다.

 

일반적으로 백그라운드에서 동작하므로 사용자의 작업에는 별로 영향을 주지 않도록 되어 있다. 그러나 설치되어있는 프로그램이 많으면 스캔에 시간이 걸려 부하도 높아진다.

 

C 드라이브의 사용량이 많으면 MsMpEng 프로세스의 부하가 높아질 수 있다(부팅 후 수십 분 부하가 높다). 경험상 C 드라이브의 사용량을 억제하거나 하드 디스크가 아닌 SSD로 하면 상당히 개선된다.

 

MsMpEng 설정을 변경하여 검사의 빈도를 낮추는 방법도 있다. 그러나 보안을 생각하면 그다지 추천 할 수 없다.

 

 

4 : SearchIndexer / SearchProtocolHost / SearchFilterHost

용도:     Windows Search (인덱스) 서비스 호스트 프로세스

파일 이름:         SearchIndexer.exe / SearchProtocolHost.exe / SearchFilterHost.exe

위치:     %windir%\System32\SearchIndexer.exe

%windir%\System32\SearchProtocolHost.exe

%windir%\System32\SearchFilterHost.exe

 

이들은 파일 검색 속도를 고속화 하는 "인덱스"를 만드는 프로세스이다. 새로운 파일이 추가 또는 수정 된 경우에 부하가 무거워 지므로 억제하고 싶으면 제어판의 색인 옵션에서 검색 범위를 제한하는 등의 설정을 실시한다.

 

 

5: wuauclt

용도:     Windows Update 관련 프로세스

파일 이름:         wuauclt.exe

위치:     %windir%\System32\wuauclt.exe

 

이것은 Windows Update 관련 프로세스이다. 새로운 Windows Update의 업데이트가 있는지 시스템에 적용할지 여부 등의 판단 · 처리 한다.

 

Windows Update의 처리에 과거 몇 차례 CPU 사용률이 비정상적으로 상승하는 문제가보고 된 적이 있다. CPU 사용률의 증가가 Windows Update의 처리로 인한 여부는 Windows Update 처리 (확인)를 수동으로 시작하거나 정지 시키면서 체크해 보면 된다.

 

또한 Windows Update에서 업데이트를 적용 하려면 이 wuauclt 프로세스가 아닌 svchost.exe 및 설치 관련 프로세스의 CPU 사용률이 증가 할 수 있다.

 

 

6 : mscorsvw / ngen

용도:     .NET Framework의 최적화 과정

파일 이름:         mscorsvw.exe / ngen.exe

위치:     %windir%\Microsoft.NET\Framework\<옵션>\mscorsvw.exe

%windir%\Microsoft.NET\Framework\<옵션>\ngen.exe

 

이것은 .NET Framework를 사용한 프로그램의 " 최적화" 프로세스이다.

.NET Framework를 사용하는 프로그램이나 패치 등을 설치/업데이트 한 직후에 실행 되는 것을 잘 볼 수 있다.

 

.NET Framework를 사용하여 작성된 프로그램(.NET 어셈블리)는 중간 언어 CIL(Common Intermediate Language) 로 작성 되어 있다. 이러한 프로세스는 이를 미리 컴파일 하여 타겟 CPU의 바이너리 코드로 변환하는 작업을 하고 있다.

 

예를 들어 개발 도구 Visual Studio를 설치 한 경우, 설치된 .NET 어셈블리의 수가 많으면 처리에 시간이 걸린다. 그럼에도 불구하고 1 ~ 2 시간 정도 지나면 종료 할 것이다.

 

 

7 : taskhost

용도:     Windows 작업 호스트 프로세스

파일 이름:         taskhost.exe

위치:     %windir%\System32\taskhost.exe

 

taskhost.exe Windows OS 'task'을 시작하는 프로세스이다.

 

태스크는 정해진 시간과 타이밍(시작하거나 로그온 시 등)에 시작되는 프로세스이다. 작업은 컴퓨터 관리 도구에서 시스템 도구] - [태스크 스케줄러]에서 설정, 관리한다. 지정된 시간과 타이밍이되면 taskhost.exe가 실제 태스크를 담당하는 프로세스를 시작 하도록 한다.

 

따라서 taskhost.exe가 무거워지는 것이 아니고, taskhost에서 시작되는 프로세스가 무거워지는 경우가 대부분이다. 작업 관리자에서 실행 된 프로세스는 taskhost는 별도의 프로세스로 표시된다.

 

만약 taskhost CPU 사용률이 높아지고 있다면, 그것은 시작하려고 한 작업 측에 문제가 있어서 올바르게 시작할 수 없거나, 혹은 여러 번 다시 시작하려고 시도하고 있다 라고 생각할 수 있다.

 

 

8 : System

용도:     Windows NT 커널 시스템

이름:     System

PID:      4 (프로세스 ID는 항상 4)

위치:     - (없음)

 

System 프로세스는 Windows OS의 커널에서 실행되는 처리를 담당하는 프로세스이다. 다음의 "System Idle Process"와 같이 가상적인 과정이며, 프로세스 ID는 항상 4이며 대응하는 실행 이미지 파일은 존재하지 않는다(굳이 말한다면, 커널 전체가 이 프로세스에 대응한다).

 

Windows OS의 커널 내부에서 다양한 모듈 및 서브 시스템 장치 드라이버 등이 작동 하고 있다. 모두 이 시스템 프로세스(및 그 내부에 있는 시스템 스레드)에서 작동 하고 있다. 일반적으로 커널의 처리는 그다지 부하가​​ 높지 않고 System 프로세스가 CPU 사용률의 상위에 나올 수는 없다. 고작 몇 %정도(성능이 낮은 PC라면 더 높을 수도 있다).

 

하지만 가끔 장치 드라이버 등에서 고장 나면 CPU를 비정상적으로 점유 해 버리는 경우가 있다. 그런 경우 System 프로세스가 CPU 사용률의 상위에 나오거나, 일정한 CPU 사용률이 계속 지속되는 등의 문제가 발생할 수 있다.

 

새로운 장치와 지원 프로그램 등을 설치하여 CPU 사용률을 계속 높게 유지하는 경우(예를 들어 1 코어씩 계속 소비하는 것을 계속하는 등) 설치 한 장치에 대한 문제 등을 의심해 보면 좋을 것이다.

 

 

9 : System Idle Process

용도:     시스템 유휴 프로세스(가상적인 과정)

이름:     System Idle Process

PID:      0 (프로세스 ID는 항상 0)

위치:     - (없음)

 

프로세스를 CPU 사용률 순서로 정렬한 경우 항상 이 "System Idle Process"라는 프로세스가 상단에 있고, CPU 사용률도 90 % 이상으로 되어 있는 경우가 많다. 하지만 이것은 가상적인 과정이며, 실제 이와 같은 이름(파일 이름) 프로그램이 있는 것은 아니다.

 

시스템에서 실행중인 모든 프로세스는 실행을 위한 큐(대기중인 행렬)에 등록 되어있다. 실행하는 프로세스가 하나도 없으면 가상으로 이 System Idle Process라는 프로세스가 실행되는 것처럼 행동하게 되어 있다.

 

, 이 프로세스가 99 % 실행되는 것은 실제로 CPU 99% 유휴(대기) 상태라는 것을 나타낸다. 수치가 높아도 걱정할 것은 아니다.

 

이 프로세스의 PID(프로세스 ID)는 항상 0이다. 만약 0이 아닌 경우 바이러스 등이 위장 하고 있을 가능성이 있다.

 

 

10 : 시스템의 인터럽트

용도:     인터럽트 처리(가상적인 과정)

이름:     지연 프로시저 호출과 인터럽트 서비스 루틴

PID:      - (없음 프로세스 ID 부분의 표시는 항상 "-")

위치:     - (없음)

 

이 시스템 인터럽트도 편의상 프로세스로 표시 되어 있을 뿐 실제로는 해당 프로세스(실행 파일)이 있는 것은 아니다. 이 프로세스를 보면 인터럽트의 '지연 프로 시저 호출' 처리에 얼마나 많은 CPU 파워가 소비되고 있는지를 확인할 수 있다. 그러나 Windows 8 / Windows Server 2012 이후의 작업 관리자에서만 표시된다.

 

인터럽트는 장치 등에서 송신되는 이벤트 트리거 이며, 예를 들면 데이터 준비가 끝나서 오류가 발생했다는 같은 경우 OS에 그것을 알리기 위해 사용된다.

 

인터럽트 처리 루틴에서 장치 상태를 확인하고 데이터를 읽어내는 '준비'만 하고 인터럽트 처리를 완료한다. 실제로 데이터의 수신 처리를 실시하는 것은, 인터럽트 "지연 프로시저(지연 절차)"의 책임이다. 즉 인터럽트 발생시 신속하게 대응하는 것이 인터럽트 처리 루틴, 나중에 천천히 사후 처리하는 것이 지연 절차이다.

 

시스템의 인터럽트 프로세스 CPU 사용률이 높아진다는 것은 인터럽트의 지연 처리 절차가 남아있는 것을 나타낸다. 성능이 낮은 CPU에서는 이 프로세스의 처리에 시간이 걸리기 때문에 시스템의 인터럽트 프로세스의 CPU 사용률이 높아진다.

 

또한 장치 드라이버에 문제가 있어서 처리가 늦어지고 있는 경우도 CPU 사용률은 증가 하게 된다. 이 경우에도 장치 드라이버 주위의 문제를 의심 할 필요가 있을 것이다.

 

 

 

번외 : rundll32

용도:     Windows DLL 호스트 프로세스

파일 이름:         rundll32.exe

위치:  %windir%\System32\ rundll32.exe

 

이것은 다른 DLL(예를 들면 제어판 애플릿의 DLL) 등을 실행하는 데 사용되는 호스트 프로세스이다. 이 프로세스의 CPU 사용률이 높다는 것은 사실 이 rundll32에 의해 시작되는 프로그램의 CPU 사용률이 높다는 것이다. rundll32가 무엇을 시작했는지는 rundll32 프로세스에 전달 된 매개 변수를 살펴볼 필요가 있다.

 

그러나 작업 관리자에서 봐도 단순히 "rundll32.exe"이라고만 표시 되고 무엇을 시작하고 있는지 자세히 알 수 없다. 자세히 알아 보려면 SysInternals "Process Explorer"와 같은 도구를 이용할 필요가 있다.

 

 

번외 : taskmgr / perfmon

용도:     작업 관리자 / 리소스 모니터

파일 이름:         taskmgr.exe / perfmon.exe

위치:     %windir%\System32\taskmgr.exe /

%WINDIR%\SYSTEM32\perfmon.exe

 

이것은 작업 관리자와 거기에서 시작되는 리소스 모니터에 해당하는 과정이다. 자신을 가리키는 것이므로 이 항목은 CPU 사용률의 상위에 있다고 걱정할 필요는 없다.

 

 

번외 : csrss

용도:     클라이언트 서버 런타임 프로세스

파일 이름:         csrss.exe

위치:     %windir%\System32\csrss.exe

 

이것은 Windows OS에 로그온 한 경우의 사용자 세션(사용자 별 프로그램 실행 환경)를 준비 하기 위한 프로세스이다. 이것도 CPU 사용률의 상위에 있다고 해서 특별히 신경 쓸 필요는 없다.

 

 

번외 : dwm

용도:     바탕 화면 창 관리자

파일 이름:         dwm.exe

위치:     %windir%\System32\dwm.exe

 

이것은 Windows 바탕 화면 관리자 프로세스이다. Windows 7에서 말하는 수의 Aero 미리 보기와 플립 3D 등을 실현 하고 있다. CPU 사용률의 상위에 있다고 해서 특별히 신경 쓸 필요는 없다.

 

 

번외 : makecab

용도:     Cabinet Maker(.CAB 파일 메이커)

파일:   makecab.exe

위치:     %windir%\System32\makecab.exe

 

이것은 .cab 파일 (Windows OS에서 자주 사용되는 파일 압축 형식)을 만들기 위한 프로세스이다. 예를 들어 로그 파일 등을 압축하여 디스크 공간을 넓히기 위해 사용 되고 있다. 대부분의 경우 바로 끝나므로 CPU 사용량 상위에 있다고 해서 특별히 신경 쓸 필요는 없을 것이다.

 

 

출처: http://www.atmarkit.co.jp/ait/articles/1505/15/news022.html

 

저작자 표시
신고
by 흥배 2015.07.06 08:00

들어 본 적이 없을지도 모르지만, 당신이 Chrome 사용자라면 이미 Google QUIC 프로토콜을 사용하고 있을 가능성이 높다. 지난주 Google이 발표 한 바에 따르면, Chrome에서 Google 서버로 전송되는 요청의 절반은 QUIC가 사용 되고 있다.

 

도대체 왜 중요한 것인가? QUIC Google에 따르면 UDP 수준의 실험적 저 지연 인터넷 프로토콜이며, UDP는 게임, 스트리밍 미디어 및 VoIP 서비스에서 자주 사용되는 프로토콜이다. 'QUIC'라는 이름은 Quick UDP Internet Connection에서 비롯되었다.

 

프로토콜 세계에서 UDP( QUIC)와 비교되는 것은 TCP이다 (Internet Protocol [IP]와 함께 인터넷의 핵심 통신 언어이다). UDP TCP보다 상당히 경량이지만, 그 대신 TCP보다 지원하는 오류 정정 서비스가 적다. 이것은 전송 서버가, 예를 들어 데이터가 도착했는지, 올바른 순서로 도착 했는지를 조사하기 위해 수신 서버와 자주 교환하지 않는 것을 의미한다. UDP가 게임 서비스에 최적인 이유는 여기에 있다. 이러한 서비스는 오버 헤드를 줄이고 지연을 최소화하는 것이 바람직하며, 만일 최신 마우스 동작을 서버가 수신하지 않았다면 1~2 초를 보내면서 정정 할 필요는 없다 - 왜냐하면 액션은 이미 앞으로 진행 하고 있기 때문이다. 그러나 웹 사이트의 요청에 적합하지 않다. 왜냐하면 모든 데이터가 도착한 것을 보장 할 수 없기 때문이다.

 

QUIC에서 Google의 목표는 UDP TCP의 좋은 점을 가지고 최신 보안 기술과 결합했다.


 

일반 보안 TCP 연결은 브라우저가 실제로 데이터를 수신하기 시작까지 2~3 회 교환이 행해지는 것이 보통이다. QUIC를 사용하면 브라우저는 과거에 주고 받은 서버는 즉시 통신을 시작할 수 있다. 또한 QUIC는 혼잡 제어와 자동 재전송 등의 새로운 기능을 도입함으로써 순수 UDP보다 신뢰성을 높이고 있다.

Google은 나중에 HTTP/2 표준의 기초가 된 SPDY라는 QUICK과 같은 목적을 가지는 대체 프로토콜을 이미 개발하고 있지만, HTTP/2 TCP에서 작동하고 있기 때문에 같은 지연 문제를 안고 있다.

 

그렇다면 왜 Google TCP의 개선 작업을 하지 않을까라는 의문을 생각해 보는 것은 당연하다. 문제는 회사의 지적에 따르면, TCP 지원은 종종 운영 체제에 직접 통합 되어있는 것이다 - 그리고 OS Google의 제어가 전혀 미치지 못하는 부분이다. "QUIC 이라면 새로운 아이디어를 실험하고 즉시 결과를 볼 수 있다" 라고 팀은 이 방식을 채용 한 이유를 밝혔다. "효과가 입증 된 날에는 QUIC 기능이 TCP TLS로 전환되는 것을 바라고 있다." 아직 설치 되어 있는 Windows XP의 수를 감안하면 그것은 하룻밤 사이에 일어날 것이 아닌 것은 분명하다.

 

만약 Google이 새로운 프로토콜을 설계하면 인터넷의 근간을 지탱하는 모든 컴퓨터도 그것을 이해 해야 한다 - 그러나 그들이 이미 이해 하고 있는 것은 UDP이다.

 

Google에 따르면, QUIC Google 검색에서 평균 페이지 로딩 시간 약 3%의 개선을 보이고 있다. 별거 아니 것처럼 들리겠지만 Google 검색이 이미 최대한 최적화 되어 있는 것을 잊어서는 안된 다. 다른 사이트 - 특히 대기 시간이 긴 웹 애플리케이션 -는 더 큰 개선이 전망된다. YouTube QUIC 통해 접속 한 사용자는 비디오 시청 중 재 버퍼링이 약 30% 감소 되었다는 보고가 있으며, QUIC의 개선 된 혼잡 제어 및 UDP 손실 복구에 의해 매우 느린 연결의 사용자가 QUIC 의한 페이지 로딩 시간 개선을 볼 수 있다.

 

Google HTTP2-over-QUIC를 미래의 새로운 인터넷 표준으로 IETF에 제안 할 계획이라고 말했다.

 

이것은 다양한 의미로 Google SPDY 노력과 유사하다. 회사는 그 때도 먼저 Chrome과 자사 서비스에서 프로토콜 프로토 타이핑을 수행 한 다음 HTTP의 새로운 버전 기반으로 제안했다.

또한 자신의 Chrome QUIC를 사용하여 연결하고 있는지를 알기 위해서는 이 브라우저 기능 확장을 설치 하면 된다(https://chrome.google.com/webstore/detail/http2-and-spdy-indicator/mpbpobfflnpcgagjijhmgnchggcjblin?hl=en).

 

 

출처: http://techcrunch.com/2015/04/18/google-wants-to-speed-up-the-web-with-its-quic-protocol/#.iziele:LJq8

 

 

C++ 라이브러리

libquic: https://github.com/devsisters/libquic

저작자 표시
신고
by 흥배 2015.07.02 08:00

요약: GCM 3.0에 대한 소개로 큰 특징은 토픽에 클라이언트를 등록하면 이 토픽에 메시지를 보내면 등록된 모든 클라이언트에 메시지를 보낼 수 있다. 게임을 예를 들면 AAA 라는 게임의 전체 유저에게 메시지를 보내기 위해서 AAA라는 토픽을 만들고, 이 토픽에 클라이언트를 등록하고, AAA에 토픽에 메시지를 보내면 모든 클라이언트에 메시지가 날아간다.

iOS의 경우 기존에는 GCM이 아닌 애플의 시스템을 사용해야 하는데 이제 GCM을 통해서 iOS쪽에도 메시지를 보낼 수 있다. GCM을 통해서 모든 플랫폼 유저에게 메시지를 보낼 수 있다.

 

 

GCM 3.0에서 Google이 시도한 것은 등록 프로세스를 간소화 하고 동사의 클라우드 통지 시스템을 Android, iOS, Chrome에서 똑같이 동작하는 것이다. 그래서 새로운 토픽 그룹과 메시지 진단 도구가 마련되었다.

 

애플리케이션은 각각 특정 기기 상에서 동작하는 애플리케이션과 관련된 식별자로 인스턴스 ID를 받는다. 인스턴스 ID는 애플리케이션이 그 장치에서 제거될 때까지, 각각의 어플리케이션의 수명을 동안 유효하다. 푸쉬 메시지는 API 호출을 통해서 생성되는 보안 토큰을 사용하여 인증한다. 보안 토큰이 훼손된 경우에는 바꿀 수 있다.

 

GCM의 편리한 기능으로 장치 그룹이 있다. 통지 키를 수신하는 GCM 상에서 장치 그룹을 생성하고, 그룹 전체에 메시지를 전송할 수 있다. 그룹은 편집하거나 클라이언트를 추가 또는 삭제 할 수도 있다. 그룹에는 최대 20개의 디바이스를 포함할 수 있다. 한 명의 사용자가 소유하는 모든 디바이스에 메시지를 송신할 때 실용적인 방법이다. 클라이언트 그룹에 메시지를 보낼 수 있다.

 

GCM 3.0에서는 다수의 클라이언트에게 메시지를 송신하는 토픽 메세지가 도입 되었다. 하나 이상의 주제를 생성하고, 각 주제에 클라이언트를 등록한다. 그 사안에 대해서 메시지를 전송하면, 등록된 모든 클라이언트에게 GCM이 정보를 통지하는 구조이다. 이 방법으로 다수의 클라이언트, 경우에 따라서는 모든 클라이언트에게 전달 할 수 있다.

 

개발 콘솔에 GCM 진단 메시지용 도구가 추가됐다. 최대 30개의 최신 메시지를, 상세한 정보와 함께 확인할 수 있다. 이 툴에서는 메시지 송신 후 몇 분간의 진단 정보를 취득할 수 있다.

 

이들 새 기능은 Android, iOS, Chrome 상에서 거의 똑같이 동작하지만, Apple의 디바이스에 메시지를 전송할 경우에는 한가지 차이가 있다. iOS에서는 우선 APNS 서버에 접속하여 토큰을 받고 그것으로 GCM 토큰을 취득해야 한다. 실제 통신에서는 애플리케이션이 iOS 기기 상에 있는 한 GCM APNS를 사용하여 메시지를 송신한다. 그러므로 애플리케이션의 동작은 Apple의 통지 시스템을 사용하는 경우와 같다. 앱이 액티브 하게 되면, GCM은 앱과 직접 통신한다. 업 스트림 메시지나 멀티 캐스팅, 메시지 스트리밍 등을 포함한 모든 GCM API iOS 앱에서 사용 가능하게 되었다.

 

Google은 현재 GCM에는 60만 개의 앱이 등록되어 있고, 매초 110만개의 메시지를 15억대의 디바이스에 송신하고 있다. 2015년 안에 처리하는 메시지의 수는 25조가 넘을 전망이다. 메시지의 평균 대기 시간은 세계 전체에서 50ms이다. 서비스는 계속 무료로 사용할 수 있다.

올해 I/O 2015세션(https://www.youtube.com/watch?v=gJatfdattno&feature=em-uploademail)에서는 GCM 3.0이 더 상세히 소개되고 있다.

 

출처: http://www.infoq.com/news/2015/06/gcm-3

저작자 표시
신고
by 흥배 2015.06.29 17:54

헬륨을 밀봉한 HDD. 현재는 HGST만 있음

공기 저항이 1/7이 되어서

 플랫 수가 5에서 7로 증가하여 대용량화

 소비 전력 감소, 소음 감소, 저온화

밀봉하고 있어서

 공기가 들어가지 않기 때문에 사고률이 감소. MTBF 250만 시간

 공기 이외의 새로운 냉각 방식을 채용 가능(수냉/유냉)

보통의 7200 회전과 같은 속도라고 생각하면 좋음

가격은 기존의 HDD 보다 아직 비싸지만 전력, 공간 비용을 생각하면 좋은 선택기

 

출처: http://www.slideshare.net/MasayaIshikawa/201506-dba/19

 

 

저작자 표시
신고
by 흥배 2015.06.25 08:00
| 1 2 3 4 5 6 7 ··· 43 |