학창시절 운영체제(OS) 시간에 쓰레드 퀀텀 (quantum) 혹은 시분할 (time slice)에 관해 배운 적이 있습니다. 최근 우연히 팀 프로그래머 중 한 명이 윈도우즈 서버에서 퀀텀의 크기가 상당히 크다는 것을 다시 상기시켜 주었습니다.
Windows Internals 책에 따르면 윈도우즈 XP의 경우는 6, 윈도우즈 서버의 경우는 36의 퀀텀 값을 갖는다고 합니다. (3 퀀텀이 1 클럭에 해당함)
이러한 퀀텀 값은 또한 윈도우즈의 Performance Option 에서 변경 가능 합니다. (Application = 6 퀀텀 혹은 Background Service = 36 퀀텀 둘 중 선택 가능)
원도우즈 서버가 180 ms라는 상당히 큰 퀀텀 값을 가지는 이유는 서비스 어플리케이션 쓰레드에게 작업을 수행할 충분한 시간을 주기 위함입니다. 또 잦은 context switch는 전체 성능을 저하시킬 수 있기 때문입니다. 하지만 XP와 같은 Client OS의 경우 사용자에게 빠른 응답을 하는 것이 중요하므로 (예를 들면 UI 쓰레드) 작은 퀀텀 값을 갖는 것입니다.
Windows Internals 책에 따르면 윈도우즈 XP의 경우는 6, 윈도우즈 서버의 경우는 36의 퀀텀 값을 갖는다고 합니다. (3 퀀텀이 1 클럭에 해당함)
보통 인텔의 멀티프로세서 시스템은 1 클럭 간격이 15ms 이므로, XP는 30ms, 서버는 180ms의 시간이 (한 번의 쓰레드 스케줄링으로) 하나의 쓰레드에 할당되는 것 입니다.
물론 쓰레드가 대기(wait)상태로 들어간다면, 이 퀀텀을 다 사용하지 못하고 context switch가 일어 날 수 있습니다.이러한 퀀텀 값은 또한 윈도우즈의 Performance Option 에서 변경 가능 합니다. (Application = 6 퀀텀 혹은 Background Service = 36 퀀텀 둘 중 선택 가능)
원도우즈 서버가 180 ms라는 상당히 큰 퀀텀 값을 가지는 이유는 서비스 어플리케이션 쓰레드에게 작업을 수행할 충분한 시간을 주기 위함입니다. 또 잦은 context switch는 전체 성능을 저하시킬 수 있기 때문입니다. 하지만 XP와 같은 Client OS의 경우 사용자에게 빠른 응답을 하는 것이 중요하므로 (예를 들면 UI 쓰레드) 작은 퀀텀 값을 갖는 것입니다.
Trackback Address :: http://devnote.net/trackback/94
