Claude Codeでプロンプト1発、MariaDBのメモリ使用量を400MB→150MBに削減した話

きっかけ#

自宅サーバでWordPressを2サイト運用している。PaaS基盤にはCoolifyを使っていて、データベースにはMariaDB 11.7を採用している。

ある日、コンテナのメモリ使用量を確認したところ、MariaDBが約400MBも消費していることに気づいた。格納しているデータは合計わずか5.1MB。WordPressのブログ2つだけで、アクセス数もそこまで多くない。データに対してメモリが80倍近い。明らかにもったいない。

でも、MariaDBのチューニングパラメータは数が多く、どれをどこまで下げれば安全なのか判断するのが面倒。そこでClaude Codeに丸投げしてみました。

環境#

項目	内容
DB	MariaDB 11.7 (Docker)
PaaS	Coolify
用途	WordPress 2サイト
実データ量	5.1MB（3データベース合計）
サーバメモリ	32GB
チューニング前メモリ	約400MB

問題の発見：デフォルト設定の罠#

docker stats でコンテナのメモリ使用量を確認すると、MariaDBが 403.5MiB 使用していた。

MariaDBのコンテナに入って SHOW VARIABLES と SHOW GLOBAL STATUS を確認すると、メモリを大量消費しているバッファが3つ見つかった。

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
-- 134,217,728 (128MB)

SHOW VARIABLES LIKE 'aria_pagecache_buffer_size';
-- 134,217,728 (128MB)

SHOW VARIABLES LIKE 'key_buffer_size';
-- 134,217,728 (128MB)

この3つだけで 384MB。これがデフォルト設定です。

分析：バッファの現在値と実使用量#

Claude Codeに現在のステータスを取得・分析させた結果がこちら。

主要バッファの使用状況#

パラメータ	割当量	実使用/必要量	乖離率
`innodb_buffer_pool_size`	128MB	データ5.1MB（hit rate 98.28%）	25倍
`aria_pagecache_buffer_size`	128MB	Ariaテーブル未使用	∞
`key_buffer_size`	128MB	`Key_blocks_used = 0`	∞
`innodb_log_buffer_size`	16MB	書込み頻度低い	8倍

接続まわりの設定#

パラメータ	設定値	実績	乖離率
`max_connections`	151	最大同時接続 5	30倍
`thread_cache_size`	151	作成スレッド 5	30倍
`table_open_cache`	2000	Open tables 157	12倍

key_buffer_size に至っては使用量がゼロ。MyISAMテーブルを一切使っていないのに128MBが確保されていた。

Claude Codeに投げたプロンプト#

Claude CodeのPlan Modeを使い、以下の流れで作業しました。

Step 1: 現状分析のプロンプト#

まずCoolify管理下のMariaDBコンテナに対して、現在のメモリ使用状況を分析させました。

MariaDB (Coolify, UUID: xxx) のメモリ使用量を分析して。
docker stats でメモリ使用量を確認し、SHOW VARIABLES / SHOW GLOBAL STATUS
から主要パラメータの設定値と実使用量を比較して。

Claude Codeは自動的にCoolifyのMCPツール経由でコンテナ内のMariaDBに接続し、SHOW VARIABLES と SHOW GLOBAL STATUS を取得して分析結果を表形式でまとめてくれた。

Step 2: チューニングプランの作成#

分析結果を踏まえ、Plan Modeでチューニング計画を立てさせました。

この分析結果をもとに、メモリ使用量を100-150MBに削減するチューニングプランを作って。
安全マージンを考慮して、各パラメータの推奨値と根拠を示して。

Step 3: 実行#

プランを承認し、そのまま適用まで実行させました。

チューニング設定#

Claude Codeが作成した設定ファイルがこちら。

[mysqld]
# === InnoDB ===
innodb_buffer_pool_size = 32M      # 128M→32M (データ5MBに対して6倍の余裕)
innodb_log_buffer_size = 2M        # 16M→2M (書込み少ない)
innodb_log_file_size = 16M         # 96M→16M

# === Aria (未使用だが最小値に) ===
aria_pagecache_buffer_size = 8M    # 128M→8M

# === MyISAM (完全未使用) ===
key_buffer_size = 1M               # 128M→1M (Key_blocks_used=0)

# === 接続 ===
max_connections = 20               # 151→20 (最大5接続に対して4倍マージン)
thread_cache_size = 10             # 151→10

# === テーブルキャッシュ ===
table_open_cache = 256             # 2000→256 (Open=157)
table_definition_cache = 256       # 400→256

# === 一時テーブル ===
tmp_table_size = 8M                # 16M→8M
max_heap_table_size = 8M           # 16M→8M

# === ソート・バッファ (per-connection) ===
sort_buffer_size = 512K            # 2M→512K
join_buffer_size = 512K            # 256K→512K
read_buffer_size = 256K            # 128K→256K (少し増加)
read_rnd_buffer_size = 512K        # 256K→512K

設定のポイント#

innodb_buffer_pool_size = 32M: データ5.1MBに対して6倍の余裕。全データがバッファプールに載るのでhit rateは維持される
key_buffer_size = 1M: 使用量ゼロなので最小値に。0にはできない（MariaDBの制約）
aria_pagecache_buffer_size = 8M: Ariaテーブルは使っていないが、内部的に一時テーブルで使われる可能性があるため8MBは残す
max_connections = 20: ピーク5接続に対して4倍マージン。WordPress + cronジョブを考慮しても十分

