fork
10.08.16, 18:36
Hallo zusammen,
ich habe die Tage ein interessantes Phänomen. Ich habe hier diverse Citrix-XenServer (Version 6.5). Dort läuft auch meine Monitoring-VM(Check-MK). Die habe ich die Tage im laufenden Betrieb auf einen anderen Server verschoben. Danach ist die VM brechend langsam geworden. 100% CPU-Last. Die VM hat 4 Cores zugewiesen. Auf dem neuen Host, habe ich die Anzahl der CPU-Cores auf 8 aufgestockt. Immer noch das gleiche Spiel. Auch mit 8 Cores fast vollständig auf 100% Auslastung. Anschliessend habe ich die VM nochmal weiter auf einen dritten Host geschubst und da lief das dann wieder alles super. Die 3. CPU ist auch noch gedrosselt, d. h. da sind CPU-Features abgeschaltet, damit die Livemigration funktioniert.
So grundsätzlich ist die i7-CPU des 2. Hosts ja um einiges schneller als die etwas älteren Xeon-CPUs. Das wundert mich, warum die Leistung der VM gerade dort eingebrochen ist. Zusätzlich ist der 2. Host komplett leer - keine anderen VMs. Die Daten des Monitorings decken sich mit dem was top/htop ausgibt. Die VM steht schon auch ordentlich unter Dampf. Die macht 100 Service-checks pro Sekunde.
Die Bilder im Anhang zeigen noch mal die Situation. Die Utilization hat im Zuge des ersten Umzuges etwas I/O-Wait angezeigt, weil die komplette Festplatte gelesen wurde. Soweit ganz normal. Anschliessend schiesst die Load und CPU-Last hoch und geht erst wieder auf dem neuen System herunter auf Ursprungslast. Der Grund warum die Load zwischendrin runter geht, ist der das ich eine von zwei Monitoring-Instanzen abgeschaltet habe, da der Server mit Load 50 unbrauchbar war.
RAM hatte die VM immer genug und die I/O war auch über die gesamte Zeit relativ konstant bei 1 MB schreiben pro Sekunde.
Habt Ihr dazu Ideen was das sein könnte?
21062
21063
Das war die CPU vom ersten Host(4 Cores):
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
stepping : 5
microcode : 0xf
cpu MHz : 2261.064
cache size : 8192 KB
physical id : 1
siblings : 4
core id : 1
cpu cores : 2
apicid : 19
initial apicid : 19
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl nonstop_tsc pni monitor vmx est ssse3 cx16 sse4_1 hypervisor lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips : 4522.12
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
Das war die CPU vom zweiten Host(8 Cores):
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
stepping : 7
microcode : 0x28
cpu MHz : 3392.392
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl nonstop_tsc pni pclmulqdq monitor vmx est ssse3 cx16 sse4_1 sse4_2 popcnt tsc_deadline_timer aes hypervisor lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips : 6784.78
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
Das war die CPU vom dritten Host:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 44
model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
stepping : 2
microcode : 0x14
cpu MHz : 2400.148
cache size : 12288 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl nonstop_tsc pni monitor vmx est ssse3 cx16 sse4_1 hypervisor lahf_lm ida arat epb dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips : 4800.29
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
ich habe die Tage ein interessantes Phänomen. Ich habe hier diverse Citrix-XenServer (Version 6.5). Dort läuft auch meine Monitoring-VM(Check-MK). Die habe ich die Tage im laufenden Betrieb auf einen anderen Server verschoben. Danach ist die VM brechend langsam geworden. 100% CPU-Last. Die VM hat 4 Cores zugewiesen. Auf dem neuen Host, habe ich die Anzahl der CPU-Cores auf 8 aufgestockt. Immer noch das gleiche Spiel. Auch mit 8 Cores fast vollständig auf 100% Auslastung. Anschliessend habe ich die VM nochmal weiter auf einen dritten Host geschubst und da lief das dann wieder alles super. Die 3. CPU ist auch noch gedrosselt, d. h. da sind CPU-Features abgeschaltet, damit die Livemigration funktioniert.
So grundsätzlich ist die i7-CPU des 2. Hosts ja um einiges schneller als die etwas älteren Xeon-CPUs. Das wundert mich, warum die Leistung der VM gerade dort eingebrochen ist. Zusätzlich ist der 2. Host komplett leer - keine anderen VMs. Die Daten des Monitorings decken sich mit dem was top/htop ausgibt. Die VM steht schon auch ordentlich unter Dampf. Die macht 100 Service-checks pro Sekunde.
Die Bilder im Anhang zeigen noch mal die Situation. Die Utilization hat im Zuge des ersten Umzuges etwas I/O-Wait angezeigt, weil die komplette Festplatte gelesen wurde. Soweit ganz normal. Anschliessend schiesst die Load und CPU-Last hoch und geht erst wieder auf dem neuen System herunter auf Ursprungslast. Der Grund warum die Load zwischendrin runter geht, ist der das ich eine von zwei Monitoring-Instanzen abgeschaltet habe, da der Server mit Load 50 unbrauchbar war.
RAM hatte die VM immer genug und die I/O war auch über die gesamte Zeit relativ konstant bei 1 MB schreiben pro Sekunde.
Habt Ihr dazu Ideen was das sein könnte?
21062
21063
Das war die CPU vom ersten Host(4 Cores):
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
stepping : 5
microcode : 0xf
cpu MHz : 2261.064
cache size : 8192 KB
physical id : 1
siblings : 4
core id : 1
cpu cores : 2
apicid : 19
initial apicid : 19
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl nonstop_tsc pni monitor vmx est ssse3 cx16 sse4_1 hypervisor lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips : 4522.12
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
Das war die CPU vom zweiten Host(8 Cores):
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
stepping : 7
microcode : 0x28
cpu MHz : 3392.392
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl nonstop_tsc pni pclmulqdq monitor vmx est ssse3 cx16 sse4_1 sse4_2 popcnt tsc_deadline_timer aes hypervisor lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips : 6784.78
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
Das war die CPU vom dritten Host:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 44
model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
stepping : 2
microcode : 0x14
cpu MHz : 2400.148
cache size : 12288 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl nonstop_tsc pni monitor vmx est ssse3 cx16 sse4_1 hypervisor lahf_lm ida arat epb dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips : 4800.29
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: