投稿

2026の投稿を表示しています

MariaDB serverを10.11から11.8にアップグレード

MariaDB serverをアップグレードしたときの覚書。 Gemini 3 Pro Previewと対話。 環境: FreeBSD 14.3-RELEASE-p7 1. MariaDB 10系と11系の違い 主にWordPressを複数運用するウェブサーバー向けにGemini先生にまとめてもらった。 オプティマイザ(頭脳)の刷新 : 11系ではSQLの実行計画を決めるロジックが「コストベース」に完全刷新されており、複雑な商品検索(WooCommerce等)が高速化する可能性がある反面、統計情報が古いと単純なクエリでインデックスを使わなくなるなどの「判断ミス」による急激な速度低下リスクが高まっている。 書き込み性能の向上: 11系は内部的なログ処理(Redo Log)が改善されており、複数のWordPressサイトから同時にアクセスや記事更新が発生するような高負荷時のディスクI/O効率が良く、書き込み待ちが起きにくくなっている。 サポート期間と安定性: 10.11は「旧設計の完成形」として2028年2月までサポートされる最も枯れた安定版(LTS)ですが、11系は新設計のため挙動が異なり、現在のLTSは11.4となっている(11.8は将来のバージョン)。 古いプラグインの互換性リスク: 11系では古いMySQL時代から残っていた非推奨機能や曖昧な設定が削除されているため、長年更新されていない古いWordPressプラグインがエラーを起こして動作しなくなる可能性が10系より高い。 JSON処理の高速化: 最近のWordPressプラグインやブロックエディタが多用する「JSON形式」のデータ処理能力が11系で強化されており、関連する処理が軽くなる傾向がある。 統計情報管理の厳格化: 11系の新オプティマイザはデータの「統計情報(件数や分布)」に非常に敏感なため、アップグレード後や記事大量追加後に ANALYZE TABLE を実行して情報を最新に保たないと、10系よりもパフォーマンスが劣化しやすくなる。 メンテナンス性の向上: 11系はテーブル構造の変更(Instant DDL)機能が強化されており、巨大なテーブルへのカラム追加などを、サービスを停止させずに瞬時に行える範囲が広がっている。 リソース効率: 11系の方がメモリ管理や一時テーブルの扱いが効率...

pkg: sqlite error while executing grmbl in file update.c:154: NOT NULL constraint failed: packages.path

pkg updateで突然下記エラーが出るようになったときの覚書。 Gemini 3 Pro Previewと対話。 環境: FreeBSD 14.3-RELEASE-p7 arm64 (Mac mini上のVMware Fusion仮想マシン) 1. pkgエラー発生 エラーの内容。 # pkg update Updating FreeBSD repository catalogue... Fetching meta.conf: 100%    179 B   0.2kB/s    00:01 Fetching data.pkg: 100%   10 MiB  10.4MB/s    00:01 Processing entries:  99% pkg: sqlite error while executing grmbl in file update.c:154: NOT NULL constraint failed: packages.path pkg: sqlite error while executing grmbl in file update.c:154: NOT NULL constraint failed: packages.path pkg: sqlite error while executing INSERT OR REPLACE INTO packages (origin, name, version, comment, desc, arch, maintainer, www, prefix, pkgsize, flatsize, licenselogic, cksum, path, manifestdigest, olddigest, vital)VALUES (?1, ?2, ?3, ?4, ?5, ?6, ?7, ?8, ?9, ?10, ?11, ?12, ?13, ?14, ?15, ?16, ?17) in file update.c:158: not an error Processing entries:  99% Unable to update repository Fre...

PHPのCacheToolをインストール

AIにサーバー稼働状況を分析レポートとして報告させるバッチを作成しているときの覚書。 Gemini 3 Pro Previewと対話。 環境: FreeBSD 14.3-RELEASE-p7, PHP 8.3.23, CacheTool 10.0.0 PHP OPcacheの統計情報を下記コマンドで取得できるかと思ったけど、PHP-FPMで実行されるOPcache統計情報ではなくPHP CLIのOPcache統計情報だった。 # php -r 'print_r(opcache_get_status(false));' 2>/dev/null ちゃんとPHP-FPM経由で「opcache_get_status」を実行させる必要がある。 opcache-guiをインストール済み。 これをcurlコマンドで読み取っていいと思う。 参考:  amnuts/opcache-gui: A clean, effective and responsive interface for Zend OPcache CacheToolというツールをGemini先生にお勧めされたのでインストールしてみた。 1. CacheToolをインストール Phar 拡張モジュールをインストール。 # pkg search phar # pkg install php83-phar 公式ドキュメントの通りにインストール。 参考:  CacheTool - Manage cache in the CLI | cachetool # curl -sLO https://github.com/gordalina/cachetool/releases/latest/download/cachetool.phar # chmod +x cachetool.phar /usr/local/bin に移動しつつ、名前を 'cachetool' に変更。 # mv cachetool.phar /usr/local/bin/cachetool 確認。 # cachetool --version CacheTool 10.0.0 2. OPcache統計情報を取得 コマンドリストを表示。 # cachetoo...

PHP APCuをインストールしてWordPressのobject-cache.phpを配置

PHPのAPC, APCu, OPcacheに関しての知識を整理したときの覚書。 Gemini 3 Pro Previewと対話 環境: FreeBSD , PHP 8.3.26, WordPress 6.9.0 1. APCuとは? APCu は、PHPで動くインメモリの key-value ストア。 APCu(APC User Cache) は APC(Alternative PHP Cache)からOPcach機能を除いたもの。 参考:  PHP: はじめに - Manual APCからAPCuになるまでの経緯 PHP 4.x 〜 PHP 5.4: APCがOpcode Cache(コードのキャッシュ)とUser Cache(データのキャッシュ)の両方の機能を担う。 PHP 5.5: 2013年にコードのキャッシュ(Opcode Cache)はPHP本体に標準で組み込まれる。 PHP 5.5以降 : APCから不要になったOpcode Cache機能を削除し、User Cache機能(データ保存)だけを切り出して軽量化・最新化したAPCuへ。 サーバーをクラスター構成で運用している場合は、ValkeyやRedisを利用する。 ValkeyやRedisを使うよりAPCuの方が通信のオーバーヘッドがないので圧倒的に高速。 2. APCuとWordPressの関係 WP_Object_CacheとWP Transients APIの関係。 WP_Object_Cache: ページ生成中の一時的なデータ保持。 スレッドメモリに保存しページ表示後に破棄される。 APCuを導入すると共有メモリに保存しページ表示後に破棄されず再利用可能。 WP Transients API: 有効期限がある長期間のデータ保持。 データベース(wp_options)に保存。 APCuを導入するとWP_Object_Cache経由でデータ取得保存するようになる。 object-cache.phpはWP_Object_Cacheクラスを上書きして、データを保存する際にapcu_*関数を使って共有メモリに保存する。 WordPressはwp-includes/load.php:wp_start_object_cache()でobject-cache....

One-Hot エンコーディング/疎行列/コサイン類似度/協調フィルタリング/共起

病院施設基準のデータ分析をGemini先生と対話している中で分からない単語を調べているときの覚書。 Gemini 3 Pro Previewと対話。 機械学習(特にレコメンデーションシステム)の基礎。 One-Hot エンコーディング データベース上の「回復期リハビリテーション」といった文字列のままでは、数学的な計算(類似度の判定など)ができない。 そこで、病院を「行」、施設基準を「列」とする巨大な表を作り、持っている場所に「1」、持っていない場所に「0」を立てる。 これで数学の問題として計算できるようになる(ベクトル化ともいう)。 参考:  カテゴリデータ: 語彙とワンホット エンコーディング  |  Machine Learning  |  Google for Developers 参考:  One-hot - Wikipedia 疎行列(sparse array) 疎行列(スパース行列/sparse array)とは、要素のほとんどがゼロで構成される行列。 One-Hot エンコーディングを行うと「0」ばかりの巨大な行列になる。 「0」をすべてメモリに乗せるのは無駄なので、「どこに『1』があるか(行番号, 列番号)」だけを記録する形式をCSR形式(Compressed Row Storage)と呼ぶ。 参考:  疎行列 - Wikipedia コサイン類似度(Cosine Similarity) 2つのベクトル(矢印)が、どれくらい同じ方向を向いているかを測る指標。 まったく同じ方向を向いているときに最大値1になるのでコサイン(cos)を使う。 サイン(sin)とタンジェント(tan)は0になる。 参考:  コサイン類似度 - Wikipedia ちなみにサインは(sin)は「どれくらい離れているか(距離)」。 タンジェント(tan)は傾き を計算するときに使う。 協調フィルタリング(Collaborative Filtering) 「あなたと似た人は、これも持っています」という推薦アルゴリズム。 Amazonの「この商品を買った人はこんなものも買っています」や動画サイトの「おすすめ」機能などで広く使われている。 あるユーザと嗜好の類似した他のユーザの情報を用いて自動的に推論を行う...

AIでサーバーの稼働状況分析レポート

サーバーのパフォーマンス情報をAIに与えて、稼働状況レポートをCronでメール報告させようとしたときの覚書。 Gemini 3 Pro Previewと対話。 環境: FreeBSD 14.3-RELEASE-p7 このサーバーは主にWordPressウェブサーバー。 1. サーバー情報の収集 収集するサーバーのシステム情報一覧 systat(パフォーマンス統計情報) 参考:  FreeBSDのsystatとcollectdでリソース情報を取得 collectdで収集した情報 参考:  FreeBSD14 + collectd + RRDtoolをportsからビルドしてインストール Nginx VTS (Virtual Host Traffic Status) 参考:  NginxのVTSモジュール でパフォーマンス分析(Netdataのインストールは失敗) OPcache GUIの情報 参考:  FreeBSD14 + PHP8.3 + OPcache ファイヤーウォール(pfとfail2ban)のログ情報 参考:  FreeBSD14 + Nginx + fail2banで不正なアクセスを自動ブロック MariaDBのパフォーマンスViewとslow_log 参考:  MariaDB Serverのチューニング設定(2025年8月版) PHPのエラーログとphp-fpm-slow.log 参考:  FreeBSD14 + Nginx + PHP8.3 + WordPress 6.8.2で起きた原因不明のPHPエラー /var/log/maillogと/var/log/messages 2. Cronジョブ生成 Gemini先生と対話してシェルスクリプトを生成。 必要なツールをインストール。 jqはJSONのコマンドライン処理ツール(デフォルトでインストール済みだった)。 # pkg install bash curl jq Gemini先生へ渡した初期プロンプト 生成AIにサーバーの稼働状況の情報を与えて、分析レポートをCronで毎日報告させるバッチを考えています。 収集するサーバー情報が増えてもメンテナンスしやすいシェルスクリプトを教えてください。 環境: FreeBSD...