“RAM을 할당하는 앱과 실제 RAM이 부족할 때 무언가가 SWAP으로 페이징됩니다”보다 가상 메모리에 더 많은 것이 있습니다.

Linux (및 UNIX의 경우)에서 시스템은 페이지를 최근에 RAM으로 읽도록 시도합니다. 프로그램 실행,로드 된 데이터, 최근에 기록 된 데이터 (이미 디스크에도 있음) 등. 같은 프로그램이 다시 실행되면 디스크에서 다시로드 할 필요가 없습니다. 일부 프로그램이 가상 주소 공간에 더 많은 메모리를 할당하도록 요청하면 먼저 디스크 액세스없이 남은 디스크 버퍼의 용도가 변경됩니다. 이것으로 충분하지 않으면 최근에 액세스하지 않은 일부 실행중인 앱 페이지가 실제로 스왑됩니다. Linux에서는 일반적으로 스와핑이 발생하지 않습니다. 일단 시스템이 스와핑을 시작하면 증가 된 드라이브 활동 (및 부진)을 발견하고 “아무것도 ..”로 이동합니다. 이는 일부 앱에서 메모리가 누수되거나 후드 아래에있는 무언가가 제어 할 수 없게 된 것을 의미하기 때문일 수 있습니다.

Windows는 전통적으로 어리석은 추가 습관을 가지고 있으며, 비활성 시간이 초과되면 전체 사용자 공간 앱을 교체합니다. 엄밀히 말하면, 용서없이 가능한 한 많은 RAM을 사용할 수 있도록 “만약의 경우”또 다른 배고픈 앱을 시작하고 싶었습니다. PC를 실행 상태로두고 몇 시간 동안 나가면 돌아 왔을 때 전환 한 앱이 스왑에서 다시로드됩니다. 이 동작은 Windows 2000에서 특히 고통스럽고 최신 Windows 버전에서는 점차 눈에 띄지 않습니다. W2k에서 스왑을 끄는 것은 쉬운 일이 아닙니다. Windows 7은 때때로 특별한 이유없이 꿀처럼 흔들릴 수 있습니다. Windows 8.1 및 10은 눈에 띄게 좋아졌습니다. 그러나 여전히 “스왑”에 대한 조정 가능한 노브 나 스와핑 알고리즘의 기타 조정 가능한 매개 변수는 없습니다.

느린 디스크 액세스로 인해 시스템이 연삭되는 다른 요인이 있습니다. Windows 7에서는 시스템이 오래된 W2k 방식으로 앱을 스왑 아웃했는지 또는 앱이 너무 느리게 시작한다는 사실 또는 Windows Update가 이번에는 주변에 (100 % CPU 소비 및 / 또는 디스크 스 래싱으로 중단되는 알고리즘의 왕복 쿼크가 있음) 또는 특히 일부 .NET Framework 관리 작업이 WinSXS 데이터베이스에서 손실 된 경우 또는 무엇입니까? 경우에 따라 / 일부 Microsoft 소프트웨어 버전 / 화신에서 실제로 백그라운드 작업의 일부 “기본 작업”(특히 Windows Update 로컬 데이터베이스 관리)이 작업 관리자에서 의도적으로 “모호한”것으로 보입니다. CPU 및 RAM 사용량은 총 메모리 소비량에 표시되지 않습니다. “합법적 인”활동이지만 맬웨어 루트킷과 구별하기가 매우 어렵습니다. 스 래싱이 중지되고 “새 업데이트를 사용할 수 있습니다”라는 풍선이 뜨면 바로 그 이유를 알 수 있습니다.

적어도 최신 Windows 버전은 프로세스 당 디스크 IO 활동을 알려줄 수 있으며 이제 개별 서비스가 단일 SVCHOST.EXE 프로세스 대신 개별적으로보고됩니다.

답변