本稿は Docker Desktop・Cursor IDE・仮想通貨トレード Bot を同時に動かしている M-series Mac mini（RAM 24 GB）で、突然のメモリ飢餓を撲滅した実録です。
最新の除外方針（data_links / .secrets / backtest24/logs / logs は監視対象に残し、htmlcov / __pycache__ / *.pyc のみ除外）を反映しています。
CursorエディタとDocker周りのセッティング終わり。今日も開発をサクサク進めていく。やはりマシンスペックを上げたことの恩恵がデカい。
システムがダウンする前に予兆を検知して即座にトラブルシュートができるから、開発速度を落とさずにすむ。 pic.twitter.com/LhF6XoUa0k— よだか(夜鷹/yodaka) (@yodakablog) July 6, 2025
1. なぜ 24 GB でも RAM が枯渇するのか
| レイヤ | 典型症状 | 原因概要 |
|---|---|---|
Docker VM (qemu-system) | RSS が 10–16 GB に膨張 | VM に固定割当て (‐m 8 GB 等) ＋ virtiofs キャッシュ |
| コンテナ | 単体プロセスが数 GB 消費 | mem_limit 未設定／リーク／Java などヒープ拡大 |
| IDE ウォッチャー | FD 3 万超・CPU 60 % | VS Code / Cursor が node_modules 等を全文監視 |
| Spotlight / Time Machine | mds_stores が CPU 100 % | Docker のレイヤ展開を全インデックス化 |
2. メモリ状況を一瞬で可視化するワンライナー
# 全体サマリ & 空き率
vm_stat && echo && memory_pressure -Q
# VM 実メモリ (GB)
ps -o rss= -p $(pgrep -f qemu-system) | awk '{printf "Docker-VM RSS: %.1f GB\n",$1/1048576}'
# 上位メモリプロセス
ps aux | sort -nrk 4 | head -20
System-wide memory free percentage が 15 % を切ったら危険域 です。
3. ステップ① ― VM メモリ上限と Ballooning
- Docker Desktop ▸ Settings ▸ Resources
Memory を 6 GB（開発なら 4 GB でも可）に。 - Docker Desktop ≥ 4.43 なら Advanced →
☑︎ Enable dynamic memory management → Apply & Restart- アイドル時に VM RSS が 2〜4 GB まで縮む。
4. ステップ② ― コンテナに mem_limit / cpus
# docker-compose.yml
services:
api:
image: myapi:latest
mem_limit: 1g # ←必ず上限を書く
cpus: 1
db:
image: postgres:16
mem_limit: 2g
cpus: 1
docker stats で LIMIT 列が付けば成功。
5. ステップ③ — トレード Bot 向けファイルウォッチ最適化
5-1 監視したい・したくないディレクトリ
| 意味 | 監視を 維持 | 除外 |
|---|---|---|
| トレード判断に直結 | data_links/**・.secrets/**backtest24/logs/**・logs/** | — |
| 不要・肥大化要因 | — | htmlcov/**__pycache__/***.pyc |
5-2 VS Code / Cursor 設定例
{
"files.watcherExclude": {
"**/htmlcov/**": true,
"**/__pycache__/**": true,
"**/*.pyc": true
},
"search.exclude": {
"**/htmlcov/**": true,
"**/__pycache__/**": true,
"**/*.pyc": true
}
}
維持したい 4 フォルダは 除外リストに入れない ことがポイントです。
5-3 効果測定
lsof -c "Cursor Helper" | wc -l # ← 1 万未満なら合格
6. ステップ④ ― Spotlight／Time Machine 除外
sudo mdutil -i off ~/Library/Containers/com.docker.docker sudo mdutil -i off ~/Library/Group\ Containers/group.com.docker
Time Machine → “オプション” で同パスを追加。
7. ステップ⑤ ― 週次 Auto-Prune
cat <<'PL' | sudo tee /Library/LaunchDaemons/com.local.dockerprune.plist <?xml version="1.0" encoding="UTF-8"?> <plist version="1.0"><dict> <key>Label</key><string>com.local.dockerprune</string> <key>ProgramArguments</key> <array><string>/usr/local/bin/docker</string><string>system</string><string>prune</string><string>-af</string><string>--filter</string><string>until=168h</string></array> <key>StartCalendarInterval</key><dict><key>Weekday</key><integer>7</integer><key>Hour</key><integer>4</integer></dict> <key>StandardOutPath</key><string>/tmp/dockerprune.log</string> <key>StandardErrorPath</key><string>/tmp/dockerprune.err</string> </dict></plist> PL sudo launchctl load /Library/LaunchDaemons/com.local.dockerprune.plist
0 4 * * 0 /usr/local/bin/docker system prune -af --filter "until=168h" > /tmp/docker_prune.log 2>&1
8. ビフォー／アフター計測
| 指標 | Before | After |
|---|---|---|
| Docker-VM RSS | 15 GB | 6〜8 GB（Idle 3 GB） |
| free% (memory_pressure) | 20 % | 65〜80 % |
| swap / compressed | 数百 MB / 5 GB | 0 MB / 1–2 GB |
| ウォッチャー FD | 25 k | 8 k |
| Spotlight CPU | 80 % | ≈0 % |
9. トラブル対処 Q&A：Engine stopped ループ
| 症状 | 解決策 |
|---|---|
| Docker Engine stopped が 3 分以上 | 1) pkill -9 -f com.docker → 再起動2) rm -rf ~/Library/Containers/com.docker.docker/Data/vms/0/* → 再起動 |
connection refused 192.168.65.x | Settings ▸ Advanced ▸ Use new virtualization framework を OFF（vf-kit → QEMU） |
| UI も起動しない | /Applications/Docker.app/Contents/MacOS/Docker --uninstall → 最新版を再インストール |
10. まとめ
- VM 6 GB＋Ballooning
- コンテナ全てに
mem_limit/cpus - トレード Bot に必要なフォルダだけ監視
- Spotlight & Time Machine から Docker を切り離し
- 週次 Auto-Prune
これで 24 GB マシンでも swap 0 のまま、
バックテストもリアルタイム Bot もストレスフリーに動かせます。
これらを試して、数値でラクさを体感してみてください！
付録：リアルタイム監視ツール
## 未インストールなら brew で導入 brew install htop # 一度だけ実行 ## 起動 (q で終了) htop