Coolifyでの適用手順#

CoolifyではMariaDBの設定ファイルをCustom Docker Configuration経由で注入する。Claude CodeはCoolifyのAPIを使って以下の手順を自動実行した。

# 1. 設定ファイルをbase64エンコード
CONFIG=$(cat my.cnf | base64 -w 0)

# 2. Coolify API で設定を更新
curl -X PATCH "https://coolify.example.com/api/v1/databases/{uuid}" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"custom_docker_run_options\": \"--volume ...\"}"

# 3. データベースを再起動
curl -X POST "https://coolify.example.com/api/v1/databases/{uuid}/restart" \
  -H "Authorization: Bearer $TOKEN"

実際にはClaude CodeがCoolifyのMCPサーバー経由でこれらのAPIを叩いてくれるので、手動でcurlを打つ必要はなかった。

Before / After#

メモリ使用量#

指標	Before	After	削減率
コンテナメモリ	403.5 MiB	~150 MiB	63%削減

CoolifyのMetrics画面。Memory Usageグラフで14時頃に約400MBから150MB付近に急落しているのが確認できる

主要バッファの比較#

パラメータ	Before	After	削減量
`innodb_buffer_pool_size`	128MB	32MB	-96MB
`aria_pagecache_buffer_size`	128MB	8MB	-120MB
`key_buffer_size`	128MB	1MB	-127MB
`innodb_log_buffer_size`	16MB	2MB	-14MB
`max_connections`	151	20	-
バッファ合計	400MB	43MB	-357MB

パフォーマンスへの影響#

チューニング後もWordPressの応答に体感上の変化はなく、InnoDB buffer pool hit rateも高い水準を維持している。データ量が5.1MBで32MBのバッファプールに完全に収まっているため、性能劣化は発生しない。

検証ポイント#

チューニング後に確認すべき項目をまとめる。

-- Buffer pool hit rate（95%以上ならOK）
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';

-- 一時テーブルのディスク書き出し率
SHOW GLOBAL STATUS LIKE 'Created_tmp%';

-- 接続数が上限に近づいていないか
SHOW GLOBAL STATUS LIKE 'Max_used_connections';

もしhit rateが著しく低下したり、Max_used_connections が max_connections に近づいた場合は、該当パラメータを引き上げれば対処できる。

所感：Claude Codeでのインフラ運用#

今回の作業、全体でプロンプト3回、所要時間約5分で完了した。

従来なら以下のステップが必要だったはずです。

MariaDBのドキュメントを読む
SHOW VARIABLES / SHOW GLOBAL STATUS の出力を読み解く
各パラメータの意味と推奨値を調べる
安全な値を計算する
設定ファイルを書く
CoolifyのAPIで適用する

これらすべてをClaude Codeが一気通貫で実行してくれた。特に良かった点は以下。

数値分析が正確: Key_blocks_used = 0 のようなステータスから「MyISAMは完全未使用」と即座に判断
安全マージンが適切: データ5.1MBに対して32MBのバッファプールを推奨（6倍マージン）するなど、攻めすぎない設定
Coolify APIの操作も自動化: MCP（Model Context Protocol）経由でCoolifyのAPIを直接操作し、設定変更から再起動まで完了

MariaDBのチューニングに限らず、「現状を分析して→計画を立てて→実行する」というインフラ運用タスクはClaude Codeと相性が良いと感じた。特にPlan Modeで計画を人間がレビューしてから実行に移せるのが安心感がある。

データベースのメモリ設定はデフォルトのまま放置されがちですが、5分の投資で250MBのメモリを回収できるなら、やらない理由はありません。

余談：MySQLはいつから重くなったのか#

昔のMySQL（5.x系あたり）には my-micro.cnf や my-small.cnf といった設定テンプレートが同梱されていて、メモリ64MB程度のマシンでも動かせるような超省メモリ設定が用意されていました。当時のデフォルト設定も控えめで、カジュアルにDBを立ち上げて開発やちょっとしたWebサイトに使うのが当たり前でした。

ところが、MySQL 8.0やMariaDB 10.x以降はそうした軽量設定テンプレートが廃止され、デフォルトの innodb_buffer_pool_size が128MBに設定されるなど、「そこそこのメモリが載っている前提」の設定に変わりました。今回のように何も考えずに立ち上げるだけで数百MBを占有する、かつての軽量高速なMySQLとは別物です。

カジュアルにDBを使いたいなら、今ならSQLiteが現実的な選択肢でしょう。サーバープロセスが不要で、ファイル1つで完結する。Litestreamを組み合わせればレプリケーションもできます。

ただ、WordPressはSQLiteに公式対応していないという矛盾があります。WP-SQLite-DBのようなコミュニティプラグインはあるものの、公式サポートではありません。結局、WordPressを使い続ける限りMySQL/MariaDBからは逃れられない。

もっとも、この記事で扱っている2つのWordPressサイトも、このブログと同様にAstroへの移行を予定しています。移行が完了すればDBコンテナごと消えるので、メモリチューニングの話自体が不要になります。最終的には静的サイトジェネレータが正義、ということかもしれません。