start

lang/php71とwww/mod_php71のZTSオプションは合わせないとハマる

FreeBSDでportsからPHP 7.1とmod_php71をインストールする際、それぞれのZTSのオプション設定を合わせておかないとハマる。というのも、ZTSの有無によってPHPエクステンションの読み込みパスが変わるからだ。

  • ZTS無効時:/usr/local/lib/php/20160303/
  • ZTS有効時:/usr/local/lib/php/20160303-zts/

エクステンションはlang/php71のZTSオプションに沿った場所にインストールされる。一方、mod_phpは自身のZTSオプション設定に沿った場所からエクステンションを読み込もうとするため、設定を合わせておかないとApache起動時に

Failed loading /usr/local/lib/php/20160303-zts/opcache.so:  Cannot open "/usr/local/lib/php/20160303-zts/opcache.so"

てな感じで怒られる事になる。

FRB (Fault Resilient Booting) について

うちのC2750D4IのイベントログにFRB2/Hang in POST failureってのが記録されててナンジャラホイ状態だったので、FRBについて調べた。イソテル様の資料に書かれてることを、かいつまんで訳しただけですけどね。

FRB1)とはBMC2)に実装されるシステムブート失敗時に別のプロセッサで起動を試みる仕組みで、レベル1~3が定義されている。

POST3)中に検出されたBIST4)の失敗からの回復が目的。全てBIOSのコードで処理される。

BSP5)がシステムを起動した際、初期化に失敗したAP6)があれば、BIOSはそのAPを無効化するようBMCに要求し、BMCはそれに応じたMP7)テーブルを生成する。無効化されたAPはBIOSからもOSからも見えなくなる。

BSPがBISTに失敗した場合、BIOSはBSPを切り替えるようBMCに要求する。BMCは現在のBSPを無効化し、別のBSPが見つかればシステムをリセットして処理を継続する。見つからなければ、ビープ音を鳴らしてシステムを停止させる。

POST中のウォッチドッグタイムアウトからの回復が目的。このウォッチドッグタイマーはBMCに実装される。

BMCの第2ウォッチドッグタイマー(FRB-2)は約6分にセットされ、システムのBIOS POSTの完了を保証するよう設計されている。FRB-2タイマーはFRB-3タイマー無効化の前に有効化され、未監視時間が発生しないよう考慮されている。POSTの終盤、オプションROMの初期化前に、BIOSはFRB-2タイマーを無効化する。

POST中にシステムがハングした場合、BIOSはタイマーを無効化せず、それによりBMCがASR8)を発生させる。

ハードリセットまたは電源投入時のウォッチドッグタイムアウトからの回復が目的。本レベル用にハードウェアの機能として備わっている。

第1ウォッチドッグタイマー(FRB-3)はシステムがハードリセットされた時からカウントダウンが始まり、通常は約5秒である。BSPのリセットが成功し実行が始まると、BIOSはFRB-3タイマーを無効化し、システムはPOSTを継続する。

BIOSコードのフェッチや実行がBSPの障害で行えずタイマーが切れると、BMCはシステムをリセットし失敗したプロセッサを無効化する。正常なプロセッサが見つからなければ、BMCはビープ音を鳴らす。


1)
Fault Resilient Booting
2)
Baseboard Management Controller
3)
Power On Self Test
4)
Built-In Self Test
5)
BootStrap Processor
6)
Application Processor。BSPに選定されなかったプロセッサ
7)
Multi Processor
8)
Asynchronous System Reset

裸族のインナーCRIN2535は15mm厚の2.5インチHDDでも使える

2.5インチSATA HDD/SDDを3.5インチ相当のネジ穴、コネクタ位置に変換するセンチュリーのマウンタCRIN2535は15mm厚の2.5インチHDDでも問題なく使える。公式には12.5mmまでの対応となっているが余裕ではまる。とりあえず、手持ちの15mm厚2.5“ HDD MQ03ABB300を入れてみた之図。

ご覧の通り、マウンター上端まではまだ余裕があるので、仮に17.5mm厚の2.5インチストレージとかが出ても収まりそう。そんなストレージ出ないだろうけど。将来、マウンタの仕様が変わって使えなくなったらメンゴ。構造的によっぽどの事がない限りは大丈夫だろうけど。

ついでにSupermicroのHDDトレイにはめてみた之図。

ばっちりでんな!……と言いたいところだけど、CRIN2535の側面の穴の位置が僅かにズレているようで、トレイへの取り付けがなかなかシビアだった。

初期型PS4 (CUH-1000)とPS4 Pro (CUH-7000)の消費電力比較

