Low CPU frequency of a dedicated server
It may happens that a CPU frequency on a server under load may be lower than you expect.
Check it out:
Check it out:
[coma][rrb][~] # cat /proc/cpuinfo | grep -c processor
8
[coma][rrb][~] # cat /proc/cpuinfo | head -n 25
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 94
model name : Intel(R) Xeon(R) CPU E3-1230 v5 @ 3.40GHz
stepping : 3
microcode : 0xa6
cpu MHz : 800
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
bugs:
bogomips : 6816.00
clflush size: 64
cache_alignment: 64
address sizes : 39 bits physical, 48 bits virtual
There is a physical blade server with 4 cores, every single one has 2 threads. Wee are seeing that the designated frequency of one CPU is 3.40GHz. But the real frequency, as we can see, is 800 MHz.
Checking the current frequency of the rest part of cores:
[coma][rrb][~] # cat /proc/cpuinfo | grep MHz
cpu MHz : 800
cpu MHz : 800
cpu MHz : 800
cpu MHz : 800
cpu MHz : 800
cpu MHz : 800
cpu MHz : 800
cpu MHz : 800
Every core has the same frequency - 800 MHz. Okay, maybe the server is not strongly used. Let's load it by using dd command and useless bytes transfer:
dd if=/dev/zero of=/dev/null
But frequency didn't grow to its optimal values and is staying on the same place. Checking other blades in the same platform (chassis). Looks like they all are affected by this problem. All have the frequency mush lower than it needs. Checking system logs doesn't help in this situation.
The real reason for this problem occurs at the hardware level, namely in the power supply.
Go to the server's ipmi management console, if you have it. There you will see an alerts about the power supply in events log like these:
8 2017/01/13 06:17:53 PS2 Status Power Supply Power Supply Failure Detected - Assertion
9 2017/01/13 09:27:17 PS2 Status Power Supply Power Supply Failure Detected - De-assertion
It tells that you need to replace a bad second power supply (PS2). After that all will be fine and all servers in the chassis will be fully operational.
NB. This is only my case and this solution may not suit everyone. The situation is really strange because a chassis has two power supplies ONLY for redundancy NOT for a parallel energy consumption. Each 2KW power supply fully provides enough energy for a chassis, which contains 12 blades. In the event of loss of one power supply, the performance of the server should not degrade. I think it's a bug of Supermicro (we use Supermicro Microcloud).
NB. This is only my case and this solution may not suit everyone. The situation is really strange because a chassis has two power supplies ONLY for redundancy NOT for a parallel energy consumption. Each 2KW power supply fully provides enough energy for a chassis, which contains 12 blades. In the event of loss of one power supply, the performance of the server should not degrade. I think it's a bug of Supermicro (we use Supermicro Microcloud).
Written on October 19, 2017