많은 파일을 포함하는 디렉토리를 열 때 왜 노틸러스가 매우 느린 지 궁금합니다. 예를 들어 내 / usr / lib 디렉토리에는 1900 개의 파일이 있으며 모든 것을 표시하는 데 약 5 초 이상 걸립니다. 몇 달 전에 우분투를 설치 한 이래로 정말 좋았고 때로는 성가시다. 나는 강력한 하드웨어가 없지만 Windows 탐색기가 이것보다 훨씬 빠르다는 것을 알고 있습니다.
속도를 높이기 위해 할 수있는 일이 있습니까?
우분투 10.04
많은 파일을 포함하는 디렉토리를 열 때 왜 노틸러스가 매우 느린 지 궁금합니다. 예를 들어 내 / usr / lib 디렉토리에는 1900 개의 파일이 있으며 모든 것을 표시하는 데 약 5 초 이상 걸립니다. 몇 달 전에 우분투를 설치 한 이래로 정말 좋았고 때로는 성가시다. 나는 강력한 하드웨어가 없지만 Windows 탐색기가 이것보다 훨씬 빠르다는 것을 알고 있습니다.
속도를 높이기 위해 할 수있는 일이 있습니까?
우분투 10.04
답변:
실행을 추적하면 nautilus
속도 저하가 두 가지 요소의 조합으로 인한 것임을 알 수 있습니다.
각 파일에 대한 유용한 정보를 표시하는 것이 현명합니다. 파일 내용을 살펴보고 사용할 아이콘을 결정하고 미리보기를 표시합니다. 환경 설정에서 미리보기를 끄면 톤을 낮출 수 있습니다.
그것은 쓸모없는 일을 많이합니다 (예를 들어 stat
, 각 파일을 여러 번 치고 /proc/filesystems
디렉토리가 아닌지 확인하는 것과 같은 ). 프로그래밍을 배우고 프로그램을 개선하며 패치를 보내면됩니다. 또는 저자에게 기능 요청을 보내십시오 (더 빨리 작성하십시오).
각 디렉토리에 대해 여러 외부 프로세스를 호출하지만 수행 한 작업을 살펴 보지 않았습니다.
strace -f -ttt -p1234 -o nautilus.strace
여기서 1234는 노틸러스의 pid입니다. 추적을 자세히 분석하지 않았으며 리드 업 (하위 프로세스와 관련된 많은 항목)과 파일 당 물건 (여러 파일 stat
및 open
일부 파일)을 살펴 보았습니다 .
ls
미리보기가로드되는 동안 큰 폴더를 즉시 나열 하고 탐색 할 수 있습니다. 올바르게 기억하면 Windows 탐색기가 이와 같이 작동합니다. 이와 같이 많이 사용되는 우분투 프로그램에는 믿기지 않습니다. 그러나 불평하지 말고 대신 기부하십시오
이로 인해 노틸러스 및 GVFS를 포함한 기타 프로젝트의 수석 개발자 인 Alexander Larsson 과 의 대화를 떠올 렸습니다.
Giles 의 대답 , 특히 파일 내용을 살펴 보는 Nautilus에 관한 내용은 Nautilus가 "느린"주요 원인에 대해 설명합니다. 그러나 Giles는 왜 이것이 느린 지 설명하지 않습니다. 어떤 사람들에게는 분명하지만 다른 사람들에게는 그렇지 않을 수 있습니다. Alex가 말한 내용은 다음과 같습니다.
빈 슬레이트로 시작한다고 가정하십시오. 즉, 파일 시스템에 전혀 액세스하지 않았습니다. 이제 stat (“/ some / dir / file”)을 실행한다고하자. 먼저 커널은 파일을 찾아야합니다. 기술적 용어로 inode라고합니다. 루트 디렉토리의 inode를 저장하는 파일 시스템 수퍼 블록을 살펴 보는 것으로 시작합니다. 그런 다음 루트 디렉토리를 열고 "some"을 찾은 다음 "dir"을 찾은 다음 결국 파일의 inode를 찾습니다.
그런 다음 실제로 inode 데이터를 읽어야합니다. 처음 읽은 후에도 RAM에 캐시됩니다. 따라서 읽기는 한 번만 발생해야합니다.
HD를 구식 레코드 플레이어로 생각하십시오. 바늘로 올바른 위치에 있으면 물건을 회전하면서 빠르게 읽을 수 있습니다. 그러나 일단“탐색”이라는 다른 장소로 옮겨야 할 때는 매우 다른 일을하고 있습니다. 팔을 물리적으로 움직 인 다음 올바른 장소가 바늘 아래에 올 때까지 플래터가 회전 할 때까지 기다려야합니다. 이러한 종류의 물리적 동작은 본질적으로 느리기 때문에 디스크 탐색 시간이 상당히 길다.
그래서 언제 찾아야합니까? 물론 파일 시스템 레이아웃에 따라 다릅니다. 파일 시스템은 읽기 성능을 높이기 위해 파일을 연속적으로 저장하려고 시도하며 일반적으로 서로 가까운 디렉토리에 대한 inode를 저장하려고 시도하지만 파일 작성 시점, 파일 시스템 조각화 등과 같은 사항에 따라 달라집니다. 이 경우 파일의 각 통계는 탐색을 유발하고 파일을 열 때마다 두 번째 탐색이 발생합니다. 따라서 아무것도 캐시되지 않을 때 시간이 오래 걸리는 이유입니다.
일부 파일 시스템은 다른 파일 시스템보다 낫습니다. 조각 모음이 도움이 될 수 있습니다. 앱에서 몇 가지 작업을 수행 할 수 있습니다. 예를 들어, GIO는 inode 번호가 디스크 순서 (일반적으로 가지고 있음)와 관계가 있기 때문에 무작위 검색을 최소화하기를 기대하기 전에 readdir ()에서 수신 된 inode를 정렬합니다.
중요한 것은 검색을 최소화하기 위해 데이터 스토리지 및 앱을 설계하는 것입니다. 예를 들어, 이것이 노틸러스가 / usr / bin을 읽는 속도가 느린 이유입니다. 일반적으로 파일의 확장자가 없기 때문에 각각에 대해 마법 스니핑을 수행해야합니다. 따라서 각 파일을 열어야합니다. => 파일 당 하나의 탐색 => slooooow. 또 다른 예는 gconf와 같이 많은 작은 파일에 정보를 저장하는 앱도 나쁜 생각입니다. 어쨌든 실제로 지연 시간을 숨기려고 시도하는 것 외에는 할 수있는 일이 많이 없다고 생각합니다.
그는 다음과 같은 메모로 끝났습니다.
이 딜레마에 대한 진정한 해결책은 회전하는 매체에서 멀어지게하는 것입니다. 인텔 SSD가 굉장하다고 들었습니다. 리누스는 그들에게 맹세합니다.
:-)
Thunar와 같은 대체 파일 관리자를 사용해보십시오. Thunar는 디렉토리 목록을로드하는 데 훨씬 빠르며 NTFS USB 하드 드라이브에서 ext4로 파일을 복사하는 데 더 안정적이지만 파일 세트가 많으면 노틸러스와 같은 문제가있는 것 같습니다.
스위치 스크립트 https://help.ubuntu.com/community/DefaultFileManager에 대한 링크는 다음과 같습니다.
Gnome 시스템에 xfce가 설치되어 있고 사용하지 않는 경우 exo-utils를 제거하십시오.
다운로드 후 Chrome이 파일을 올바르게 열지 못하는 문제와 함께 내 문제가 해결되었습니다.
"편집-> 환경 설정"의 "미리보기"탭에서 모든 옵션을 "사용 안 함"으로 전환하십시오.
또한 "Assistive Technologies"를 끄는 데 큰 도움이되었습니다. "시스템-> 환경 설정-> 보조 기술"에서이를 수행 할 수 있습니다. "보조 기술 사용"을 선택 취소하십시오.
후자의 변경 사항을 적용하려면 로그 아웃했다가 다시 로그인해야합니다.