Проблемы с алгоритмом процентного соотношения времени процессора - PullRequest
Новая
       24

Проблемы с алгоритмом процентного соотношения времени процессора

2 голосов
/ 21 октября 2011

У меня проблемы с алгоритмом Java, который я создал, чтобы преобразовать использование процессора в наносекундах (полученное с помощью JMX) в процент от 100%.Кажется, что алгоритм дает числа больше 100%, что, как я полагаю, связано с несколькими доступными процессорами, хотя код должен разобраться с этим.Алгоритм можно увидеть ниже.cpuTimeDiffNS - это количество процессорного времени, используемого в наносекундах, а periodMS - период выборки. 

public static final double getCPUPerc(long cpuTimeDiffNS, long periodMS) {
    if (periodMS == 0) return 0;
    double cpuTimeDiffMS = cpuTimeDiffNS / 1000000d;
    int procs = Runtime.getRuntime().availableProcessors();
    long availableTime = periodMS * procs;
    double perc = cpuTimeDiffMS / availableTime;
    return perc * 100d;
}

Вот некоторые примеры из сбора данных: 

0
87.5
133.8288232
160.8231707
197.7896341
209.6036585
248.822774
274.3902439
267.9115854
271.3414634
277.1067759
283.1554878
272.1036585
279.4000734
283.9176829
283.5365854
275.9146341
282.4578033
278.9634146
261.0536937
254.6071775
286.662182
278.9634146
276.7245597
288.4908537
281.6933708
286.9664634
279.7822896
276.2957317
280.4878049
275.5335366
271.7557485
280.8689024
287.2689689
281.6933708
267.5097276
273.2469512
286.1735835
289.6341463
296.875
279.4000734
289.2530488
282.8400196
288.4908537
287.4266145
288.1097561
286.5853659
288.9554795
238.1207192
288.4908537
288.7063531
290.3963415
286.662182
277.4390244
290.4843444
281.6310976
271.7557485
272.8658537
283.2222358
250.7621951

Редактировать: по запросу, функции сбора ввода (вы, вероятно, можете игнорировать это): 

// returns CPU time in NS for a thread group (recursively)
public static long getCPUTime(ThreadGroup tg) {
    synchronized (TGLOCK) {
        int size;
        do {
            size = tg.enumerate(tgThreads, true);
            if (size <= tgThreads.length) continue;
            tgThreads = new Thread[size];
        } while (size > tgThreads.length);

        long totalTime = 0;
        for (int i = 0; i < size; i++) {
            totalTime += getCPUTime(tgThreads[i]);
        }
        return totalTime;
    }
}

public static long getCPUTime(Thread t) {
    return threadMXBean.getThreadCpuTime(t.getId());
}

public static ThreadGroup getRootThreadGroup() {
    // Find the root thread group
    ThreadGroup root = Thread.currentThread().getThreadGroup().getParent();
    while (root.getParent() != null) {
        root = root.getParent();
    }
    return root;
}

и входы (опять же, вы, вероятно, можете игнорировать это): 

    simCPUTimeNS     = getCPUTime(kks.getSimThreadGroup());
    appsCPUTimeNS    = getCPUTime(kks.getAppThreadGroup());
    lwjns3CPUTimeNS  = getCPUTime(kks.getKKSThreadGroup());
    simCoreCPUTimeNS = getCPUTime(kks.getSimThread());
    totalCPUTimeNS   = getCPUTime(getRootThreadGroup());

    simCPUTimeNSDiff  = simCPUTimeNS - lastSimCPUTimeNS;
    appsCPUTimeNSDiff = appsCPUTimeNS - lastAppsCPUTimeNS;
    lwjns3CPUTimeNSDiff = lwjns3CPUTimeNS - lastLwjns3CPUTimeNS;
    simCoreCPUTimeNSDiff = simCoreCPUTimeNS - lastSimCoreCPUTimeNS;
    totalCPUTimeNSDiff = totalCPUTimeNS - lastTotalCPUTimeNS;

    lastSimCPUTimeNS     = simCPUTimeNS;
    lastAppsCPUTimeNS    = appsCPUTimeNS;
    lastLwjns3CPUTimeNS  = lwjns3CPUTimeNS;
    lastSimCoreCPUTimeNS = simCoreCPUTimeNS;
    lastTotalCPUTimeNS   = totalCPUTimeNS;

    simCPUPerc     = getCPUPerc(simCPUTimeNSDiff, currDiffMS);
    appsCPUPerc    = getCPUPerc(appsCPUTimeNSDiff, currDiffMS);
    lwjns3CPUPerc  = getCPUPerc(lwjns3CPUTimeNSDiff, currDiffMS);
    simCoreCPUPerc = getCPUPerc(simCoreCPUTimeNSDiff, currDiffMS);
    totalCPUPerc   = getCPUPerc(totalCPUTimeNSDiff, currDiffMS);

Приветствияза любую помощь, я уверен, что ответ очевиден;)Chris

Ответы [ 2 ]

1 голос
/ 22 октября 2011

Таким образом, мы используем аналогичный код для вычисления средней нагрузки и (как выясняется) он имеет ошибку, которая также может быть в вашем коде. Мы используем getAllThreadIds(), но он возвращает только «активные» потоки, и enumerate также делает это. Если какой-либо из ваших потоков останавливается, то общее время процессора может уменьшиться. Я не понимаю, как это приведет к тому, что значения превысят 100%.

Пара комментариев о вашем коде:

  • Почему линия synchronized (TGLOCK)? Это для синхронизации объекта ThreadGroup?
  • if (size <= tgThreads.length) continue; должен быть break;. Нет необходимости в двойном тестировании.
  • enumerate возвращает количество потоков, помещенных в массив. Это всегда будет <= tg.length, поэтому массив никогда не будет расти, если я правильно его подготовлю. Если он вернет больший размер, вы получите NPE, поскольку у вас есть tgThreads = new Thread[size]; прямо перед проверкой во время, что никогда не будет правдой.
  • Есть ли причина, по которой вы вообще используете ThreadGroup? Мы используем следующее, которое не нужно повторять или что-то еще: 
    for (long id : threadMxBean.getAllThreadIds()) {
    long cpuTime = threadMxBean.getThreadCpuTime(id);

Надеюсь, это поможет хоть немного.

0 голосов
/ 24 октября 2011

Я работаю на расширенной по времени JVM (5-кратное замедление), и похоже, что я забыл расширить одну часть кода C ++ JVM в os_windows.cpp (os::thread_cpu_time) при выполнении настроек.К сожалению.Он использует timeGetTime(), функцию времени Windows.Это объяснило бы это.

...