지난 주, 나는 컴퓨터가 심각하게 느려졌다는 것을 알았다. 내 일상적인 일은 영원히 계속되는 것 같고, 심지어 내 표준 JMP 데모도 익숙해 진 것보다 훨씬 오래 걸리고 있었다. 나는 권한 복구, 메모리 검사, 손상된 커널 확장이 있는지, 심지어는 Mac OS Mavericks의 깨끗한 버전을 설치하는 것으로 보아서 내가 보았던 동작을 수정하는지 확인하는 등의 일반적인 작업을 시도했습니다.
그런 다음 내 솔리드 스테이트 드라이브 (SSD)에서 계속 진행될 수 있다고 생각났습니다. 내 MacBook Pro와 함께 제공되는 원래의 하드 드라이브 (표준 회전 드라이브)가 있었기 때문에이를 설치하고 원래 드라이브에서 부팅을 시도했습니다.
컴퓨터의 성능을보기 위해 사용하는 프로그램은 Geekbench입니다. 다수의 프로세서, 그래픽 및 디스크 집약적 인 작업을 수행 한 다음 단일 및 다중 코어 성능 번호를 다시보고합니다.이 성능 번호는 이와 유사하게 지정된 컴퓨터 데이터베이스와 비교할 수 있습니다. 그런 다음 비슷한 성능을 얻었는지 확인할 수 있습니다.
음, 내 컴퓨터의 성능은 단일 코어의 경우 2,000, 멀티 코어의 경우 10,000이어야합니다. 싱글 코어는 700 개, 멀티 코어는 3,000 개였습니다. 원래의 HDD를 랩톱에 다시 넣을 때 성능은 약 2,000 및 8,500으로 향상되어 훨씬 더 가깝습니다.
그래서 분명히 내 운전으로 뭔가가 진행되고있었습니다. 포기하지 않으면, 나는 그것을 수리 할 수 있는지보기로 결심했다. 또한 JMP를 사용하여 일부 데이터를 수집하고 시각화 할 수있는 좋은 기회라고 생각했습니다. Digiloyd Tools Suite의 DiskTester라는 프로그램을 사용했습니다. DiskTester의 기능 중 하나는 재조정 SSD 기능입니다. 이렇게하면 드라이브의 여유 공간에 많은 양의 데이터를 기록하고 여러 번 반복 할 수 있습니다. 프로그램은 청크 오프셋을 MB, 평균 쓰기 속도, 현재 쓰기 속도 및 최소 및 최대 쓰기 속도로보고합니다.
Digiloyd Tools 개발자에 따르면이 드라이브는 "자체 정리 및 조각 모음을 통해이 처리에 응답합니다."이 프로세스가 드라이브에서 작동하는 경우 몇 번의 반복 작업을 수행하면 크게 개선되는 첫 번째 반복에 대해 상당히 나쁜 성능을보아야합니다.
그래서 나는 내 드라이브를 지우고 내 다른 내부 드라이브에서 부팅하여 복구 프로세스를 시작하여 밤새 실행하고 원시 데이터의 여덟 번의 반복을 수집했습니다.
DiskTester는 원시 데이터를 클립 보드에 복사 할 수있는 옵션을주었습니다.이 클립 보드는 이제 .txt 파일을 만들어서 JMP로 가져옵니다.
파일> 열기를 사용하여 .txt 파일을 가져온 다음 옵션이 주어지면 Open As : 데이터 (미리보기 사용)를 선택합니다. 그러면 JMP로 가져 오기 전에 데이터를 검사 할 수있는 옵션이 나타납니다.
열이 보이는 방식에 만족합니다. 123 아이콘을 보면 모든 데이터가 연속으로 표시 될 것입니다. 이는 원하는 것입니다. 이 창에서 열 이름을 지정할 수있는 옵션이 있습니다.
이제 원시 데이터를 JMP로 가져 왔지만 결과를 시각화하기 전에해야 할 단계가 하나 더 있습니다. 당신은 반복 열인 중요한 열을 놓쳤다는 것을 알 수 있습니다. 위상 또는 그룹화 변수로 사용하려면이 값이 필요합니다. 다행히 JMP에서 이것을 아주 쉽게 생성 할 수 있습니다. 새 열을 만든 다음 마우스 오른쪽 버튼을 클릭하여 열 정보로 이동합니다. 새 열을 만들 때 데이터를 초기화 할 수있는 옵션이 있습니다. 시퀀스 데이터를 선택한 다음 From에 1을 입력하고 To에 8을 입력하고 (1에서 8까지의 반복에서 데이터를 원함) Step에 1을 입력합니다.
마지막 블록은 482,176MB이고 프로그램은 128MB의 청크를 쓰고 있으며 이는 각 반복마다 3,767 개의 고유 한 측정 값이 있음을 의미합니다. 그래서 3767을 각 값 반복 N 번 필드에 넣을 것입니다.
행 3,767과 3,768을보고 내 작업을 확인할 수 있습니다. 물론, 3,767은 반복 1로 표시되고, 3,768은 반복 2로 표시됩니다. 이제 갈 준비가되었습니다.
그래프 빌더를 사용하여 데이터의 현재 상태를 확인합니다. MB 대신 GB 단위로 오프셋을 사용하면 모든 플롯에서 X 축의 레이블을 표시하는 더 좋은 방법 일 수 있습니다. 더 자세히 살펴보기 전에 마우스 오른쪽 버튼을 클릭하여 MB를 GB로 변환 할 것입니다. Offset MB, 수식을 클릭 한 다음 Offset MB를 가져 와서 1000으로 나눕니다. 이렇게하면 데이터 표로 돌아 가지 않고도 사용자 정의 변환 열이 만들어집니다. 나중에 이것을 사용할 것이므로 Offset GB라는 이름으로 마우스 오른쪽 버튼을 클릭 한 다음 Add : 데이터 테이블에 추가를 선택하십시오. 아래 그림은 각 반복에 대한 드라이브 전체의 성능 판독 패턴을 보여줍니다. 우리가 더 잘 볼 수 있도록 점의 투명도를 0.1로 낮추었 고 그래프에 더 낮은 사양 한계 인 110MB / 초를 추가했습니다.
그래프에서 볼 수 있듯이 첫 번째 반복에서의 성능은 모든 곳에서 발생합니다. 평균 쓰기 성능이 괜찮 으면 (91MB / 초) 디스크에 훨씬 더 느리게 쓰여지는 많은 128MB 청크가 있습니다. 그러나 반복 2에 의해, 상황은 크게 개선되기 시작합니다. 평균 쓰기 성능이 115MB / 초로 향상되었습니다. 반복 5에 의해 일들이 정착하기 시작했고, 그 시점에서 필자는 쓰기 성능에서 점근적인 행동을 보는 것처럼 보인다.
그러나 모든 반복을 통해 남아있는 것은 쓰기 성능을 위해 최고 40 %에 달하는 블록 대역입니다. 테스트가 끝날지라도 130 블록은 실적이 낮은 섹터에 있습니다. 이는 2,294 블록이 사양 한계보다 낮은 첫 번째 반복에서 크게 개선되었습니다. 그래프 데이터 빌더에 로컬 데이터 필터를 추가하면 처음과 마지막 반복에만 집중하고 성능을 비교할 수 있습니다. 쓰기 성능은 반복 1에서 크게 달라질 수 있지만 반복 8에서는 3 개의 직선이 나타나 드라이브의 모든 테스트 섹터에서 일관된 성능을 나타냅니다. 실적이 저조한 섹터의 원인은 여전히 나에게는 약간의 수수께끼이지만, 운영 체제에서는 프로그램이 다른 시스템 작업으로 인해 중단되어 측정 된 성능이 저하 될 수 있습니다. (누군가가 더 나은 가설을 가지고 있다면, 그것을 코멘트에 남겨 두십시오).
그래서이 큰 질문은 : "효과가 있었나요?"글쎄, 나는 그 사실을보고하게되어 기쁘다. 재조정 절차를 실행하고 랩탑에 드라이브를 재설치 한 후 Geekbench 점수는 2,900 / 9,500으로 돌아 왔으며 하드웨어 사양을 고려할 때 예상됩니다. 그리고 내 컴퓨터에서 발견 한 급격한 속도 저하는 더 이상 존재하지 않습니다.
