BLEデバイスのゲートウェイとして利用しているRaspberry Pi4がデータを送信しなくなる不具合が発生。電源を再度オフ＆オンしても数日すると再発という状況。
原因はラズパイのLxPanelのメモリーリークだったので原因特定にいたった過程と対処方法をご紹介します。
機器構成
使用機材は下記の通り。
- サーバー：Raspberry Pi4G（２G)
- LTEモデム：Soracom Onyx – LTE™ USB ドングル (SC-QGLC4-C1)
- SIM：Soracom Plan-D300
- BLEセンサー：温湿度計を１０台程度
ラズパイにLTE USBドングルを差し込みSoracomのPlan-D300を使ってクラウドに送っております。
Soracomコンソール セッション詳細
Soracomコンソールからセッション詳細を確認。
イベントとして、Deletedが発生しており、その後、接続が復活することなく、再度、ラズパイをリセットしないと復帰できない状況でした。
ラズパイの状況をGrafanaで記録
ゲートウェイでは、 node-red-contrib-cpu と node-red-contrib-os を使ってゲートウェイの状態を取得することができます。
Grafanaで推移を確認すると、CPUメモリ使用率（赤）が100%になり、その後、データが落ちていることが確認できました。
SSHで接続 TOPコマンドで確認
sshでゲートウェイに接続し、topコマンドで確認したところ、lxpanelというプロセスが他よりも多くのVIRT(仮想メモリサイズ Virtual Memory Size）を消費しているのが確認できました。
つまり、このVIRTが100%になることでゲートウエイがフリーズして、通信が切断されている可能性が高いことがわかりました。
もともとlxpanelは毎日3時に再起動するcronを動かしていたのですが、その頻度を上げることにしました。
1時間に1回 lxpanelを再起動するcronを設定
corntabを編集します。
今は毎日3時に再起動しているので
0 * * * * export DISPLAY=":0.0" && lxpanelctl restart
このように、1時間に１回、再起動するように設定しました。
結果
結果、データ送信がされない不具合は再発しなくなりました。
GrafanaでCPUメモリ使用率（赤）を確認すると、
ー 昼間になると使用率が上がる
ー 平日の昼間は上がるが、土日は上がらない
ということから、設置した空間の使用人数が増えるとCPUメモリ使用率が上がることがわかり、おそらく、BLEデバイスが増えたことで、BLE Scan自体のメモリ負担が増えてくるのではないかと考えました。
まとめ
以上、弊社が経験したSoracomのLTE通信で現場BLEデバイスのデータを送るゲートウェイがデータ送信できなくなる問題について、原因の解明プロセスと解決方法をご紹介しました。