☰

1マイクロ秒未満の待ち時間の長いコンテンツを測定するためのDPROBES（DTRACE_PROBE）

tag-icon • tag-icon linux performance scheduling sleep ebpf
1マイクロ秒未満の待ち時間の長いコンテンツを測定するためのDPROBES（DTRACE_PROBE）

現在、待ち時間の長いアプリケーションのパフォーマンスを分析していますが、測定結果にまったく自信がありません。これまで私はDPROBES機器を使用してきましたBCC/機能測定用。この数字を確認できる人はいますか？また、より良い方法をご存知の方はお知らせください。

測定値usleep(1)：平均= 53962ナノ秒

#include <unistd.h>
#include <sys/sdt.h>

int main() {
   int i;
   for(i=0; i<1000000; i++){ 
   DTRACE_PROBE("hello-usdt", probe-main-start);
   usleep(1);
   DTRACE_PROBE("hello-usdt", probe-main-end);
   }
}

測定オーバ​​ーヘッド：平均= 788ナノ秒

#include <sys/sdt.h>

int main() {
   int i;
   for(i=0; i<1000000; i++){ 
   DTRACE_PROBE("hello-usdt", probe-main-start);
   DTRACE_PROBE("hello-usdt", probe-main-end);
   }
}

オーバーヘッドですべての測定から788ナノ秒を引くことはできますか？

別の例nanosleep(200)：平均= 52563ナノ秒

#include <sys/sdt.h>
#include <unistd.h>
#include <time.h>
#include <stdio.h>
int main() {
  
    struct timespec tim, tim2;
    tim.tv_sec = 0;
    tim.tv_nsec = 200L;
    int i;
    for (i=0; i<100000; i++){
    DTRACE_PROBE("hello-usdt", probe-main-start);
    if(nanosleep(&tim , &tim2) < 0 ){
            printf("Nano sleep system call failed \n");
            return -1;
    }   
    DTRACE_PROBE("hello-usdt", probe-main-end);
    }
    printf("Nano sleep successfull \n");

    return 0;
}

コードを少し修正しましたfunclatency。

# attach probes

usdt = USDT(path = "path to application")
usdt.enable_probe(probe = "probe-main-start", fn_name = "trace_func_entry")
usdt.enable_probe(probe = "probe-main-end", fn_name = "trace_func_return")
b = BPF(text = bpf_text, usdt_contexts = [usdt])

この方法では、0.8マイクロ秒未満のどれも測定できませんか？また、私が50マイクロ秒ほど「寝眠」を眠っていたとは信じられませんnanosleep(200)。

ベストアンサー1

usleep(1) 測定: 平均 = 53962 ナノ秒

コードの順序は次のとおりです。

   DTRACE_PROBE("hello-usdt", probe-main-start);
   usleep(1);
   DTRACE_PROBE("hello-usdt", probe-main-end);

問題のプロセスは、省電力要求の後にスケジュールされる可能性が高いです。
したがって、次のDTRACE_PROBEは、関連プロセスが再スケジュールされたときにのみ実行されます。したがって、測定は、必要なクロック時間を安定して測定することなく、usleep(1)1μsの省電力時間+システム活動に応じた可変時間を測定します。後者はどんな場合でも1μsよりはるかに優れています。
危険を避けましょう... 50倍以上... 平均約50μs ;-)
非リアルタイム環境では、この指標の標準偏差はかなり高いようです。

測定されたオーバーヘッド：平均= 788ナノ秒。
オーバーヘッドですべての測定から788ナノ秒を引くことはできますか？

あなたのアプローチがDTRACE_PROBEによるオーバーヘッドを測定することを認めます。
それにもかかわらず、すべての測定作業と同様に、標準偏差を最初に検討してください。標準偏差が高いほど平均の意味が下がるからです。
標準偏差に満足すれば、はい。測定値から平均を減算します。
しかし…まあ…< 1 µsについて話しているのでしょうか？

別の例 nanosleep(200) :avg = 52563 ナノ秒

何？繰り返しますが...約50μsのドリフト？どのくらい奇妙ですか？
私の答えの最初の部分nanosleepも適用されます。十分でない場合は参照してください。nanosleep手動:

また、スリープモードが完了した後でも、呼び出しスレッドを実行するためにCPUが再び使用可能になるまで、まだ遅延がある可能性があります。

この方法では、0.8マイクロ秒未満のどれも測定できませんか？また、nanosleep（200）が50usecほど「レイプ」をしたことは信じられません。

上記の内容をすべて読んだ後、最後の質問に対する答えを見つけたことを願っています。この質問は、以前の質問に対する答えも提供します。

いいえ！この方法を使用して800ns未満の何も測定できないわけではありません。
ただし、システムのアクティビティとハードウェアのパフォーマンスにより、次の操作しか実行できません。ブロック通話にかかった時計の時間を測定します。（どんな呼び出しでも、スケジューラはすぐにプロセスをスケジュールするようにトリガします。）精度は約50μsより優れています。

おすすめ記事