VMware LLD自動監視における ZabbixサーバのMemory Cache肥大化について
はじめまして。いつも閲覧させていただいております。
標題の通り、VMware LLD自動監視をしている ZabbixサーバのMemory Cacheが
肥大化しており、理由と対処法が分からず困っております。
下記にOS情報等を記載しますので、お力を貸していただきたいです。
==================================
●OS情報
OS：REHL 7.1
Zabbixバージョン：3.2.1
CPUコア数：2
Memory容量：16GB
●監視台数
Hypervisor：20台程度
ゲストOS：400台程度
※テンプレートの更新間隔はHypervisorが3時間。
ゲストOSが5分。アイテム取得間隔の多くが60秒です。
●Memory使用状況
total：15:52GB
used：14.02GB
free：1.49GB
available：12.53GB
cached：13.24GB
buffers：884MB
●postgresql.conf設定
shared_buffers：2GB
temp_buffers：32MB
work_mem：16MB
maintenance_work_mem：128MB
max_stack_depth：4MB
==================================
ZabbixのValueCacheの使用率は10%以下のため、Postgresの設定に問題がある可能性を疑っていますが
400台程度の規模で13GB以上のCacheを専有するのが普通なのか、ご教授いただきたいです。
※追加で必要な情報があれば、随時記載します。
karna - 投稿数: 60
Cacheとして専有しているわけではありません。
また、現状での対処も不要と思われます。
Linuxのメモリ管理に起因する話なので、zabbixやSQLサーバーで制御する話ではありません。
基本的に、メモリがある分キャッシュに利用されますが、
> available：12.53GB （未使用メモリ＋すぐに開放できるメモリ）
こちらの値に余裕があれば、問題ありません。
講釈を垂れるほどLinuxに精通しているわけではないので、詳しくは検索等でご確認ください。
質問とは無関係ですが、3.2系の初期バージョンで不具合も多いかと思います。
また、サポートも終了していますので、3.4系(あるいは3.2系の最終版)に更新された方がよいかもしれません。
Yasumi - 投稿数: 373
＞karnaさん
ありがとうございます。availableに余裕あるのですが、Swapしてしまうのですよね。
それさえなければ気にならず良かったのですが。
色々検索して調べましたが、同様にCacheが肥大化しているケースで参考になるものを見つけられなかったです。
提案いただいているバージョンアップはすでに考えていて、改善する可能性があるのでしようと思っています。
他の方で知見がありましたら受け付けておりますので、引き続きよろしくお願いします。
fripper - 投稿数: 495
Linux のメモリ管理と avaliable / free / cache / buffer 等の関連は
先に karna さんがコメントくださっている通りです
空きメモリがある限りは、キャッシュやバッファ等の用途としてOS(kernel)が
効率よく使おうとするような動作となりますので、起動プログラム数が
少ない限りにおいては、それほど切実な問題ではないと思います
プログラムがスワップされてしまうことについても、
OS側が「利用頻度が低い」と判断すれば、多少スワップされてしまうことは
起こり得るので、「空いているのでスワップは０になるはず」とは言えないと思います
‥という一般論とは別に、RHEL7.1環境、という点で‥
‥Zabbixからは少し外れますが
＞https://access.redhat.com/errata/RHBA-2015:0364
＞https://qiita.com/digitalpeak/items/4b39fdcb8fae7d09f406
この問題については、ご利用の環境で対策済でしょうか？
curl を利用して https アクセスする場合に、nss ライブラリの問題で
dentry と呼ばれるファイルに関するキャッシュ情報が肥大化してしまう問題です
＃zabbix_serverも libcurl を利用しているはずなので、影響あるのでは？との推測からです
「cat /proc/meminfo」のコマンド実行で、「SReclaimable」が不自然に大きな値となっていたり
「cat /proc/slabinfo」で dentry_cache の値が不自然に大きければ、該当しているかも？
Yasumi - 投稿数: 373
＞fripperさん
ありがとうございます。Cacheが16GB中14GBを取っているので気になりますが、
ご指摘の通りシステムに即時に影響を与えるものではないですね。
※Swapの動向次第では、定期的な再起動を要求される可能性はありますが。
RHEL7.1観点での指摘は大変ありがたいです。
コマンド実行で確認しましたが、SReclaimableやdentryがGBを超えるような値は取っていませんでした。
今回は該当していなかったですが、OSのMemory観点として覚えておこうと思います。
また、Zabbixのバージョンを最新の3.4.9に上げてみましたが事象解消しませんでした。
/var/log/zabbix/zabbix_server.logに短期的なスパンで何度も「bacame supported」「became not supported」が出力されており
ディスカバリーのアイテム取得状態が影響しているかもしれないので、継続調査しようと思っています。
またOS観点も気にしていますので、RHEL7.4で構築して同様になるかなど確かめたいなと思います。
※他の方で知見がありましたら受け付けておりますので、引き続きよろしくお願いします。
yk_taiko - 投稿数: 184
ValueCache はマクロの値などを格納するためのキャッシュですが、
他のキャッシュは設定値も含めてどうなっていますでしょうか。
Yasumi - 投稿数: 373
＞yk_taikoさん
ありがとうございます。
zabbix_server.confの情報を記載させていただきますね。
下記以外はデフォルト設定となっております。
StartDiscoverers=30
StartPingers=30
StartVMwareCollectors=20
VMwareFrequency=60
VMwarePerfFrequency=60
VMwareCacheSize=128M
VMwareTimeout=180
CacheSize=1G
StartDBSyncers=6
TrendCacheSize=16M
ValueCacheSize=64M
Timeout=5
LogSlowQueries=3000
unreachable pollerが、LLDの更新にあわせて一定間隔で20%程度になって0%になるを繰り返す以外は、
全体的にZabbixプロセスの負荷率は0～15%程度に収まっており、気になる傾向はないと感じておりますが
知見がございましたらご教授いただけますと助かります。
Yasumi - 投稿数: 373
本件ですが、DB初期化してZabbix再インストールによって解消しました。
クローズでお願いします。