Назад | Перейти на главную страницу

То же оборудование / программное обеспечение, значительная разница в производительности

Введение

У меня есть два комплекта машин, установить A и установить B, очевидно, с той же аппаратной / программной конфигурацией, но со значительной разницей в производительности. Машины в установить B до в 4 раза быстрее чем машины в наборе A. Однако если я перезагружу машину в наборе Aпо необъяснимым причинам он начинает работать так, как ожидалось, как машины из набора B. Я не могу найти объяснения такому поведению.

Конфигурация оборудования

Все компоненты оборудования идентичны по номеру модели / детали.

Настройки и ПО

Эта проблема

Машины в обоих наборах простаивают, но какую бы нагрузку я ни пытался запустить, я получаю очень разные результаты с точки зрения производительности. Для простоты я проведу все тесты на ядре 0. Результат воспроизводится на всех ядрах (обоих процессорах).

Установите A

[root@SET_A ~]# uptime
 11:48:40 up 51 days, 19:34,  2 users,  load average: 0.00, 0.00, 0.00

[root@SET_A ~]#  taskset -c 0 sh -c 'time echo "scale=5000; a(1)*4" | bc -l > /dev/null'

real    0m43.751s
user    0m43.742s
sys     0m0.005s

Установить B

[root@SET_B ~]# uptime
11:50:00 up 15 days, 19:43,  1 user,  load average: 0.00, 0.00, 0.00

[root@SET_B ~]# taskset -c 0 sh -c 'time echo "scale=5000; a(1)*4" | bc -l > /dev/null'

real    0m18.648s
user    0m18.646s
sys     0m0.004s

Наблюдения

турбостаты сообщает ядро ​​0 как находящееся в C0 Consumption состояние и в P0 Performance состояние с включенной турбо-частотой на протяжении всего теста.

Установите A

[root@SET_A ~]# turbostat  -i 5
pk cor CPU    %c0  GHz  TSC SMI    %c1    %c3    %c6    %c7 CTMP PTMP   %pc2   %pc3   %pc6   %pc7  Pkg_W RAM_W PKG_% RAM_%
             3.15 3.18 2.39   0   3.26   0.00  93.59   0.00   40   46  49.77   0.00   0.00   0.00  46.45 22.41  0.00  0.00
 0   0   0  99.99 3.19 2.39   0   0.01   0.00   0.00   0.00   40   46   0.00   0.00   0.00   0.00  29.29 12.75  0.00  0.00

Установить B

[root@SET_B ~]# turbostat  -i 5
pk cor CPU    %c0  GHz  TSC SMI    %c1    %c3    %c6    %c7 CTMP PTMP   %pc2   %pc3   %pc6   %pc7  Pkg_W RAM_W PKG_% RAM_%
             3.14 3.18 2.39   0   3.27   0.00  93.59   0.00   38   40  49.81   0.00   0.00   0.00  46.12 21.49  0.00  0.00
 0   0   0  99.99 3.19 2.39   0   0.01   0.00   0.00   0.00   38   40   0.00   0.00   0.00   0.00  32.27 13.51  0.00  0.00

Упрощенный тест

Чтобы максимально упростить тест (без FP, как можно меньше обращений к памяти), я написал следующий 32-битный код.

.text
.global _start

_start:
      movl    $0x0, %ecx
oloop:
      cmp $0x2, %ecx
      je end
      inc %ecx
      movl    $0xFFFFFFFF,%eax
      movl    $0x0, %ebx
loop: cmp     %eax, %ebx
      je      oloop
      inc     %ebx
      jmp     loop

end:
      mov $1, %eax
      int $0x80
.data
value:
        .long 0

Он просто увеличивает регистр от 0 до 0xFFFFFFFF дважды, больше ничего.

Установите A

[root@SET_A ~]# md5sum simple.out 
30fb3a645a8a0088ff303cf34cadea37  simple.out
[root@SET_A ~]# time taskset -c 0 ./simple.out

real    0m10.801s
user    0m10.804s
sys     0m0.001s

Установить B

[root@SET_B ~]# md5sum simple.out 
30fb3a645a8a0088ff303cf34cadea37  simple.out
[root@SET_B ~]# time taskset -c 0 ./simple.out

real    0m2.722s
user    0m2.724s
sys     0m0.000s

x4 разница для увеличения регистра.

Больше наблюдений с упрощенным тестом

Во время теста количество прерываний одинаково на обеих машинах, ~1100 intr/s (сообщается с помощью mpstat). В основном это прерывания местного таймера на CPU0, поэтому в принципе нет разницы в источнике прерывания.

Установите A

[root@SET_A ~]# mpstat -P ALL -I SUM 1
01:00:35 PM  CPU    intr/s
01:00:36 PM  all   1117.00

Установить B

[root@SET_B ~]# mpstat -P ALL -I SUM 1
01:04:50 PM  CPU    intr/s
01:04:51 PM  all   1112.00

Для P-States и C-States имеет то же самое, что и выше.

анализ перфорации

