Некорректно считается vm.memory.size[available]

[DRVTiny]

$ fgrep MemAvailable /proc/meminfo 
MemAvailable:    2022324 kB

$ echo "Zabbix estimated available memory size: "$(( $(zabbix_get -s msk1-vm-monitor01.mydomain.com -k "vm.memory.size[available]")»10 ))' kB'
Zabbix estimated available memory size: 436692 kB

Как же так? Не совпадают цифры, однако. Разница в 5 раз!
Чему же верить?

[Kos]

Ну, вряд ли с такой "подробной" информацией Вам кто-нибудь ответит по существу.
Смотрим системный файл /proc/meminfo на локальном компьютере с неизвестной операционкой неизвестной версии, полученное значение сравниваем с выводом от Zabbix-агента неизвестной версии, который работает, вероятно, на другом компьютере с такой же неизвестной операционкой такой же неизвестной версии.

А вообще по поводу параметра vm.memory.size немного написано тут.

[DRVTiny]

Я не понимаю, у вас паранойя что ли или Вы сомневаетесь в моей профессиональной компетенции?

С компетенцией, уверяю Вас, у меня всё в порядке, остаётся, очевидно, второе.

Вас не волнует тот факт, что проблема реально есть, но вот лично у Вас не проявляется? Ну ОК, ступайте себе мимо, зачем чушь писать?

Да, если Вам это облегчит жизнь, то free показывает то же, что и /proc/meminfo

[Kos]

Уважаемый, не надо переходить на личности и хамить тем, кто пытается Вам же помочь.
Умение общаться, кстати, тоже часть профессиональной компетенции.

А по сути вопроса - Вы так и не предоставили какой-либо полезной информации для анализа. Как говорится, "телепаты в отпуске".

[DRVTiny]

А что именно предоставлять?

Виртуальная машина VMware
CentOS 7
Zabbix 3.0.2, из официального репозитория для RHEL 7
10Гб памяти, 6 CPU

Агент работает на той же машине, на которой запускаю zabbix_get и делаю fgrep MemAvail /proc/meminfo (что вроде итак было очевидно)

Что ещё можно указать?
БД и веб-"фронтенд" работают на других виртуалках.

[a.konovalov@msk1-vm-monitor01 ~]$ for i in total available free used cached buffers; do echo "${i^} memory size: "$(( $(zabbix_get -s msk1-vm-monitor01.mydomain.com -k "vm.memory.size[$i]")>>20 ))'M'; done
Total memory size: 9839M
Available memory size: 827M
Free memory size: 232M
Used memory size: 9606M
Cached memory size: 594M
Buffers memory size: 0M
[a.konovalov@msk1-vm-monitor01 ~]$ free
              total        used        free      shared  buff/cache   available
Mem:       10075724     7906412      239656      267244     1929656     1518252
Swap:       1023996      298744      725252
[a.konovalov@msk1-vm-monitor01 ~]$ head -n10 /proc/meminfo
MemTotal:       10075724 kB
MemFree:          248512 kB
MemAvailable:    1527160 kB
Buffers:              16 kB
Cached:           608700 kB
SwapCached:         1416 kB
Active:          7410772 kB
Inactive:         557528 kB
Active(anon):    7245724 kB
Inactive(anon):   384696 kB
[a.konovalov@msk1-vm-monitor01 ~]$ uname -r
3.10.0-229.14.1.el7.x86_64
[a.konovalov@msk1-vm-monitor01 ~]$ vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0 298744 239852     16 1929712    0    1     1     4    8   4  9  1 91  0  0

[aib]

Судя по всему, zabbix прибавляет swap к реально свободной памяти
Вот мои результаты
Centos 7
VMware ESXi 5.5.0
VM settings : Memory = 16 Gb

[root@z3 ~]# for i in total available free used cached buffers; do echo "${i^} memory size: "$(( $(zabbix_get -s localhost -k "vm.memory.size[$i]") >>20 ))'M'; done                                              Total memory size: 15887M
Available memory size: 3172M
Free memory size: 385M
Used memory size: 15501M
Cached memory size: 2817M
Buffers memory size: 0M
[root@z3 ~]# free
              total        used        free      shared  buff/cache   available
Mem:       16268716    12687180      407988       14740     3173548     3262112
Swap:       4063228     1027092     3036136
[root@z3 ~]# head -n10 /proc/meminfo
MemTotal:       16268716 kB
MemFree:          371920 kB
MemAvailable:    3226056 kB
Buffers:               0 kB
Cached:          2885448 kB
SwapCached:        17884 kB
Active:          9829052 kB
Inactive:        3045948 kB
Active(anon):    8588156 kB
Inactive(anon):  1416136 kB
[root@z3 ~]# uname -r
3.10.0-327.18.2.el7.x86_64
[root@z3 ~]# vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  1 1027092 390008      0 3173108    1    2   369   913   25   21 12  8 78  2  0

Об этом, кстати, упомянуто в документации

https://www.zabbix.com/documentation/3.0/manual/appendix/items/vm.memory.size_params

[DRVTiny]

Алексей, я не понял, честно. Можно в цифрах на моём примере?

[Kos]

В документации по Zabbix, ссылку на которую я давал в самом начале, сказано:

◾ в Linux available является равной free + buffers + cached

В Вашем случае так оно и есть (ну, плюс-минус погрешность округления при пересчёте в мегабайты).
Причём каждая из величин по отдельности (free, buffers, cached, total) тоже более-менее совпадает с теми результатами, которые видны из /proc/meminfo.

Так что осталось разобраться с тем, что подразумевает ядро Linux-а в качестве значения MemAvailable, которое оно отдаёт через тот же /proc/meminfo. Очевидно, что тут используется другой алгоритм; небольшой поиск приводит к первоисточнику, который затем цитируется во многих местах:

Many load balancing and workload placing programs check /proc/meminfo to estimate how much free memory is available. They generally do this by adding up "free" and "cached", which was fine ten years ago, but is pretty much guaranteed to be wrong today.

It is wrong because Cached includes memory that is not freeable as page cache, for example shared memory segments, tmpfs, and ramfs, and it does not include reclaimable slab memory, which can take up a large fraction of system memory on mostly idle systems with lots of files.

Currently, the amount of memory that is available for a new workload, without pushing the system into swap, can be estimated from MemFree, Active(file), Inactive(file), and SReclaimable, as well as the "low" watermarks from /proc/zoneinfo.

Первоначально этот параметр появился в ядре версии 3.14, но потом был портирован и в некоторые более старые ядра (пример от Red Hat).