Month: November 2022

家族が増えました

人間の家族に異動はないのですが，家族が一匹増えました．

私ではない家人が直接の飼い主ですが，まだ赤ん坊の犬なので家人が不在のようなときは私がめんどうを見ます．

まだ予防注射を受ける月齢ではないので，外の散歩はできませんが，順調に育って注射を受ければときどきは散歩の担当になると思います．

WordPressの問題2つ解決

SlackwareARM 15.0 (32bit) for Raspberry Pi 4 (SARPi4) の話です．

WordPressを6.1にしたところ，健康がこれまで “Good” だったのに， “Should be improved” に変わりました．

Criticalなのは，page cacheがONになってないということです．ざっと調べたらその操作をするプラグインがあるとのことです．確かに多数ありますが，ここでふと感じたのは，こんなにたくさんあるということは，プラグインではそんなに高度なことをやっていないなということです．

とりあえず一つのプラグインをインストールして， “Page Cache” のスイッチをONにしようとしますが，permissionが何たらかんたらでONにできないと言ってきます．

その後多少調べたら，wp-config.phpのpermisionがhttpdデーモンからいじれないようになっていましたので修正したら， “ON” にできました．

このプラグインが何をしているかというと，wp-config.phpに，

define('WP_CACHE', true);

を追加しているだけです（とこの時点では思いましたが間違いなので，続きを読んでください）．

それならということで，2つめのサイトでは，手でwp-config.phpを編集してから，Dashboardを開いたら，ページキャッシュに関するcriticalな警告は出ませんでしたが，よくよく見るとやはり効果はないようです．プラグインをインストールして，Page CacheをOn にした場合median server responsは20〜30msになりますが，wp-config.phpに，上記の定義を追加しただけでは，600ms弱となります（600ms未満なので， “Critical” にはならない）．

ということで，なんらかのPage Cache制御のプラグインは必要です．

とりあえずの形でインストールしたのは，次のプラグインです．

WP-Optimize – Cache, Clean, Compress.

2つめの解決は，これはかなり前からなんですが，imagickというplug-inがないという問題で，これはプラグインでもWordPressのものではなくて，phpのものです．

Debianなどには普通に付いているようですが，Slackwareは付いてこないのです😓

しかし，SlackBuildsにあったので，sbopkgでbuild & installできました．なんでこんな簡単な解決策があるのに，これまでやらなかった，というか解決できなかったのか解らないです😓

筆者は管理画面を英語モードで運用しています．これは，トラブルが生じたとき検索して解決策が見つかる確率が日本語よりもはるかに多いためです．また，英語を使う機会が減っているのでそれを補う意味も多少あります．この記事内ではそうした事情から元の英語をそのまま書いたり，面倒くさくて意訳で書いてますので，日本語の管理画面の文言と異なる場合があります．
6.0.3まで．
筆者の使っているplug-inでは，先頭の <?php の次の行に追加しています．

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

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