Установите A

 Performance counter stats for 'taskset -c 0 ./simple.out':

        41,383,515 instructions:k            #    0.00  insns per cycle         [71.42%]
    34,360,528,207 instructions:u            #    1.00  insns per cycle         [71.42%]
            63,675 cache-references                                             [71.42%]
             6,365 cache-misses              #    9.996 % of all cache refs     [71.43%]
    34,439,207,904 cycles                    #    0.000 GHz                     [71.44%]
    34,400,748,829 instructions              #    1.00  insns per cycle         [71.44%]
    17,186,890,732 branches                                                     [71.44%]
               143 page-faults                                                 
                 0 migrations                                                  
             1,117 context-switches                                            

      10.905973410 seconds time elapsed

Установить B

 Performance counter stats for 'taskset -c 0 ./simple.out':

        11,112,919 instructions:k            #    0.00  insns per cycle         [71.41%]
    34,351,189,050 instructions:u            #    3.99  insns per cycle         [71.44%]
            32,765 cache-references                                             [71.46%]
             3,266 cache-misses              #    9.968 % of all cache refs     [71.47%]
     8,600,461,054 cycles                    #    0.000 GHz                     [71.46%]
    34,378,806,261 instructions              #    4.00  insns per cycle         [71.41%]
    17,192,017,836 branches                                                     [71.37%]
               143 faults                                                      
                 2 migrations                                                  
               281 context-switches                                            

       2.740606064 seconds time elapsed

Наблюдения

Заключительные вопросы

Причина здесь либо слишком тривиальна, что я ее пропустил, либо слишком сложна, чтобы ее невозможно объяснить. Я надеюсь, что это первое, любая помощь / подсказка / предложение приветствуются.

Конечно, было бы здорово, если бы кто-нибудь дал ответ, позволяющий сразу решить вашу проблему. Но боюсь, однозначного ответа нет. Но могут быть некоторые направления решения проблемы, которые еще не были предприняты:

  1. Исходя из гипотезы, что некоторые из ваших машин иногда показывают такое поведение, а другие нет, можно сделать вывод о тонких аппаратных проблемах (спорадических, не обнаруживаемых с помощью системной диагностики). Противоположная гипотеза заключается в том, что это может случиться с любой из ваших машин.

    • Шаг 1. Убедитесь, что все части машин можно отследить в будущем.
    • Шаг 2: Выберите некоторые из якобы «хороших» машин и запустите их с жесткими дисками некоторых «плохих» машин и посмотрите, проявится ли эффект.
    • Шаг 3: Контрольный шаг. Запустите "плохие" машины с жесткими дисками "хороших" и посмотрите, проявляется ли проблема.

Если эффект также проявляется на «хороших» машинах, вероятно, есть небольшие различия в установке (HD-контент), или проблема в жестком диске.

Если эффект никогда не проявляется на «хороших» машинах, теория «тонких проблем с оборудованием» в некотором роде подтверждается.

  1. Ищите те различия, которые «действительно и явно не могут быть причиной - никогда!». Есть история об инженере GM, которого послали выяснить, почему автомобиль GM не заводится, когда владелец этой машины покупал клубничное мороженое, но никогда, когда он покупал ваниль в магазине ... В вашем случае посмотрите, где находится ставятся хорошие и плохие машины. Больше вентиляции в комнате, меньше? Ближе к каким-то окнам и прямым солнечным лучам? Ближе / дальше от некоторых электрических установок (климат-контроль, ...)? Различные сети электроснабжения здания? Еще что-нибудь подключено к некоторым путям управления питанием / USV? ... На первый взгляд может показаться неразумным то, что я предлагаю здесь, но эй - ваша проблема довольно спорадическая, не так ли? (50 дней безотказной работы и ваши машины "крутятся" в этот период ..).

Поместите хорошие машины на место плохих и посмотрите, что произойдет.

  1. Некоторые из моих наиболее болезненных рабочих дней в качестве инженера по встроенным программам происходили из-за того, что люди меняли «идентичное оборудование» на моем рабочем столе ... и я тратил полдня - полнедели, пытаясь выяснить, почему мои вещи не работают так, как раньше перед тем, как я ушел на ночь ... Иногда даже самые незначительные изменения какого-либо компонента (или версия программного обеспечения / конфигурации, вшитая в него) могут иметь некоторые наблюдаемые эффекты. В некоторых из моих случаев по этой линии даже производитель не знал об этих «несущественных» изменениях - иногда только в компоновке какой-либо печатной платы или смене поставщика конденсатора на второй источник ...

Шаг 1 должен помочь найти такие тонкие различия, определить, какая из ваших машин работает, а какая нет. Шаг 3 - поиск объяснения.

  1. Попробуйте оценить "MTBF" и проанализировать его на предмет закономерностей. Как вы можете ясно видеть, когда машина начинает замедляться, вы можете измерить среднее время, необходимое машине, чтобы замедлиться. Тогда это может быть полезно, если разные машины имеют разное время до отказа, если время кластеризуется вокруг значения или если нет никакого шаблона (полностью случайного, когда это происходит) ...