一部のvmware collectorプロセスが100%になり、Zabbix_serverプロセスが再起動する
Zabbix4.0.7
最近になって、一部のvmware collectorプロセスが100%になり、
定期的にZabbix_serverプロセスが再起動する事象が発生しています。
デバッグレベルを上げてログを確認しましたが、原因がよく分からなかったため、
もし分かる方がいましたらお力を貸していただいたいです。
■/var/log/zabbix_server.log
================================================================
__mem_malloc: skipped 161 asked 19721864 skip_min 264 skip_max 44920 size 125958248
__mem_malloc: skipped 0 asked 144 skip_min 18446744073709551615 skip_max 0
[file:vmware.c,line:92] __zbx_mem_malloc(): out of memory (requested 140 bytes)
[file:vmware.c,line:92] __zbx_mem_malloc(): please increase VMwareCacheSize configuration parameter
=== memory statistics for vmware cache size ===
free chunks of size 72 bytes: 1
min chunk size: 72 bytes
max chunk size: 72 bytes
memory of total size 134216928 bytes fragmented into 1525807 chunks
of those, 72 bytes are in 1 free chunks
of those, 109803960 bytes are in 1525806 used chunks
================================
=== Backtrace: ===
14: /usr/sbin/zabbix_server: vmware collector #5 [updated 0, removed 0 VMware services in 0.000011 sec, querying VMware services](zbx_backtrace+0x42) [0x7f4b1457ad9a]
13: /usr/sbin/zabbix_server: vmware collector #5 [updated 0, removed 0 VMware services in 0.000011 sec, querying VMware services](__zbx_mem_malloc+0x197) [0x7f4b14576371]
12: /usr/sbin/zabbix_server: vmware collector #5 [updated 0, removed 0 VMware services in 0.000011 sec, querying VMware services](+0x7c7c9) [0x7f4b144fa7c9]
11: /usr/sbin/zabbix_server: vmware collector #5 [updated 0, removed 0 VMware services in 0.000011 sec, querying VMware services](zbx_hashset_insert_ext+0x12e) [0x7f4b1458023b]
10: /usr/sbin/zabbix_server: vmware collector #5 [updated 0, removed 0 VMware services in 0.000011 sec, querying VMware services](+0x7dca0) [0x7f4b144fbca0]
9: /usr/sbin/zabbix_server: vmware collector #5 [updated 0, removed 0 VMware services in 0.000011 sec, querying VMware services](+0x7edc5) [0x7f4b144fcdc5]
8: /usr/sbin/zabbix_server: vmware collector #5 [updated 0, removed 0 VMware services in 0.000011 sec, querying VMware services](+0x7f502) [0x7f4b144fd502]
7: /usr/sbin/zabbix_server: vmware collector #5 [updated 0, removed 0 VMware services in 0.000011 sec, querying VMware services](+0x858a7) [0x7f4b145038a7]
6: /usr/sbin/zabbix_server: vmware collector #5 [updated 0, removed 0 VMware services in 0.000011 sec, querying VMware services](vmware_thread+0x340) [0x7f4b14505abe]
5: /usr/sbin/zabbix_server: vmware collector #5 [updated 0, removed 0 VMware services in 0.000011 sec, querying VMware services](zbx_thread_start+0x37) [0x7f4b1458878c]
4: /usr/sbin/zabbix_server: vmware collector #5 [updated 0, removed 0 VMware services in 0.000011 sec, querying VMware services](MAIN_ZABBIX_ENTRY+0xdbc) [0x7f4b144b816a]
3: /usr/sbin/zabbix_server: vmware collector #5 [updated 0, removed 0 VMware services in 0.000011 sec, querying VMware services](daemon_start+0x2f6) [0x7f4b1457a5de]
2: /usr/sbin/zabbix_server: vmware collector #5 [updated 0, removed 0 VMware services in 0.000011 sec, querying VMware services](main+0x312) [0x7f4b144b73ac]
1: /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f4b10d59af5]
0: /usr/sbin/zabbix_server: vmware collector #5 [updated 0, removed 0 VMware services in 0.000011 sec, querying VMware services](+0x384d9) [0x7f4b144b64d9]
One child process died (PID:31769,exitcode/signal:1). Exiting ...
Got signal [signal:15(SIGTERM),sender_pid:31729,sender_uid:992,reason:0]. Exiting ...
Got signal [signal:15(SIGTERM),sender_pid:31729,sender_uid:992,reason:0]. Exiting ...
Got signal [signal:15(SIGTERM),sender_pid:31729,sender_uid:992,reason:0]. Exiting ...
Got signal [signal:15(SIGTERM),sender_pid:31729,sender_uid:992,reason:0]. Exiting ...
Got signal [signal:15(SIGTERM),sender_pid:31729,sender_uid:992,reason:0]. Exiting ...
zabbix_server [31729]: Error waiting for process with PID 31769: [10] No child processes
syncing history data...
syncing history data done
syncing trend data...
syncing trend data done
Zabbix Server stopped. Zabbix 4.0.7 (revision 92831).
Starting Zabbix Server. Zabbix 4.0.7 (revision 92831).
================================================================
TNK - 投稿数: 4671
out of memoryですから、メモリ不足が発生しているのだと思われ
ます。ログに
please increase VMwareCacheSize configuration parameter
と出力されていますが、VMwareCacheSizeの調整は試されましたか？
Yasumi - 投稿数: 372
ありがとうございます。
今日の朝に、VMwareCacheSizeを64MBから128MBに引き上げました。
VMwareCacheSizeの最新の使用量が6.37 MBなので、不足しているように思えませんが、
事象が解消されていないのでさらに256MBに上げてみます。
⇒256MBでも解消されないようです。
なぜ発生したか現在まで不明ですが、3.4.7で解決された事象と似ている気がしています。
https://support.zabbix.com/browse/ZBX-13441
TNK - 投稿数: 4671
記載頂いたバグは、zabbix_serverがSIGSEGVやSIGBUSで異常終了してしまうケースです。
今回ご質問頂いた問題は、メモリ不足エラーですので別の問題だと思います。
-- 追記
VCenterの配下に多数のESXiがあったりしませんか？
VCenterはあまり高スペックではない場合も多いと思いますが、特定のVCenter配下の
監視対象が多かったりレスポンスが遅かったりすると、特定のプロセスが上昇したまま
の時間が継続しやすくなると思います。
Yasumi - 投稿数: 372
ありがとうございます。
監視対象のvCenterは3台です。1st vCenterはやや規模が大きいですが、
先週までは正常で、この1年間で「特定のプロセスが上昇したまま」の状態はありませんでした。
なので、なぜ突然ほぼ2時間おきにZabbix_serverが再起動するのか悩んでいる状態です。
直接関係あるかは不明ですが、最近DBとMemoryまわりを気にしています。
Memroy48GB搭載していますが、available33GBあるにも関わらず、cache44GB使用していてSwapします。
PostgreSQL(9.2)の自動バキュームが追い付かない時期があり、DB使用量が40GBほど。
history_uintが18GBあり、どうしたものか、と思っています。
================================================================
1st vCenter
ESXi 25台
VM 379台
2nd vCenter
ESXi 3台
VM 125台
3rd vCenter
ESXi 4台
VM 150台
※LLDは10m毎。ESXiは5m/40d/730d、VMは10m/1w/90dのアイテム取得。
================================================================
TNK - 投稿数: 4671
VCenterは物理サーバーですか？VMですか？
VMであったとしたら、そのVMを起動しているハイパーバイザーの負
荷状況に変化はありませんか？
サーバーのswap発生に関しては、そのサーバー上で稼働させている
サービスで使用しているメモリ配分の見直しをされた方が良いと思
います。
場合によっては、一部のサービスを別のサーバーに移動させるなど
の対応の検討も必要かもしれません。
データベースのサイズに関しては、サイズを減らしたいのであれば、
・監視のアイテム数を減らす
・監視間隔を伸ばす
・保存期間を短くする
などを行って、保持するデータの量を削減するしかないでしょう。
Yasumi - 投稿数: 372
ありがとうございます。
vmware collectorに負荷を掛けていた原因が判明しました。
いまフォーラムに別でスレッドを立てていますが、
3rd vCenterのvmware.eventlog監視が有効（取得不可）になっていたのが原因でした。
見る限り3rd vCenterのeventlog出力はそこまで量が過大には思えませんが、
何かしらの理由で取得できずに負荷を掛けていたようです。（まさかzabbix_serverごと再起動するとは。。。）
・vmware.eventlogだけが「Timeout was reached」になる
http://www.zabbix.jp/node/4783
swapについては検討してみますが、データベースのサイズはPostgreSQLを利用しているため
FULL VACUUM（したくない）しないと、データサイズ削減は難しそうです。。。
TNK - 投稿数: 4671
物理的なファイルサイズを小さくするには、VACUUM FULLを行った
方が良いとは思いますが、swapを発生させなくするためにと考えら
れているのであれば、それは誤りだと思います。
データベースのデータファイルサイズだけがswap発生に影響がある
とは限りません。
頻繁に、history_uintテーブルから全件検索を行うなど、大きなデ
ータを常にキャッシュ上に置くような処理が無い限り、対象のテー
ブルのデータ全てがメモリ上に置かれるわけではありません。
しかも、データファイルのサイズが大きくても、未使用領域があれ
ば、データベース上でキャッシュされる実データのサイズはファイ
ルのサイズより小さくなるはずです。
サーバー上で動かしているのはデータベース以外にもあるのだと思
われますが、トータルで実メモリを超えるようなメモリ割り当てを
してしまっている可能性が考えられので、昨日の「メモリ配分の見
直しを」と指摘させて頂いたのです。
swapを発生させてしまうようなメモリ配分よりも、実メモリで処理
できる範囲でそれぞれのサービスに配分したほうがパフォーマンス
が向上するかもしれません。
ご検討ください。
-- 追記
VCenter側のパフォーマンスの問題はVCenter側で改善するか、
単位時間での監視項目の処理数を削減することをご検討ください。
Yasumi - 投稿数: 372
＞swapを発生させなくするために～誤り
その通りです、VACUUM FULLをする予定はありません。
vCenterの問題は了解しました。考えてみます。
サーバー上で動かしているのはZabbixだけです。。。
confの設定は、Cache 256 MB/history 16 MB/index 4 MB/trend 64 MB/configuration 512 MBの割り当てですが、
PostgreSQLのプロセスが使用するrssの合計は80GBにも及びます。
ここは私のDB設定や何かしらの知識不足に起因するかもしれないです、、、
TNK - 投稿数: 4671
Zabbixサーバープロセスだけではないですよね？
WebサーバーもPostgreSQLも動いているのですよね？
とはいえ、PostgreSQLが80GBも消費しているのであれば、その部分
の改善の余地はありそうですね。
Yasumi - 投稿数: 372
はい、htttpもpostgresも起動しています。
DBチューニングを独学でしているので、https://pgtune.leopard.in.ua/#/なども使いましたが
これが適正な状態なのか判断ができていません。。。ともかくpostgresqlのRSSが大きいです。
・postgresql.conf
shared_buffers = 12GB
temp_buffers = 32MB
work_mem = 256MB
maintenance_work_mem = 2GB
max_stack_depth = 2MB
effective_io_concurrency = 200
wal_buffers = 16MB
random_page_cost = 1.1
#cpu_tuple_cost = 0.01
effective_cache_size = 32GB
============================================================
・postgresのRSS使用量
※zabbix_serverの再起動で減っていますが、80GBまでいきます
# ps -aux | grep -v grep | grep postgres
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
postgres 13939 0.0 0.6 13083392 310324 ? S 7月29 0:15 /usr/bin/postgres -D /data/pgsql -p 5432
postgres 13940 0.0 0.0 192636 1820 ? Ss 7月29 0:00 postgres: logger process
postgres 13942 0.1 24.6 13089992 12143192 ? Ss 7月29 2:11 postgres: checkpointer process★11.6GB
postgres 13943 0.0 1.9 13089540 978016 ? Ss 7月29 0:10 postgres: writer process
postgres 13944 0.0 0.0 13089540 18040 ? Ss 7月29 0:08 postgres: wal writer process
postgres 13945 0.0 0.0 13090788 3304 ? Ss 7月29 0:02 postgres: autovacuum launcher process
postgres 13946 0.0 0.0 192252 1968 ? Ss 7月29 0:50 postgres: stats collector process
postgres 25343 0.0 0.0 13091988 40628 ? Ss 7月29 0:01 postgres: zabbix zabbix [local] idle
（中略）
postgres 25699 1.3 0.2 13093176 105460 ? Ss 7月29 16:26 postgres: zabbix zabbix [local] idle★zabbix idleが計31GB