스래싱(컴퓨터 과학)

Thrashing (computer science)

컴퓨터 과학에서 스레싱은 컴퓨터의 가상 메모리 리소스가 과도하게 사용될 때 발생하며, 이로 인해 페이징 및 페이지 장애가 지속적으로 발생하여 대부분의 응용 프로그램 수준 [1]처리를 방해합니다.이로 인해 컴퓨터의 성능이 저하되거나 저하됩니다.이 상황은 사용자가 실행 중인 일부 애플리케이션을 닫거나 활성 프로세스가 추가 가상 메모리 리소스를 확보할 때까지 무기한 지속될 수 있습니다.

초기화가 완료된 후 대부분의 프로그램은 프로그램에 필요한 총 메모리에 비해 적은 수의 코드 및 데이터 페이지에서 작동합니다.가장 자주 액세스하는 페이지를 작업 세트라고 합니다.

작업 세트가 시스템 전체 페이지 수에서 차지하는 비율이 작을 경우 가상 메모리 시스템이 가장 효율적으로 작동하고 페이지 장애를 해결하는 데 적은 양의 컴퓨팅이 소비됩니다.작업 세트가 커짐에 따라 페이지 장애 해결은 증가율이 임계점에 이를 때까지 관리 가능한 상태로 유지됩니다.그 후 장애가 극적으로 증가하여 이를 해결하는 데 소요되는 시간이 프로그램 작성에 소요되는 컴퓨팅 시간을 압도합니다.이 상태를 슬래싱이라고 합니다.스레싱은 대규모 데이터 구조에서 작동하는 프로그램에서 발생합니다. 대규모 작업 집합으로 인해 지속적으로 페이지 장애가 발생하여 시스템이 크게 느려지기 때문입니다.페이지 폴트를 만족시키려면 디스크에서 다시 읽어야 하는 페이지를 해제해야 할 수 있습니다.

이 용어는 다양한 유사한 현상, 특히 메모리 계층의 다른 수준 간의 이동에도 사용됩니다. 이 경우 상당한 시간이 자원을 획득하는 데 소비되기 때문에 프로세스가 느리게 진행됩니다.

"스래싱"은 가상 메모리 시스템 이외의 컨텍스트에서도 사용됩니다.예를 들어 컴퓨팅의 캐시 문제나 네트워킹의 바보 같은 창 증후군을 설명하는 데 사용됩니다.

개요

가상 메모리는 컴퓨터 하드 디스크와 같은 보조 저장소일부를 캐시 계층의 추가 계층으로 간주하여 작동합니다.가상 메모리는 프로세스가 기본 메모리에 물리적으로 존재하는 것보다 더 많은 메모리를 사용하도록 허용하고 가상 시스템을 사용하도록 설정하는 데 유용합니다.가상 메모리를 지원하는 운영체제는 프로세스에 가상 주소 공간을 할당하고 각 프로세스는 실행 컨텍스트 내의 주소를 이른바 가상 주소로 참조합니다.그 주소의 코드나 변수등의 데이터액세스 하려면 , 가상 주소 변환이라고 불리는 프로세스로 주소를 물리 주소로 변환할 필요가 있습니다.실제로 물리 메인 메모리는 일반적으로 메모리 페이지의 디스크에 저장되어 있는 가상 메모리의 캐시가 됩니다.

프로그램은 운영 체제에서 필요에 따라 일정 개수의 페이지가 할당됩니다.액티브 메모리 페이지는 RAM과 디스크 양쪽에 존재합니다.비활성 페이지는 메인 메모리가 가득 차면 캐시에서 삭제되고 디스크에 기록됩니다.

프로세스가 메인 메모리를 모두 사용하고 있어 메모리 페이지를 추가할 필요가 있는 경우 페이지 장애라고 불리는 심각한 캐시 누락이 연속적으로 발생하여 운영체제 응답성현저하게 저하되는 경우가 많습니다.이 프로세스는 반복적인 페이지 교환과 함께 "스래싱"이라고 불립니다.이로 인해 CPU 사용률이 높아져 시스템이 정지할 가능성이 있습니다.최신 컴퓨터에서는, 스레싱이 페이징 시스템(물리 메모리가 부족하거나 디스크 액세스 시간이 너무 긴 경우)이나 I/O 통신 서브 시스템(특히 내부 버스 액세스에 관한 경합) 등에서 발생할 수 있습니다.

