キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 
cancel
436
閲覧回数
0
いいね!
0
コメント
Satoshi Kinoshita
Cisco Employee
Cisco Employee

Cisco VIM (CVIM) で発生した HUGEPAGE に関する問題のトラブルシュート方法を紹介します。

 

問題

CVIMコンピュートノード上で動作するVMが不安定になっているという報告がありました。VMを起動しようとしてもメモリのエラーが出力されて起動できません。

 

問題解析

該当コンピュートノードで /var/log/messages を参照すると多くのプロセスが再起動をを繰り返してました。

 

# cat /var/log/syslog
::
Apr 5 21:15:58 compute9 python: ansible-systemd Invoked with name=docker-novacpu enabled=True daemon_reload=False state=restarted user=False masked=None
Apr 5 21:15:58 compute9 systemd: Stopping Nova SSH Service...
Apr 5 21:15:58 compute9 journal: *** Shutting down /nova_ssh_start.sh (PID 8)...
Apr 5 21:15:58 compute9 journal: *** Init system aborted.
Apr 5 21:15:58 compute9 journal: *** Killing all processes...
Apr 5 21:16:00 compute9 telegraf: 2020-04-05T12:16:00Z W! [agent] input "inputs.libvirt" did not complete within its interval
Apr 5 21:16:05 compute9 telegraf: 2020-04-05T12:16:05Z E! [inputs.docker]: Error in plugin: E! Error gathering container [/novassh_19767] stats: Error getting docker stats: context deadline exceeded
Apr 5 21:16:16 compute9 docker: novassh_19767
Apr 5 21:16:16 compute9 systemd: Stopped Nova SSH Service.
Apr 5 21:16:16 compute9 systemd: Stopping Nova Compute Docker...
Apr 5 21:16:16 compute9 journal: *** Shutting down /nova_compute_start.sh (PID 8)...
Apr 5 21:16:17 compute9 journal: *** Init system aborted.
Apr 5 21:16:17 compute9 journal: *** Killing all processes...
Apr 5 21:16:34 compute9 docker: novacompute_19767
Apr 5 21:16:34 compute9 systemd: Stopped Nova Compute Docker.
Apr 5 21:16:34 compute9 systemd: Started Nova Compute Docker.
Apr 5 21:16:34 compute9 systemd: Started Nova SSH Service.
Apr 5 21:16:35 compute9 python: ansible-command Invoked with warn=True executable=None _uses_shell=False _raw_params=systemctl reset-failed removes=None creates=None chdir=None
Apr 5 21:16:36 compute9 python: ansible-systemd Invoked with name=docker-novacpu enabled=True daemon_reload=False state=restarted user=False masked=None
Apr 5 21:16:37 compute9 systemd: Stopping Nova SSH Service...
Apr 5 21:16:55 compute9 docker: novassh_19767
Apr 5 21:16:55 compute9 systemd: Stopped Nova SSH Service.
Apr 5 21:16:55 compute9 systemd: Stopping Nova Compute Docker...
::


更に事象発生時の sar のパフォーマンスデータ(/var/log/sa) を参照すると極端にメモリの使用量が多い状態となっていました。

 

12:00:02 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty
12:10:01 AM 3619824 391079936 99.08 120 2306984 24438216 6.16 11333180 4475276 36
12:20:01 AM 3623992 391075768 99.08 120 2308880 23992276 6.05 11328876 4475944 4
12:30:01 AM 3620360 391079400 99.08 120 2310916 23972384 6.04 11331012 4476628 8
12:40:01 AM 3608376 391091384 99.09 120 2312860 23989400 6.05 11343732 4477300 24
12:50:01 AM 3605648 391094112 99.09 120 2314864 23992316 6.05 11344972 4477944 16
01:00:01 AM 3603892 391095868 99.09 120 2316788 23965576 6.04 11346776 4478620 36
01:10:01 AM 3598628 391101132 99.09 120 2318580 24463420 6.17 11350448 4479264 36

 

