ESXi 6.0 U1 + Solaris 11.0 VM = центральний процесор високий (повільно піднімається), але VM неактивний

1

У мене є ESXi 6.0 Update 1 (Build 3029758), встановлений на новому апаратному забезпеченні (Atom C2750, 16GB RAM).

VM - Solaris 11.0 з 1 vCPU і 4 Гб оперативної пам'яті. Solaris було встановлено з sol-11-1111-text-x86.iso без додаткової конфігурації, за винятком встановлення VMware Tools.

Після запуску віртуальної машини процесор хоста демонструє простою (12 МГц), але він повільно піднімається приблизно на 10% на день (240 МГц на день), поки не досягне близько 95%, тоді як сама ВМ стає невідповідною, однак ESXi все ще каже, що VM працює штраф.

На кожному етапі сама ВМ завжди повідомляє, що вона неактивна. Перезавантаження віртуальної машини повертає процесор хоста назад в режим очікування (12 МГц), і повільний підйом починається знову.

Час роботи VM: 

# uptime
  00:06am  up 4 days  0:12,  1 user,  load average: 0.00, 0.00, 0.00

Вихід з esxtop: 

 1:10:11pm up 4 days 47 min, 504 worlds, 2 VMs, 2 vCPUs; CPU load average: 0.06, 0.06, 0.06
PCPU USED(%): 5.3 0.5 0.1 0.1 0.1  45 0.1 0.2 AVG: 6.5
PCPU UTIL(%): 5.0 0.5 0.2 0.5 0.0  42 0.1 0.4 AVG: 6.2

      ID      GID NAME             NWLD   %USED    %RUN    %SYS   %WAIT %VMWAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT
   36739    27266 vmx                 1    0.03    0.02    0.01   99.98       -    0.00    0.00    0.00    0.00    0.00    0.00
   36741    27266 vmast.36740         1    0.14    0.13    0.00   99.87       -    0.01    0.00    0.00    0.00    0.00    0.00
   36742    27266 vmx-vthread-5       1    0.00    0.00    0.00  100.00       -    0.00    0.00    0.00    0.00    0.00    0.00
   36743    27266 vmx-vthread-6:n     1    0.00    0.00    0.00  100.00       -    0.00    0.00    0.00    0.00    0.00    0.00
   36744    27266 vmx-vthread-7:n     1    0.00    0.00    0.00  100.00       -    0.00    0.00    0.00    0.00    0.00    0.00
   36745    27266 vmx-vthread-8:n     1    0.00    0.00    0.00  100.00       -    0.00    0.00    0.00    0.00    0.00    0.00
   36746    27266 vmx-mks:nas         1    0.01    0.01    0.00   99.99       -    0.00    0.00    0.00    0.00    0.00    0.00
   36747    27266 vmx-svga:nas        1    0.00    0.00    0.00  100.00       -    0.00    0.00    0.00    0.00    0.00    0.00
   36748    27266 vmx-vcpu-0:nas      1   45.15   42.35    0.00   57.66    0.02    0.00   57.63    0.03    0.00    0.00    0.00

У випадку, якщо хтось дивується, я використовую Solaris 11.0, тому що намір для цього VM полягає у використанні ZFS з фізичними RDMs для створення NAS. На жаль, Solaris 11.1 (і вище) + фізичний RDM = ESXi purple screen (див Повідомлення про помилку: Solaris 11.1 + RDM = ESXi 5.1 фіолетовий екран ). Ця проблема повинна була бути виправлена ​​в ESXi 5.5, але вона все ще існує в ESXi 6.0U1. Я тестував (ESXi 6.0U1 + Solaris 11.1 + фізичний RDM) і (ESXi 6.0U1 + Solaris 11.3 + фізичний RDM). Обидві комбінації призводять до фіолетового екрану.

