절전 명령 지연이 심각하게 부정확함(VM)

절전 명령 지연이 심각하게 부정확함(VM)

쉘 스크립트에서 사용해야 해서 sleep터미널에서 사용해 보았으나 지연이 발생하여 일관성이 없었고 매우 부정확했습니다. 예를 들어 sleep 320초에 가까운 지연이 발생합니다. 이러한 지연은 동일한 시간이 지정되면 변동될 수도 있습니다. 일반적으로 Latency는 값이 증가할수록 기하급수적으로 증가하는 것으로 보입니다.

Ubuntu 및 Debian VM에서 시도했지만 결과는 동일하지 않았습니다. VM 구성 요소가 제 역할을 하고 있다고 생각하지 않습니다( timeout 10Windows VM에서 실행해도 괜찮습니다).

각 명령의 타이밍을 맞춰 시스템 시계는 제대로 실행되고 있다고 생각하지만 그렇지 않습니다. 아래의 몇 가지 예를 참조하세요.


괄호 안의 시간은 실제 경과 시간(근사치)입니다.

$ time sleep 1        (7 secs)

real    0m1.040s
user    0m0.003s
sys     0m0.016s
$ time sleep 1        (5 secs)

real    0m1.028s      
user    0m0.009s
sys     0m0.013s
$ time sleep 1        (5 secs)

real    0m1.027s
user    0m0.013s
sys     0m0.007s
$ time sleep 1        (5 secs)

real    0m1.029s
user    0m0.007s
sys     0m0.016s
$ time sleep 3       (17 secs)

real    0m3.036s
user    0m0.000s
sys     0m0.021s
$ time sleep 5       (29.5 secs)

real    0m5.026s
user    0m0.007s
sys     0m0.013s

기본값은 분명히 초 단위이지만 s시간을 추가해도 아무런 차이가 없습니다.

디스크나 CPU를 소비할 수 있는 다른 어떤 것도 호스트에서 실행되고 있지 않습니다.

VM을 다시 시작하면 처음 몇 번의 시도는 향상되는 것처럼 보이지만 그 이후에는 정확도가 점점 더 나빠집니다.

문제가 무엇인지 아시나요?

