Category: Linux

Re: httpsのnssがslabを大量に使うからswapが発生する件が依然解らないまま解決した模様

2022年11月2日の「httpsのnssがslabを大量に使うからswapが発生する件が依然解らないまま解決した模様」ですが，その後も安定して，メモリーが空いています．

Slackware ARM for Raspberry Pi 4 Model B 15.0 (32bit)の話です．

11月2日よりあとに，WordPressにRedisクライアントをインストールしたりして，httpdのそれぞれのスレッドの占有するメモリーはかなり増えましたが，起動してから一週間経っても “avail Mem” は2GB以上空いていますし， “free mem” も1GB以上空いていて， “Swap” はほとんど使われていませんから余裕です．

ということでKernelのバグだったと言うことで間違いないと思います1仕様だったのかも知れませんが😓 あくまで “当社調べ” です．．

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

新しいタブレットをどうするか

WACOMはドライバーのupdate/upgradeで古いモデルをサポートしなくなります．これまでもそのことで何度か買い換えを余儀なくされました．

タブレットの利用は絵を描くのではなくマウス代わりなので，小さい方が手を動かす範囲が狭く都合が良いので，現行モデルで買うとすると， “Intuos small ベーシック USBモデル” ないし， “One by WACOM small” です．これらを買うのはやぶさかではないのですが，最新のWACOMタブレットを買うと，X.orgやLinux Kernelのドライバーがサポートしていない，という問題に遭遇します．

X.orgとLinux Kernelがサポートしている少し古いタブレットを探し出して買えばKVMスイッチに繋がっている全てのPC/WSで使えますが，古い分早くWACOMに見切られます．

少し考えます．

httpsのnssがslabでswapの問題が解決したところでWordPressの対策をしたらメモリー使用量が増えた

そんなわけで，Kernelのupdateをしたらnssがslabでメモリーを大量消費する問題が解決しました．

それとは別に，WordPressのパフォーマンス改善のために，Page cacheとRedisを導入したところ，httpdの使用メモリーがかなり増えました．

従前は1スレッドあたり6%弱くらいでしたが，現在は1スレッドあたり8%弱です．1スレッドあたり2ポイントくらい増えてますから，

4096 x 0.02 x 4 ≅ 330MB

ということで，コンベンショナルメモリーを330MB位余計に食うようになりました．

それでも，そのhttpsのnssがslabでメモリーを消費する問題が解決したので，swapを使う事は今のところないです．

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

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

Slackware ARM 32bit版 for Raspberry Pi 4 Model B (SARPi4)の話です．

Raspberry Pi 4 Model B (RPi4) 4GB RAMでGUIなしのサーバーを仕立ててますが，起動してから半日くらいでメモリーが使い果たされてSWAP領域を数百MB使います．ZRAMを導入してからはずいぶんレスポンスが良くなりましたが，SWAPを使わないに越したことはないです．

当該サーバーではhttpd (Apache 2.4.x)の4つのthreadがそれぞれ5%前後のメモリーを使います．多めに見積もって6%として，

4GB x 0.06 x 4 ≅ 1GB

ですから，メモリーを食い尽くすはずはないのですが，半日でSWAPを必要とします．

その原因についてslabがなんだかんだという記事を見て，そういうことなのかなと思いつつも，関連記事のおまじないを試しても何の効果もないので納得いきませんでした．

昨日，Kernelを5.19.15-v7l-sarpi4にupdateして，まる一日が経過しましたが，まだ1.9GB主記憶に空きがあり，SWAPを必要とする気配は全くありません．

ということで，Kernelのバグだったんじゃないかと思います（個人の感想です）．

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

使ってもいないDebian上のmysqldを動くようにした

とあるDebianのサーバーで，mysqldというか実態はMariaDBのデーモンですが，それがなかなか動いてくれなかったのを動くようにしました．

問題は，/runからもはや/var/runへsymlinkが張られていなくて，それぞれ実体のあるディレクトリーとなっているのに，mariadb.service内では，/var/run/mysqldを使い，/etc/mysql/mariadb.cnfでは/run/mysqldを参照しているためのようです．

他のDebianのマシンでは，/var/runは/runからのsymlinkなので，何かの手違いで，/var/runと/runを独立させてしまったようです．

システムが活きたまま，/var/runを/runからのsymlinkに修正するのはちょっと危険ですね😓

と，いいつつ，やってしまいました．

cd /var/run
cp -Rdvp * /run
cd ..
mv run run-save
ln -s /run

今のところ問題ないみたいです．