Цікаво, що Solaris 11.1 (і вище) без фізичних RDM не страждає від повільного підйому використання процесора хоста, описаного вище. Отже, я теж маю справу з дивним підйомом CPU хоста або фіолетовими екранами :-(

Додаткова інформація, яку запитує Ендрю Генле (2016-01-11)

Вихід із esxtop зараз: 

11:12:46am up 5 days 22:49, 518 worlds, 3 VMs, 3 vCPUs; CPU load average: 0.09, 0.08, 0.08
PCPU USED(%): 1.3 5.9 0.6 0.6 0.4  63 0.3 0.2 AVG: 9.1
PCPU UTIL(%): 1.3 5.6 0.5 0.8 0.7  59 0.4 0.1 AVG: 8.6

      ID      GID NAME             NWLD   %USED    %RUN    %SYS   %WAIT %VMWAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT
   36739    27266 vmx                 1    0.03    0.02    0.01  100.00       -    0.00    0.00    0.00    0.00    0.00    0.00
   36741    27266 vmast.36740         1    0.14    0.13    0.00  100.00       -    0.01    0.00    0.00    0.00    0.00    0.00
   36742    27266 vmx-vthread-5       1    0.00    0.00    0.00  100.00       -    0.00    0.00    0.00    0.00    0.00    0.00
   36743    27266 vmx-vthread-6:n     1    0.00    0.00    0.00  100.00       -    0.00    0.00    0.00    0.00    0.00    0.00
   36744    27266 vmx-vthread-7:n     1    0.00    0.00    0.00  100.00       -    0.00    0.00    0.00    0.00    0.00    0.00
   36745    27266 vmx-vthread-8:n     1    0.00    0.00    0.00  100.00       -    0.00    0.00    0.00    0.00    0.00    0.00
   36746    27266 vmx-mks:nas         1    0.00    0.00    0.00  100.00       -    0.00    0.00    0.00    0.00    0.00    0.00
   36747    27266 vmx-svga:nas        1    0.00    0.00    0.00  100.00       -    0.00    0.00    0.00    0.00    0.00    0.00
   36748    27266 vmx-vcpu-0:nas      1   64.28   59.40    0.00   40.69    0.05    0.04   40.64    0.03    0.00    0.00    0.00

Час роботи VM зараз: 

# uptime
 22:14pm  up 5 days 22:21,  1 user,  load average: 0.00, 0.00, 0.00

Вихід у VM prstat: 

# prstat -a -n 20
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
   702 root       19M 9904K sleep   59    0   0:15:33 0.3% vmtoolsd/2
  3272 root       11M 3508K cpu0    59    0   0:00:00 0.1% prstat/1
     5 root        0K    0K sleep   99  -20   0:00:05 0.1% zpool-rpool/136
  3237 root       18M 5172K sleep   59    0   0:00:00 0.1% sshd/1
   427 root     7668K 5768K sleep   59    0   0:00:17 0.0% hald/4
   369 root       12M 3552K sleep   59    0   0:00:14 0.0% nscd/35
   602 root       35M   16M sleep   59    0   0:00:26 0.0% fmd/28
  3238 root       11M 3344K sleep   59    0   0:00:00 0.0% bash/1
   292 root     3220K 1376K sleep   59    0   0:00:00 0.0% vbiosd/3
   247 root     2648K 1316K sleep   60  -20   0:00:00 0.0% zonestatd/5
   267 root       11M 1272K sleep   59    0   0:00:00 0.0% net-physical/1
    81 daemon     14M 4612K sleep   59    0   0:00:00 0.0% kcfd/3
   975 root     3680K 2240K sleep   59    0   0:00:00 0.0% nmz/1
   108 root       13M 2552K sleep   59    0   0:00:00 0.0% syseventd/18
    48 root     3880K 2256K sleep   59    0   0:00:04 0.0% dlmgmtd/7
   162 netadm   4100K 2476K sleep   59    0   0:00:00 0.0% ipmgmtd/5
    39 netcfg   3784K 2424K sleep   59    0   0:00:04 0.0% netcfgd/4
   335 root       11M 2848K sleep   59    0   0:00:00 0.0% picld/4
    13 root       19M   18M sleep   59    0   0:00:29 0.0% svc.configd/22
    11 root       20M   11M sleep   59    0   0:00:07 0.0% svc.startd/12
 NPROC USERNAME  SWAP   RSS MEMORY      TIME  CPU
    53 root      444M  173M   4.2%   0:18:11 0.6%
     1 smmsp    6288K 1584K   0.0%   0:00:00 0.0%
     2 daemon     17M 5664K   0.1%   0:00:00 0.0%
     1 netadm   4100K 2476K   0.1%   0:00:00 0.0%
     1 netcfg   3784K 2424K   0.1%   0:00:04 0.0%
Total: 60 processes, 637 lwps, load averages: 0.01, 0.00, 0.00

Використання пам'яті VM: 

# echo ::memstat | mdb -k
Page Summary                Pages                MB  %Tot
------------     ----------------  ----------------  ----
Kernel                     101923               398   10%
ZFS File Data               60118               234    6%
Anon                        30785               120    3%
Exec and libs                2168                 8    0%
Page cache                   5295                20    1%
Free (cachelist)             8599                33    1%
Free (freelist)            837526              3271   80%

Total                     1046414              4087
Physical                  1046413              4087

Додаткова інформація, яку запитує Ендрю Генле (2016-01-13)

vmtoolsd це демон VMware Tools для Solaris. Цей процес не є причиною. Під час розслідування я зупинив цей процес на ВМ і знайшов, що це не має значення.

Так, всі дані взяті одночасно. І, так, він показує дуже низьке використання процесора VM, але дуже високе використання центрального процесора.

Ваша пропозиція щодо використання mpstat це (я думаю) йде вниз по правильному шляху. Було виявлено масово велику кількість переривань на ВМ. 

# mpstat 2
CPU minf mjf xcal  intr  ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
  0    0   0    0  60208  107  147    1    0    1    0   100    0  14   0  86
  0    0   0    0 130658  103  181    4    0    1    0   413    1  28   0  72
  0    0   0    0 130157  103  134    1    0    0    0    39    0  26   0  74
  0    0   0    0 129690  104  134    1    0    1    0    46    0  27   0  73
  0    0   0    0 129722  102  142    1    0    1    0    42    0  27   0  73

Потім я використовував intrstat на віртуальній машині, щоб побачити, які переривання піднімаються, але це не виявило нічого корисного. 

# intrstat

      device |      cpu0 %tim
-------------+---------------
       ata#1 |         0  0.0
    e1000g#0 |         0  0.0

      device |      cpu0 %tim
-------------+---------------
       ata#1 |         0  0.0
    e1000g#0 |         9  0.0

      device |      cpu0 %tim
-------------+---------------
       ata#1 |         0  0.0
    e1000g#0 |         2  0.0

Потім я використав старий скрипт dtrace, який я мав багато років, щоб виглядати трохи ближче до переривань у VM. Видається, що переривання генеруються cbe_fire але я не знаю, що таке і не знайшов корисної інформації про нього. 

# ./intrstat.d
dtrace: script './intrstat.d' matched 4 probes
dtrace: 24610 dynamic variable drops with non-empty dirty list
CPU     ID                    FUNCTION:NAME
  0  62167                       :tick-1sec
driver     instance         intr-count
---------------------------------------
ata        0x1                     0
mpt        0x0                     0
mpt        0x2                     0
e1000g     0x0                     3
<unknown>  unix`cbe_fire       71405

dtrace: 24005 dynamic variable drops with non-empty dirty list
  0  62167                       :tick-1sec
driver     instance         intr-count
---------------------------------------
ata        0x1                     0
mpt        0x0                     0
mpt        0x2                     0
e1000g     0x0                     3
<unknown>  unix`cbe_fire       70285

dtrace: 23759 dynamic variable drops with non-empty dirty list
  0  62167                       :tick-1sec
driver     instance         intr-count
---------------------------------------
mpt        0x0                     0
mpt        0x2                     0
ata        0x1                     1
e1000g     0x0                     3
<unknown>  unix`cbe_fire       71097

Повна таблиця переривань нижче. 

# echo '::interrupts -d' | mdb -k
IRQ  Vect IPL Bus    Trg Type   CPU Share APIC/INT# Driver Name(s)
1    0x41 5   ISA    Edg Fixed  0   1     0x0/0x1   i8042#0
9    0x80 9   PCI    Lvl Fixed  0   1     0x0/0x9   acpi_wrapper_isr
12   0x42 5   ISA    Edg Fixed  0   1     0x0/0xc   i8042#0
15   0x44 5   ISA    Edg Fixed  0   1     0x0/0xf   ata#1
16   0x43 5   PCI    Lvl Fixed  0   1     0x0/0x10  mpt#1
17   0x40 5   PCI    Lvl Fixed  0   2     0x0/0x11  mpt#2, mpt#0
18   0x60 6   PCI    Lvl Fixed  0   1     0x0/0x12  e1000g#0
24   0x81 7   PCI    Edg MSI    0   1     -         pcieb#0
25   0x30 4   PCI    Edg MSI    0   1     -         pcieb#1
26   0x82 7   PCI    Edg MSI    0   1     -         pcieb#2
27   0x31 4   PCI    Edg MSI    0   1     -         pcieb#3
28   0x83 7   PCI    Edg MSI    0   1     -         pcieb#4
29   0x32 4   PCI    Edg MSI    0   1     -         pcieb#5
30   0x84 7   PCI    Edg MSI    0   1     -         pcieb#6
31   0x33 4   PCI    Edg MSI    0   1     -         pcieb#7
32   0x85 7   PCI    Edg MSI    0   1     -         pcieb#8
33   0x34 4   PCI    Edg MSI    0   1     -         pcieb#9
34   0x86 7   PCI    Edg MSI    0   1     -         pcieb#10
35   0x35 4   PCI    Edg MSI    0   1     -         pcieb#11
36   0x87 7   PCI    Edg MSI    0   1     -         pcieb#12
37   0x36 4   PCI    Edg MSI    0   1     -         pcieb#13
38   0x88 7   PCI    Edg MSI    0   1     -         pcieb#14
39   0x37 4   PCI    Edg MSI    0   1     -         pcieb#15
40   0x89 7   PCI    Edg MSI    0   1     -         pcieb#16
41   0x38 4   PCI    Edg MSI    0   1     -         pcieb#17
42   0x8a 7   PCI    Edg MSI    0   1     -         pcieb#18
43   0x39 4   PCI    Edg MSI    0   1     -         pcieb#19
44   0x8b 7   PCI    Edg MSI    0   1     -         pcieb#20
45   0x3a 4   PCI    Edg MSI    0   1     -         pcieb#21
46   0x8c 7   PCI    Edg MSI    0   1     -         pcieb#22
47   0x3b 4   PCI    Edg MSI    0   1     -         pcieb#23
48   0x8d 7   PCI    Edg MSI    0   1     -         pcieb#24
49   0x3c 4   PCI    Edg MSI    0   1     -         pcieb#25
50   0x8e 7   PCI    Edg MSI    0   1     -         pcieb#26
51   0x3d 4   PCI    Edg MSI    0   1     -         pcieb#27
52   0x8f 7   PCI    Edg MSI    0   1     -         pcieb#28
53   0x3e 4   PCI    Edg MSI    0   1     -         pcieb#29
208  0xd0 14         Edg IPI    all 1     -         kcpc_hw_overflow_intr
209  0xd1 14         Edg IPI    all 1     -         cbe_fire
240  0xe0 15         Edg IPI    all 1     -         apic_error_intr

Знову ж таки, я застряг :(

Додаткова інформація, яку запитує Ендрю Генле (2016-01-15)

Кінець виводу з вашого сценарію dtrace: 

          unix`do_splx+0x97
          genunix`disp_lock_exit+0x55
          genunix`post_syscall+0x61a
          unix`0xfffffffffb800cb7
           18

          unix`todpc_rtcget+0xe5
          unix`todpc_get+0x1a
          unix`tod_get+0x1a
          genunix`clock+0xa53
          genunix`cyclic_softint+0xd6
          unix`cbe_softclock+0x1a
          unix`av_dispatch_softvect+0x62
          unix`dispatch_softint+0x33
          unix`switch_sp_and_call+0x13
           38

          unix`sys_syscall+0xff
           39

          genunix`fsflush_do_pages+0x142
          genunix`fsflush+0x3d4
          unix`thread_start+0x8
           58

          unix`dispatch_softint+0x27
          unix`switch_sp_and_call+0x13
        26573

          unix`mach_cpu_idle+0x6
          unix`cpu_idle+0x150
          unix`idle+0x58
          unix`thread_start+0x8
       135471

Останнім стеком стека є цикл бездіяльності. Другий останній слід стека з рахунком 26573, здається, винуватцем, але не так багато інформації, щоб продовжити там.

cpu-usage  solaris  esxi 
— protogen
джерело
Розмістіть вивід з prstat -a на ВМ. Це покаже процес, який займає весь ваш процесорний час. Також запустіть echo ::memstat | mdb -k на віртуальній машині як root і розмістити цей вивід. Це покаже використання пам'яті.
— Andrew Henle
@Andrew - запитувана інформація додана до початкового повідомлення вище. Оцініть ваш внесок і допомогу.
— protogen
Що vmtoolsd? Чи продовжує накопичуватися час процесора і, можливо, більш високий і вищий відсоток процесора протягом часу? І чи всі ці дані взяті одночасно так, що всередині ВМ ви бачите дуже низький відсоток використання процесора, але за межами ВМ ви бачите завантаження ЦП на 64%? Якщо так, то відправте вивід з mpstat 2 2, запустіть всередині віртуальної машини. Це викличе mpstat виводити дані двічі з двосекундною затримкою. Першим набором вихідних даних будуть середні значення після завантаження. Другий набір вихідних даних буде здійснюватися протягом двох секунд між виведенням наборів.
— Andrew Henle
@Andrew - запитувана інформація знову додана до початкового повідомлення вище (це стає досить довго!). Знову дякую.
— protogen
Це виглядає реально подібно: illumos.org/issues/1333
— Andrew Henle

Відповіді:

0

(опублікувати це як відповідь, щоб код міг бути відформатований)

Ви можете запустити цей скрипт dtrace як кореневий, щоб визначити, де ядро ​​витрачає час: 

#!/usr/sbin/dtrace -s
profile:::profile-1001hz
/arg0/
{
    @[ stack() ] = count();
}
  • Помістіть це у файл, назвіть його дещо описовим hotspot.d
  • chmod це виконуваний файл: chmod 755 hotspot.d
  • Запустіть його: ./hotspot.d
  • Через кілька секунд після того, як він надрукує щось збігаючись з N зондами, зупиніть його роботу, натиснувши CTRL-C.

Ви побачите багато даних - кожен стек стека ядра, який він вибирав під час його запуску, упорядкований шляхом збільшення кількості відліків для цієї трасування стека. Ігноруйте ті, які є idle в трасі стека десь - це цикл простою - і це цілком імовірно, що останні декілька слідів стеку не є простою, де ваша система витрачає весь свій час.

— Andrew Henle
джерело
Використання dtrace -n Я отримую помилку dtrace: invalid probe specifier. Це має бути dtrace -s ? Edit: Так, я підтвердив, що це має бути dtrace -s, вихід виглядає так, як ви описали.
— protogen
Якщо ви виправили свою публікацію dtrace -s Зверніть увагу також на відсутність вибуху #!/usr/sbin/dtrace -s
— protogen
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.