Почему Load Average > 2000 на нормально работающем сервере?

Question

[Den K]

Сегодня обнаружил стабильный рост load average. Сейчас он уже около 2100. Сервер работает нормально.

top - 05:51:05 up 51 days, 19:19, 2 users, load average: 2152.96, 2105.26, 1978.46
Tasks: 169 total, 1 running, 168 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.1 us, 0.7 sy, 0.0 ni, 98.1 id, 0.1 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem : 2047836 total, 82308 free, 1407496 used, 558032 buff/cache
KiB Swap: 999420 total, 845208 free, 154212 used. 398712 avail Mem

Кто нибудь сталкивался с таким?

Comments

[roswell]

А что показывает cat /proc/cpuinfo ?

[Den K]

roswell,

spoiler

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 85
model name : Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz
stepping : 4
microcode : 0x2000035
cpu MHz : 2999.999
cache size : 25344 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
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 mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single retpoline kaiser fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 invpcid rtm rdseed adx smap xsaveopt arat
bugs : cpu_meltdown spectre_v1 spectre_v2
bogomips : 5999.99
clflush size : 64
cache_alignment : 64
address sizes : 42 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 85
model name : Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz
stepping : 4
microcode : 0x2000035
cpu MHz : 2999.999
cache size : 25344 KB
physical id : 2
siblings : 1
core id : 0
cpu cores : 1
apicid : 2
initial apicid : 2
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 mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single retpoline kaiser fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 invpcid rtm rdseed adx smap xsaveopt arat
bugs : cpu_meltdown spectre_v1 spectre_v2
bogomips : 5999.99
clflush size : 64
cache_alignment : 64
address sizes : 42 bits physical, 48 bits virtual
power management:

processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 85
model name : Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz
stepping : 4
microcode : 0x2000035
cpu MHz : 2999.999
cache size : 25344 KB
physical id : 4
siblings : 1
core id : 0
cpu cores : 1
apicid : 4
initial apicid : 4
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 mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single retpoline kaiser fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 invpcid rtm rdseed adx smap xsaveopt arat
bugs : cpu_meltdown spectre_v1 spectre_v2
bogomips : 5999.99
clflush size : 64
cache_alignment : 64
address sizes : 42 bits physical, 48 bits virtual
power management:

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 85
model name : Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz
stepping : 4
microcode : 0x2000035
cpu MHz : 2999.999
cache size : 25344 KB
physical id : 6
siblings : 1
core id : 0
cpu cores : 1
apicid : 6
initial apicid : 6
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 mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single retpoline kaiser fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 invpcid rtm rdseed adx smap xsaveopt arat
bugs : cpu_meltdown spectre_v1 spectre_v2
bogomips : 5999.99
clflush size : 64
cache_alignment : 64
address sizes : 42 bits physical, 48 bits virtual
power management:

Answer 1

[lega]

Любой процесс может выставить статус "блокирован", обычно когда обращается к диску или другое IO, ядро это учитвает при расчете loadAverage, в итоге если какое-то приложение выставило этот статус и оставило его висеть, то loadAverage будет расти.
Поищите процессы со статусом D (например через ps aux), в теории у вас должно быть не менее 7 таких процессов.

Comments

[Den K]

Спасибо за наводку. Обнаружил несколько тысяч процессов со статусом D.
Несколько команд lsof так же были с этим статусом.
Будем разбираться что было.

Answer 2

[Руслан Федосеев]

Процессов у вас там много. Залогиньтесь, посмотрите, что происходит.
LA не всегда обозначает, что серверу все )

Comments

[Den K]

Процессов много, все нужные.
Происходит штатная работа сервера. Это одна их нод docker swarm.
LA как будто плюсуется, а не отображается в реальном времени.

[Руслан Федосеев]

LA на сервере и LA в забиксе не совпадают? проверяйте заббикс

[lega]

> Процессов у вас там много
это не много, да и не в количестве процессов дело