apt-get dist-upgrade이전 시스템에서는 4GB 비디오 파일 복사와 같은 일부 과도한 I/O 작업을 수행하는 동안 데스크톱이 정지되는 현상을 경험했습니다. 하지만 이제 상황은 더욱 악화되었습니다. 어떤 작업이라도 apt-get install전체 데스크톱을 정지시키기에 충분했고, 비디오를 복사해도 nice -c 3전혀 도움이 되지 않았고 몇 분 동안 아무것도 할 수 없었습니다. 에 따르면 man ionice,유휴 I/O 프로세스는 정상적인 시스템 활동에 영향을 주지 않아야 합니다.
이상한 스왑 문제도 있었습니다. 스왑 파티션을 비활성화했는데 OOM이 두 번 실행되었습니다. 그러나 실행하여 작동하는지 확인했는데도 vm.oom_kill_allocating_task=1(내가 설정한) OOM을 트리거한 프로세스를 종료하는 대신 디스크가 회전하기 시작하고 오랫동안 데스크톱이 완전히 정지되었습니다.sudo swapoff -a
오래된 하드웨어 및 시스템:
- 하드 드라이브: 500GB Toshiba
- 시스템: Debian 7.9(32비트)
- 커널: 3.15.10-zen-686(Liquorix)
- 디스크 스케줄러: BFQ
- 파일 시스템: ext4
새로운 하드웨어 및 시스템:
- 하드 드라이브: 삼성 1TB
- 시스템: Ubuntu 15.10(64비트)
- 커널: 4.2.0-30-일반
- 디스크 스케줄러: 마감일(기본값)
- 파일 시스템: Btrfs를 사용하여 암호화된 LVM
CFQ 스케줄러에서 Deadline으로 변경하여 비슷한 문제를 해결하는 사람들이 많이 있지만 Ubuntu 커널에서는 Deadline이 기본값입니다. 소위 빠른 BFQ 디스크 스케줄러(암호화 없음)를 사용하는 데 문제가 있었습니다.
답변1
분명히 가장 큰 문제는 교환 문제입니다. 이전 시스템에서는 이 설정을 사용하면 vm.swappiness=100메모리가 부족해지기 전에 페이지를 이동하여 시스템이 정지되는 것을 방지할 수 있었습니다. 이 새로운 시스템에서는 반대 효과가 있는 것처럼 보였습니다. 시스템은 항상 불필요한 교체를 계속했습니다. 추가 메모리를 구입하고 스왑을 완전히 비활성화했으며 문제는 대부분 해결되었습니다.
I/O 작업으로 인해 데스크톱이 정지되는 현상은 해당 작업에 대한 데이터가 RAM에 캐시되고 데스크톱 애플리케이션에서 사용하는 메모리가 스왑에 투입되어 시스템이 디스크에서 다시 읽게 되기 때문인 것 같습니다. 데스크탑 시간과 상호 작용하려고 할 때마다.
RAM이 충분하면 I/O 작업이 데스크탑 응답성에 거의 영향을 미치지 않습니다. 그러나 데스크탑을 일정 시간 동안 방치하면 데스크탑과 상호 작용할 때 초기 지연이 발생할 수 있습니다. 이는 커널이 시스템이 작업에 더 높은 우선순위를 부여할 만큼 충분히 유휴 상태라고 간주하고 해당 데이터가 캐시를 완전히 채워서 데스크톱 응용 프로그램에서 페이지를 제거할 수 있다고 간주하기 때문일 수 있습니다.
디스크 스케줄러에 관해서는 어느 것이 최선의 선택인지 알기 위해 충분한 테스트를 수행하지 않았지만 조사에 따르면 마감일을 완전히 무시하거나 ionice이것이 ioniceCFQ에만 해당되는 것 같습니다.