ひょんな事からPlayStation® 4 Pro (CUH-7000)に買い替えることになったので、発売日に買った初期型PlayStation® 4 (CUH-1000)との消費電力を比較してみる。ブーストモードはオフ……というか、計測したのはかなり前で、当時はまだ提供されてなかったのである。出力信号は1080p。うちに4kテレビなどというものはないのである。4kのプラズマはよ!(絶対に出ません

PS4
(CUH-1000)
PS4 Pro
(CUH-7000)
備考
電源オフ 0 0
スタンバイ 4~5 3 ・USB端子に給電する(3時間)
・インターネットに接続したままにする
・ネットワーク経由でPS4の電源を入れられる
・アプリケーションを一時中断したままにする
ホーム画面 76~81 63~65
FF15
プラチナデモ
タイトル 130 91~93
プレイ中 155 108 冒頭の湖のシーンが一番高かった。
ホーム画面戻り 103~113 74~82 PSボタン押下。裏でゲームが動いている状態。
torne メイン画面 95 70~72 ゲームは動かさずtorne単体のみ起動。
動画再生 101 73~76

 PS4とPS4 Proの消費電力比較

消費電力は概ね2割減ってとこですか。ブーストモードやPS4 Pro対応ソフトだと多分跳ね上がると思うケド…。

Samba 4.6のファイルコピーがCPU 100%近く使い超絶遅い件

この状態に悩まされてる人は何よりも答えが欲しいだろうから、最初に結論を書いておくと、smb.confでcase sensitive = yesと設定すると多分直る。直下に大量のファイルを抱えたフォルダをコピーするとsmbdがCPUを100%近く消費し、コピー速度が極めて遅くなる現象ならほぼ間違いなく直る。

(2018-07-03 追記)
case sensitive = yesの副作用を十分に考慮のこと。一例として、エクスプローラでは見えるファイルが、特定のアプリケーションでは存在しないファイルになるといった不具合が出るなど。詳細はこちら

「”大量のファイル”ってどれくらい?」かというと、サーバマシンの性能にもよるがCore i系なら概ね1万ファイル、流行りのラズパイとかだと恐らくもっと少数、単純なクロック比で1/2、実性能はもっと劣るだろうから更に半分で2500ファイルくらい?。完全な当てずっぽうですけど。要はファイル名の比較のところがボトルネックになっているようなので、CPUのシングルスレッド性能に依存する。

例によってNAS4Free 11.0.0.4 (4303)[FreeBSD 11.0-RELEASE-p10/Samba 4.6.4]でNASをでっち上げたのだが、知人曰く、今までのNASに較べてファイルコピーが遅い、と。マシンのスペック的にはXeon E5-2620v3, メモリ8GB, 1GbE×2のLAGで、ストレージも3.5インチHDD2本でRAID-1のペアを3ペアでRAID10なので問題が出るとは考えにくい。実際、シェルでのシーケンシャルライトでは500MB/sくらい出てる。

様々なサイズのテストファイルを試してみるも、至って正常な速度が出るし、むしろ他のNASよりも速いくらい。ところが、知人が遅いというファイル群で試してみると、たしかに遅い。小さなファイルが多いためワイヤーレートには程遠いが、それでも初速は10MB/s超えてるのに、あれよあれよと速度が落ちて仕舞には100kB/sを切ってしまう。そして何故かsmbdがCPUを100%近く持っていく尋常ならざる状態に。Pen!!!時代のGbEじゃあるまいし、たかがファイル転送でCPU 100%ってどんだけー。

問題のファイル群をシェルでcpすると30MB/s出てるので、やっぱりマシンに問題はなさげ。さらに、NAS4Free 9 [FreeBSD 9.3-RELEASE-p14/Samba 4.1.18]搭載の別マシン(Xeon E3-1225v2/16GB/3.5“ HDD 6台でRAID-Z2なので性能は必要十分)で試すと、安定して数MB/sは出るし、CPU負荷も常識的な範囲。となれば、問題なのはSambaっぽい…?

ここまで絞り込んでからが大変だった。

情報がないない。マシンの省電力設定を切ってみたり、Sambaが速くなる各種おまじないを試してみたり、SMBのプロトコルバージョンを変えたり、LAGを解除してみたり、etc…するも効果なし。ググりにググって、ようやくFreeNASのフォーラムでcase sensitiveが原因じゃねという投稿を見つけた次第。

早速case sensitive = yesにして試してみたら、効果てきめん。転送速度もCPU負荷も劇的に改善された(テストファイルが32kBなので速度がそんなに出てないのは仕方ない)。論より証拠ってなもんで、比較画像貼っておきますね。

 Samba 4.6.4のcase sensitive設定によるファイルコピー速度の比較

その後、Sambaのドキュメントのcase sensitive設定のところを見たら、思いっきり「As a special case for directories with large numbers of files, if the case options are set as follows, “case sensitive = yes”, (後略)」と書いてあったでござる(´・ω・`)。

大文字小文字の変換処理ごときで遅くなるなよ!と思わなくもないが、ファイルの新規作成時はディレクトリ内の既存ファイル名と被ってないか総当りでチェックしているようなので、何も考えずに実装すれば計算量はO(n/^2^/)、ファイル数が増えると爆発的に比較数が増えるんすなぁ…。にしてもですよ、デフォルト設定のcase sensitive = autoは以前のバージョンから変わってないわけで、いきなり遅くなるなんてチョーひどくなーい?

case sensitive設定を変えるとWindowsからのアクセスに支障がでないか心配なところだが(なんたってWindowsは表面上は大文字小文字区別しませんからね!)、/-そこはエクスプローラが上手いこと取り計らってくれる模様。本当かどうかは知らない。-/ → (2019-05-19 追記)取り計らってくれなかった。例えばa.txtとA.TXTがあった場合、どちらのファイルを見に行くかは半固定。一度決まった同名ファイルのアクセス先は固定されるが、それらファイルを含むディレクトリの内容が変わるとアクセス先の選定が再度行われ、その結果は不定ってのがWindowsの昔からの仕様らしい…。

(2018-07-03 追記)
再度の注意。アプリケーションによっては意図しない挙動が発生するためcase sensitive = yesでの運用は十分なテストを行うこと!

  • start.txt
  • 最終更新: 2022-07-27 15:26
  • by Decomo