편집하다:

  • 런닝 declare -p PS1리턴

    declare -- PS1="\${debian_chroot:+(\$debian_chroot)}\\u@\\h:\\w\\\$ "
    
  • 런닝 command -V sleep리턴

    sleep is hashed (/usr/bin/sleep)
    
  • 런닝 declare -p PATH리턴

    declare -x PATH="/home/debwp/mycmds:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
    
  • Paul_Pedant의 게시물에 대한 결과:

    ~$ date '+%T.%N'; time sleep 5; date '+%T.%N'
    22:47:49.679497552
    ^[[A
    ^[[A
    ^[[A
    ^[[A
    
    real  0m5.033s
    user  0m0.005s
    sys   0m0.014s
    22:47:54.788302324
    ~$ date '+%T.%N'; time sleep 5; date '+%T.%N'
    22:47:54.830674809
    
    real  0m5.043s
    user  0m0.008s
    sys   0m0.012s
    22:47:59.934542825
    ~$ date '+%T.%N'; time sleep 5; date '+%T.%N'
    22:47:59.994006022
    
    real  0m5.057s
    user  0m0.004s
    sys   0m0.018s
    22:48:05.159303996
    ~$ date '+%T.%N'; time sleep 5; date '+%T.%N'
    22:48:05.241043114
    
    real  0m5.099s
    user  0m0.004s
    sys   0m0.021s
    22:48:10.383158635
    ~$ date '+%T.%N'; time sleep 5; date '+%T.%N'
    22:48:10.435520982
    
    real  0m5.028s
    user  0m0.004s
    sys   0m0.012s
    22:48:15.497877219
    ~$
    
  • date초당 한 번씩 터미널에 입력하면 다음과 같은 결과가 발생합니다.

    $ date
    Mon 31 Aug 20:42:25 CEST 2020
    $ date
    Mon 31 Aug 20:42:25 CEST 2020
    $ date
    Mon 31 Aug 20:42:25 CEST 2020
    $ date
    Mon 31 Aug 20:42:26 CEST 2020
    

답변1

이 동작은 확실히 하이퍼바이저와 관련이 있습니다.

time(7)설명하다:

실시간은 과거의 표준 지점(아래 신기원 및 달력 시간 설명 참조) 또는 프로세스 수명의 특정 지점(예: 시작)(경과 시간) 등 일부 고정된 지점에서 측정된 시간으로 정의됩니다. ).

프로세스 시간은 프로세스에서 사용하는 CPU 시간의 양으로 정의됩니다. 때로는 사용자 구성 요소와 시스템 구성 요소로 구분됩니다. 사용자 CPU 시간은 사용자 모드에서 코드를 실행하는 데 소요된 시간입니다. 시스템 CPU 시간은 프로세스를 대신하여 시스템 모드에서 커널을 실행하는 데 소요되는 시간입니다(예: 시스템 호출 실행). time(1) 명령을 사용하면 프로그램 실행 중에 소비되는 CPU 시간을 확인할 수 있습니다.

이를 바탕으로 다음과 같은 결론을 내릴 수 있습니다.

$ time sleep 1

real    0m1.002s
user    0m0.002s
sys     0m0.000s

real실시간은 프로세스에 소요된 실제 시간을 의미합니다(벽시계 시간이라고도 함). user는 사용자 모드에서 코드를 실행하는 데 소요된 CPU 시간(CPU 주기 * 빈도)이고, 는 sys커널 프로세스를 대신하여 시스템 모드에서 실행에 소요된 CPU 시간(CPU 주기 * 빈도)입니다.

문제를 설명하세요.

왜 보고시간이 없나요 real?time(1)내 시계와 맞을까요?

베어 메탈에서 운영 체제를 실행하는 경우 일반적으로 배터리로 구동되는 수정 발진기가 일정한 주파수로 실행됩니다. 이 하드웨어 시계는 에포크 이후의 시간을 추적합니다. 드리프트를 수정하기 위해 초당 진동 수를 조정할 수 있습니다(참조:hwclock(8)).

time(7)또한 다음과 같이 말했습니다.

시간 초과를 설정하고(예: select(2), sigtimedwait(2)) CPU 시간을 측정하는(예: getrusage(2)) 다양한 시스템 호출의 정확도는 소프트웨어 시계의 해상도에 의해 제한됩니다. 커널이며 jiffy 측정 시간으로 측정됩니다. jiffy의 크기는 커널 상수 HZ의 값에 의해 결정됩니다.

하드웨어 시계는 시스템 시계를 초기화하는 데 사용됩니다(그렇지 않으면 부팅 이후의 시간만 알려짐). 귀하의 하이퍼바이저(virtualbox)가 hwclock을 사용하여 시간을 초기화하는 것 같습니다. 그 후에는 소프트웨어 시계가 대신합니다.

rtc(4)설명하다:

[하드웨어 시계] 커널에 의해 유지 관리되고 gettimeofday(2) 및 time(2)을 구현하고 파일에 타임스탬프를 설정하는 데 사용되는 소프트웨어 시계인 시스템 시계와 혼동하지 마십시오.

방금 여기서 배운 것은 time(2)(이것은 유틸리티에서 사용하는 라이브러리 호출입니다.time(1)) 실제로는 하드웨어 시계가 아닌 시스템 시계에서 정보를 가져옵니다.

소프트웨어 시계는 커널에 의해 유지되며 시간을 측정합니다 jiffies. 커널 상수에 의해 결정되는 시간 단위입니다. 내가 이해한 바에 따르면 특정 수의 CPU 사이클이 지피를 추가합니다. 따라서 OS에서는 CPU가 2.0GHz에서 실행되고 있다고 생각하지만 CPU가 실제로 1.0GHz에서 실행되고 있는 경우 벽시계와 비교하면 지피는 실제로 예상되는 1ms가 아닌 2ms가 소요됩니다.

물리적 하드웨어로 실행할 때 우리는 실행 속도를 CPU에 지시한 다음(전력 절약을 위해 속도를 낮추고 성능을 위해 속도를 높임) 물리적 하드웨어가 이 지점에 도달했기 때문에 하드웨어가 약속한 대로 수행한다고 가정합니다. 비결은 "하드웨어"가 가상일 때 하이퍼바이저가 물리 법칙이 아니라 가상 CPU를 제어하는 ​​방법을 결정한다는 것입니다.

사용자 공간(예: 가상 머신)에서 실행되는 하이퍼바이저는 호스트 커널의 도움을 받아 필요한 주기를 제공합니다. 호스트 시스템이 1000개의 가상 머신을 실행하는 경우 각 게스트 VM은 예상 CPU 주기의 일부만 가져오므로 추측된 시스템 클럭이 더 느린 속도로 증가한다고 상상할 수 있습니다. 하이퍼바이저가 필요한 모든 리소스를 확보하더라도 적절하다고 판단되는 대로 리소스를 제한하도록 선택할 수 있으며 이로 인해 게스트 운영 체제가 이유를 이해하지 못한 채 예상보다 느리게 실행될 수 있습니다.

답변2

확립된이 답변존재하다VirtualBox 게스트의 시계 드리프트:

Virtualbox Manager에서 반가상화 값(시스템 설정 -> 가속 탭)을 에서 으로 변경하여 문제를 Default해결했습니다 .Minimal

관련 정보