관련된 구성 및 알고리즘에 따라 시스템의 throughput지연이 몇 나 저하될 수 있습니다.스레싱은 CPU가 '생산적인' 작업을 덜 수행하고 '스왑' 작업을 더 많이 수행하는 상태입니다.상위 레벨의 메모리는 다음 [2]레벨의 메모리 계층에 있는 하위 레벨만큼 고속이기 때문에 전체 메모리 액세스 시간이 증가할 수 있습니다.CPU는 페이지 교환에 너무 바빠서 사용자의 프로그램에 응답하지 못하고 필요한 만큼 인터럽트합니다.스레싱은 메모리 내에 페이지가 너무 많아 각 페이지가 다른 페이지를 참조할 때 발생합니다.실제 메모리는 모든 페이지를 포함할 수 있는 용량이 부족하기 때문에 '가상 메모리'를 사용합니다.실행 중인 각 페이지가 현재 실제 메모리(RAM)에 없는 페이지를 요구하면 가상 메모리에 일부 페이지를 배치하고 RAM에서 필요한 페이지를 조정합니다.CPU가 이 작업을 수행할 때 너무 비지 상태이면 스레싱이 발생합니다.

원인들

가상 메모리 시스템에서 스레싱은 참조 위치가 불충분한 프로그램 또는 워크로드에 의해 발생할 수 있습니다.프로그램 또는 워크로드의 작업 세트를 물리 메모리 내에 효과적으로 유지할 수 없는 경우 지속적인 데이터 스왑(즉, 스레싱)이 발생할 수 있습니다.이 용어는 테이프 운영체제 시절 데이터를 빠르게 쓰고 읽을 때 테이프가 내는 소리를 나타내기 위해 처음 사용되었습니다.IBM System/370 시리즈 메인프레임 컴퓨터에서 이러한 종류의 최악의 시나리오는 페이지 경계를 가로지르는 이동 명령 자체가 페이지 경계를 가로지르는 소스 및 대상을 가리키는 페이지 경계를 가로지르는 실행 명령일 수 있습니다.따라서 이 명령어에 포함되는 페이지 수는 총 8페이지이며, 8페이지가 모두 메모리에 동시에 존재해야 합니다.8 페이지 중 하나를 스왑인할 수 없는 경우(예를 들어 다른 페이지를 위한 공간을 확보하기 위해), 명령이 실패하고 8 페이지를 모두 스왑인할 수 있을 때까지 다시 시작하려는 모든 시도가 실패합니다.

기타 용도

스레싱은 메모리와 스토리지의 맥락에서 가장 잘 알려져 있지만 다음과 같은 다른 리소스에서도 유사한 현상이 발생합니다.

캐시 스레싱

메인 메모리에 액세스 하면, 복수의 메인 메모리 로케이션이 같은 캐시 라인으로 경합해, 과도한 캐시 누락이 발생합니다.이는 연관성이 낮은 캐시에서 가장 문제가 됩니다.

TLB 스레싱

가상 주소를 물리 주소로 변환하는 Memory Management Unit(MMU; 메모리 관리 유닛)의 캐시로서 기능하는 Translation Lookaside Buffer(TLB; 변환 룩사이드버퍼)가, 작업 페이지에 비해 너무 작은 경우.명령 캐시 또는 데이터 캐시 스레싱이 발생하지 않더라도 TLB 스레싱이 발생할 수 있습니다.이는 캐시 크기가 다르기 때문입니다.명령 및 데이터는 전체 페이지가 아닌 작은 블록(캐시 라인)으로 캐시되지만 주소 검색은 페이지 수준에서 수행됩니다.따라서 코드와 데이터 작업세트가 캐시에 들어가더라도 작업세트가 여러 페이지에 걸쳐 fragment화되어 있는 경우 가상 주소 작업세트가 TLB에 맞지 않아 TLB 스레싱이 발생할 수 있습니다.

히프 슬래싱

사용 가능한 메모리가 부족하거나 메모리 조각화로 인해 사용 가능한 메모리가 부족하여 개체에 대한 메모리 할당에 실패하여 자주 발생하는 가비지 수집을 힙 [3]슬래싱이라고 합니다.

프로세스 스레싱

프로세스에서도 같은 현상이 발생합니다.프로세스 작업 세트를 코스케줄링할 수 없기 때문에 모든 상호작용 프로세스가 동시에 실행되도록 스케줄링된 것은 아닙니다.프로세스의 스케줄과 비스케줄링이 반복되어 진행이 [4]느리기 때문에 프로세스 스레싱이 발생합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Denning, Peter J. (1968). "Thrashing: Its causes and prevention" (PDF). Proceedings AFIPS, Fall Joint Computer Conference. 33: 915–922. Retrieved 2012-02-15.
  2. ^ L., Hennessy, John (2012). Computer architecture: a quantitative approach. Patterson, David A., Asanović, Krste. (5th ed.). Waltham, MA: Morgan Kaufmann. ISBN 9780123838728. OCLC 755102367.
  3. ^ IBM POWER8을 포함한 IBM 프로세서를 위한 성능 최적화조정 기술, "Heap+thrashing" 페이지 170
  4. ^ Ousterhout, J. K. (1982). "Scheduling Techniques for Concurrent Systems" (PDF). Proceedings of Third International Conference on Distributed Computing Systems. pp. 22–30.