12:00:02 AM kbswpfree kbswpused %swpused kbswpcad %swpcad
12:10:01 AM 68056 2029092 96.75 651928 32.13
12:20:01 AM 68056 2029092 96.75 651928 32.13
12:30:01 AM 68056 2029092 96.75 651928 32.13
12:40:01 AM 68056 2029092 96.75 651928 32.13
12:50:01 AM 68056 2029092 96.75 651928 32.13
01:00:01 AM 68060 2029088 96.75 651928 32.13


メモリの使用率が99%を超えており、更にSwapも96%程が使用されている状態となってます。
これは明らかにメモリに関連する問題が発生しており、OS上のプロセスがメモリ不足によりダウンしていると考えられます。


メモリの使用率を見てみると以下のように free のメモリが殆どない状況です。

$ free -g
              total        used        free      shared  buff/cache   available
Mem:            376         367           5           2           4           2
Swap:             1           0           1

 

"ps aux" コマンドでプロセスのメモリ使用率(RSS)をみてみてもメモリを使用しているプロセスはほとんどいません。

 

このような状況では HUGEPAGE メモリに関係する問題が発生している可能性があります。

このコンピュートノードのHUGEPAGEに関する使用状況を見てみます。

setup_data.yaml を参照すると、このコンピュートノードでは 2Mbyte のHUGEPAGEが100%割り当てられています。

 

# cat openstack-configs/setup_data.yaml
::
  compute9:
    cimc_info: XXXX
    management_ip: XXXX
    rack_info: XXXX
    sriov_tor_info: XXXX
    tor_info: XXXX
::
VM_HUGEPAGE_PERCENTAGE: 100
VM_HUGEPAGE_SIZE: 2M

 

このコンピュートノードのHUGEPAGEの使用状況を見ても20%程度しか使われていません。

 

[root@compute9 ~]# cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/free_hugepages
71562
[root@compute9 ~]# cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
89994
[root@compute9 ~]# cat /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages
89993
[root@compute9 ~]# cat /sys/devices/system/node/node1/hugepages/hugepages-2048kB/free_hugepages
71561

 

openstackのインスタンスが使用するHUGEPAGEがの設定を見直してみます。

 

通常であればこのコンピュートノードは全てのメモリが2MのHUGEPAGEで割り当てられているため、Instanceを起動する際には以下のように flavor に2MのHUGEPAGEを使用する設定を入れないといけません。

 

# openstack flavor show fl-2m |grep -e properties -e ram
| properties                 | hw:mem_page_size='2048', hw:numa_nodes='2' | 
| ram                        | 8192                                       |

 

2MのHUGEPAGEを使用するためには、properties に hw:mem_page_size='2048' の設定が必要となります。


しかしながら、実際にコンピュートノード上で動作しているインスタンスの flavor を確認してみると、HUGEPAGE を使用してない flavor が使用されていました。

 

# openstack flavor show fl-normal|grep -e properties -e ram
| properties                 |                                      |
| ram                        | 4096                                 |

 

CVIMで全てのメモリをHUGEPAGEに割り振ったとしても、OSのプロセスのために少量のメモリを4K byteのノーマルページのために残しておきます。


このため、このコンピュートノードではノーマルページを使用するインスタンスがいくつか立ち上がるとわずかに残されているノーマルページをインスタンスのために確保するため今回のようなメモリ不足の状況に陥ることがあります。

 

CVIMコンピュートノードにInstanceをデプロイする場合には、まず setup_data.yaml を確認し、HUGEPAGEの割合を確認した上で、適切な openstack flavor を使用する事をするようにして下さい。

 

関連情報

HUGE PAGE の使用方法に関しては以下のドキュメントをご参照下さい。

[CVIM] HugePage について

 

 

 

 

Getting Started

検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう

シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします