httpsのnssがslabを大量に使うからswapが発生する件が依然解らない

ここ数年解らなかった,httpdを動かしているとメモリーの空きがなくなり,swapが発生してシステムのレスポンスが悪くなる件ですが依然としてよく解りません.

RAM 4GB版のRaspberry Pi 4 Model B (RPi4)を起動すると,半日くらいで空きメモリーを使い切り,kswapd0が働きだし,zramが消費されはじめます.

ファイルやパーティションを使うswapをやめてzramにしたのは,httpdサーバーが主な仕事のこのマシンにしてみれば,対象療法にはなっている訳です.

一方,予備機としてRAM 8GB版のRPi4もあり,いろいろなテストの目的でときどき入れ替えて使用していますが,4GBのRPi4と比較すれば、起動直後の空きメモリーに4GBが加算される形になるので余裕があります.こちらは半日動かしたくらいでは5GB以上メモリーに空きがあります.

これが不思議なんですが,8GBで5GB以上余裕があるなら,4GBでも1GB余裕があっていいはずなんですがそうはならないのです.

しばらく4GBと8GBをとっかえひっかえしながら様子を見てみることにします.

これまで試して効果がなかったこと

  • export NSS_SDB_USE_CACHE=YESとしてhttpdを起動する
  • export TMPDIR=/dev/shmとしてhttpdを起動する
ファンが故障してパッシブになったケースに,余っていたヒートシンクをはり付けてみましたが,効果は限定的です.同じ条件でCPUの温度が1〜2℃下がる程度です(記事と写真は関係ありません).

「httpsのnssがslabを大量に使う」当サイト内の関連記事

NSS_SDB_USE_CACHE=YES

某サーバーはメモリーが4GBと8GBの主副のRaspberry Pi 4 Model B (RPi4)をときどき入れ替えて,運用しています.

4GBのほうでは気がつくとkswapd0が大汗かいてます.8GBではそういうことはありません.

httpdを再起動すると,いったんかなりのメモリーが解放されますが,また何時間か経つと,kswapd0が大汗かいてます.zramを使用しているので,ファイルやパーティションをswapのメディアにしているときよりは,レスポンスはいいですが,それでも,何かコマンドを打ち込んでも反応するのにちょっと時間遅れがあります.

ずっと原因がわかりませんでしたが,https接続でphpが動いてlibcurlが動くと,nssがslabを大量に使うのが原因のようですということらしいです,って聞いても何が何だか解りません😓

下記参考ページにあるように,ときどきslabを開放してやるのがひとつの解法のようですが,根本治療は,

export NSS_SDB_USE_CACHE=YES

もしくは,

export TMPDIR=/dev/shm

のどちらかを “どこか” で実行することのようです.当該サーバーの場合どこで実行すれば良いのか解らないので,しばらく試行錯誤します.

参考ページ

「httpsのnssがslabを大量に使う」当サイト内の関連記事

RPi3でRTSPを見る: Reboot 6 また難航

RPi3でRTSPを見る: Reboot シリーズは,まとめちゃったんですが,完了していません.

まずどうでもいい話からですが,Raspberry Pi 3 Model B (RPi3)と同+ (RPi3+)を持っているので,専用電源も2つあったはずなのに1つ見つかりません.

いろいろ探しても見つからないので,強制空冷のケースと一緒に某通販サイトの出店者に注文しました.なんか,買ったら出てきそうな予感はしていました.

実際その予感は当たりました.買う前にいろいろ探したつもりですが,新しい電源が届いた数日後,全くありそうもなく探していないところから出てきました.

Raspberry Pi 3用のACアダプター

写真の左がその「出てきた」RPi3(+)専用と銘打たれていた5V3AのACアダプターで,プラグはMicro USBです.

右が今回買ったもので,5V3AのUSB電源です.これに,中間スイッチの付いた,Micro USBのケーブルが付いてきました.そのままほったらかしておくと,いくつもある普通のUSBアダプターと紛れてしまうので, “RPi3用” とテプラを貼っておきました.USBアダプターなので,USB-Cのケーブルを使えばRaspberry Pi 4 Model Bにも使えますし,もちろんその他のUSB機器にも使え,まあつぶしがきくので良しとします.

さて,このプロジェクトが難航というか頓挫している最大の理由は,Real Time Streaming Protocol (RTSP)の動画を流すカメラの故障です.

買ったときからあんまり調子が良くなくて,新しいfirmwareが発表される度に今度は良くなると期待していましたが,裏切られ続けてきてます.

最新のfirmwareが最悪で,8月14日に接続が途切れてから,何度電源リセットをしても,接続先のルーターのリスタートをしても,接続が復帰しません.

一昨日から,電源を完全に切っています.心証として,暑い時期のほうがより調子が悪いので,少し涼しいときに電源を入れて初期化して再設定してみます.

それでだめ(たぶんだめ😓)なら,もう1台同じものを買うか,別のものを探すか迷っています.

パッシブか強制空冷か

いま,Raspberry Pi 3 Model B+(RPi3+)は,アマゾンの出店者から買ったヒートシンク一体型のケースを使用しています.ファンの付いてないパッシブな冷却です.

CPUの温度が50℃くらいの時,ケースの温度は40℃くらいです.

gkrellmによるCPUの温度表示
ほぼ同じ時刻(条件)におけるケースの表面温度

パッシブなヒートシンク一体型ケースのメリットとしては,

  • 確実に冷える
  • ファンなどの故障によるオーバーヒートの心配がない

等が主なところです.逆にデメリットは,

  • Wi-FiもBluetoothも弱い

です.全体をアルミで囲っているわけですから,当然と言えば当然です.Wi-Fiルーターの近くでいじることが多いので,ネット接続のほうは問題にはなりませんが,Bluetoothはキーボードがしばしば切断してしまいかなり支障をきたしています.

また,ケースを触ったとき,思ったより暖かいのになかなか慣れません.冬だと気持ちいいのかもしれません.

そんなこんなで,冷却装置を見直し中のRaspberry Pi 3 Model B (RPi3)のほうは,樹脂製のケースに大きな穴が開いていてファンで排気するオーソドックスな空冷ケースを購入することにしました.発熱するチップにはそれぞれおもちゃみたいなヒートシンクを貼り付けます.

お盆休みを挟んでしまったので,到着するのが1週間ほど先になりました.

RPi3でRTSPを見る: displaycamerasはNG

当初の目的は,遊んでいるRaspberry Pi 3 Model B (+)で,監視カメラのReal Time Streaming Protocolの画像を見る,なんですが,Manjaro ARMのKDE Plasma DesktopをインストールしてVLCを動かす,と,個人の嗜好に思いっきり引きずられてしまいました😓

シンプルに, “RPi3でRTSPを見る” という目標へ一番近そうなのは, GitHubの “displaycameras” を試してみる,だと思うので今度はそれをやってみます.

インストール不可

一言で言えば,「古すぎて話にならない」です.

displaycameras自体,3年も前のalpha版が放置状態です.そのdisplaycamerasがRTSPを見るために使うのがomxplayerで,こちらはさらにその数年前に開発が止まってます.サイトのREADME.mdの冒頭には,

Note: omxplayer is being deprecated and resources are directed at improving vlc.

とあります.そう,今日的には,RTSPを見るのにVLCを使うのは一番正しい選択です.そのVLCのRTSPが,Debian系で機能を止めているのだから,やはり,Debian系以外のdistroを使う,というのはこれまた正しい選択でした.

もう一つ選択肢があるとしたら,Raspberry Pi OS上で,自分でVLCをbuildする,ということになりましょう.