Raspberry Pi 4しばらく登板 (3)

Raspberry Pi 4 Model B RAM 4GBでまる4日ほど運用しました.定量的なデータは何もありませんが,LAN内のクライアント1からのアクセスでは,レスポンスがSlackware ARM 32bit時よりも少し改善された感じはしました.

ただし,写真のupload時の処理時間に大差はないです2

今回は,同じRaspberry Pi 4 Model Bですが,RAM 8GBのものに置き換えました.RAM 4GBだと定常的な運転状態でswap (ZRAM)が500MB前後になります3.8GB RAMではswapが実質的にゼロなので,差は出ると思います.

Redis Object Cacheの反応時間,最大のピークは90 ms

このRedis Object Cacheの反応時間のグラフの中央 (16:35) あたりの大きなピーク(90 ms)はハードウェア交換直後に複数のdaemonが起動したため反応時間が大きくなったと推測できます.このピークの前がRaspberry Pi 4 Model B RAM 4GB,後が同8GBです.反応時間の平均的な値は小さくなっているように見えます.

この状態でまたしばらく運用してからRaspberry Pi 5に戻します.

  1. M4 Mac mini, MacBook Air M4など. ↩︎
  2. Uploadした写真をWordPressのシステムがいくつかのサイズに作り直します.当然写真によりますがだいたい16秒前後処理時間がかかります. ↩︎
  3. ZRAMは1GBに設定しました. ↩︎

プチフリーズはたぶん解決してない (2)

プチフリーズというか,Core Spotlight daemonとPagesが連携してMetadataフォルダーを肥大化させる件について,今回Geminiに聞いてみました.

そうしたら,もう1人役者がいるそうで,それはiCloudです.iCloudがPagesのファイルの編集履歴を保存することとCore Spotlight daemonの連携にバグがあって無限にインデックスを作るようです.

iCloudにApple製アプリのファイルを保存するのは具合が良いのですが,この際他の場所に置いてみることにしました.

問題になっているM4 Mac miniのローカルSSDにおいても良いのですが,Google Driveに置いた方が他のMacから編集するのに楽なのでそうしました.

まだ数時間しか経っていないので,Metadataフォルダー内のCore Spotlightのフォルサイズは130MBと常識的な範囲内です.

前回のぬか喜びを反省して,1週間くらいはこのままで運用しようと思います.

Raspberry Pi 4しばらく登板 (2)

Raspberry Pi 4 (RPi4)で運用し始めてまる2日経過しましたが,問題は特にないです.WordPressの反応もSlackware ARM (32bit)で運用していたときより速い感じがします.

Fail2Banも着実に排除するIPアドレスを増やしていってます.

また,GUIがそれなりに動くのはいいです.Firefoxが使えるので,記事を書いたり修正するのも楽です.

Slackware ARM (32bit)でもKDEが動くのですが,ちゃんと動くWebブラウザーがないのが残念なところでした.KDE自体も重かったです.

その点Raspberry Pi OSの標準であるPIXELは軽量でいいです.

RAMは4GBでちょうどいい感じです.しばらくLAN内で続けて動かしている旧サーバーはRAM 8GBで,これももったいないのでいずれ入れ替えようと思います.

Orphan

以前経験したのに忘れてしまっていました.

サーバーをSlackware ARM 15.0からRaspberry Pi OS 13.3に切り替え,古いサーバーのデータなどを整理していたら,総容量が200GB程度まで減りました.

今まで1TBのSSDをつないでいましたが,半端な容量で使い道のない250GBのSSDがありこれに引っ越すことにしました.1TB SSDも空きます.

作業はManjaro AMD64 (x86_64)で行います.fdiskでGPTのパーティションを切り,mkfsでブート用のvfatとルートのext4をフォーマットします.

これが落とし穴で,Manjaroでフォーマットしたext4はSlackware 15.0では認識されないのです.

2回,コピーしてブートしてくれないので,インターフェースが悪いのかSSD自体が悪いのかなど悩みましたが,ManjaroでフォーマットしたボリュームはSlackwareでは読めないことを思い出しました.

このBLOGにもそれに関する記事があるはずですが今回見つけられませんでした😓

Geminiに聞いてみたら,古いKernelでは最新のmkfs.ext4のデフォルトでフォーマットしたボリュームはtoo newでマウントできないんだそうです.

回避策としては,

mkfs.ext4 -O ^orphan_file,^metadata_csum_seed /dev/sdXN

とします.あるいはSlackware上でフォーマットすればよいのです.

しかし,このような後方互換性のない新機能というのもちょっと困ったもんです.名前をext5にしてくれていればまだ分かりやすいものを.

Raspberry Pi 4しばらく登板

Raspberry Pi 5 (RPi5)による新サーバーの運用もだいたい目鼻がつきました.ここでいったんRPi5からRaspberry Pi 4 Model B (RPi4)にサーバー担当を交代しました.

実はこれが一番やりたかったことで,これまで,32bit OSのSlackware ARM 15.0をRPi4で動かしてきましたが,同じハードで64bit OSだとどれくらいパフォーマンスが違うのか,ということです.

ChatGPTによればArmv8では,64bit OS/アプリと32bit OS/アプリでそれほどパフォーマンスに目だった差はないとのことです.

Slackwareの頃のWordPressプラグインRedis Object Cacheのグラフを取っておけばよかったのですが,探したらありませんでした😓

これが,先ほどWordPressをRPi5からRPi4に切り替えたRedis Object Cacheの反応のグラフです.

Redis Object Cacheの反応時間.最大のピークは60 ms

最初の大きなピーク(60 ms)あたりがRPi4の起動したタイミングです.その前はRPi5ですから,両者の性能の差が顕著に出ています.たぶん,RPi4をSlackwareARMで動かしてきたときもこんなもんだったと思います😓

今回の件についてはChatGPTの言うことは正しかったようです.残念です.