Posts

2026年9月15日に、文章を生成しないAIモデルが出ました。TypeSafe AIの「Jev」です。返すのは型のついた値と、確率と、信頼度。人間が読むためではなく、ソフトウェアがそのまま使うための出力です。 このサイトは「自分のサーバーで動かした記録」を書いています。なので、最初に確認したのはこれを自前で動かせるのかでした。 確認できた範囲では、動かせません。 そして、その理由の書かれ方が少し特殊でした。 確認できたこと Jevのウェイトは公開されていない。 ライセンスはproprietary（専有）で、アーキテクチャも技術論文も公開されていないとされている セルフホストの選択肢について、公式サイト・Cloudflareのドキュメント・Wikipedia・技術メディアの4か所を見ても、記載が1つもなかった 提供はホスト型APIのみ。エンドポイントは api.typesafe.ai/v1/systemone 価格は入力100万トークンあたり$0.042。出力トークンは課金されない（2つの情報源で一致） コンテキスト長については、情報源が食い違っている（後述） 応答時間は70〜500ミリ秒とされている 私はJevを実際には叩いていません。 この記事は公開情報の確認と、自前で同じことをやる場合の計算です。そこは最後にはっきり書きます。 Jevが何を返すのか（最小限） 大規模言語モデルと違い、Jevは自然言語のテキストを返しません。用意されているのは3種類の問い方です。 プリミティブ 何をするか 返ってくるもの Choice 選択肢から1つ選ぶ（最大255個） 選択肢・確率・信頼度 Score 順序のある段階で評価する スコア・段階別の確率・信頼度 Noul はい／いいえを判定する 0〜1の確率 信頼度は確率分布の形から出しており、高信頼度は自動処理へ、中程度はレビューへ、低信頼度は人間へという振り分けが想定されています。 「判断だけを返す」というのは、つまりこういうことです。文章を読ませて要約させるのではなく、「この問い合わせは対応が必要か」に0〜1で答えさせる。 用途がはっきり分かれています。 自前サーバーで動かせるのか 4か所を確認しました。 確認先 セルフホストに関する記載 TypeSafe AI 公式サイト 記載なし（early accessの案内、コンソール、ドキュメントへのリンクのみ） Cloudflare AI のモデルドキュメント 記載なし（typesafe/jev として第三者製モデルを提供） Wikipedia ライセンスはproprietary。「アーキテクチャ、ウェイト、技術論文のいずれも公開していない」 MarkTechPost 「TypeSafe has not published weights, a parameter count, or a self-hosting option」 注意して書きます。「できない」と断定できるのは、公式が明示的に禁じている場合です。 ここで確認できたのは、そのための情報が公開されていないということです。ウェイトが無ければ動かしようがないので、実務上は「できない」と同じですが、書き方は分けておきます。 つまりJevを使うということは、判断を外部のAPIに投げるということです。自前サーバーの話とは、前提が逆になります。 情報が食い違っている点：コンテキスト長 ここは正直に書きます。2つの情報源で、記載が食い違っています。 Cloudflare AI のドキュメント：コンテキストウィンドウ 32,000トークン MarkTechPost：「Context length and model size remain undisclosed（コンテキスト長とモデルサイズは非公開のまま）」 TypeSafe自身が公開していない数字を、提供事業者であるCloudflareが自社ドキュメントに書いている、という形です。どちらが正しいのかは、私には判断できませんでした。 ...

Ollamaのコマンドは、覚えることがほとんどありません。pull して run するだけです。 詰まるのはコマンドではなく、その裏側です。 pullが何分かかるのか。1回目の応答だけ異常に遅いのはなぜか。使い終わったメモリはいつ返ってくるのか。このあたりは、動かしてみるまで分かりません。 さくらのVPS 2Gプラン（Ubuntu 24.04・GPUなし・CPUのみ）で測った数字と、公式ドキュメントの記載を突き合わせました。 確認できたこと pull は 0.5Bで38.6秒、1Bで2分4秒、3Bで2分56秒。ディスクはそれぞれ +380MB / +1,260MB / +1,840MB 増えた 1回目の応答が遅いのはモデルのロード時間。0.5Bで3.18秒、1Bでは43.6秒かかった モデルは既定で5分間メモリに保持され、そのあとアンロードされる（公式ドキュメントの記載） つまり5分以上間を空けると、あのロード時間がもう一度発生する ollama ps の Processor 列を見れば、CPUで動いているかGPUで動いているかが分かる（公式の記載。100% CPU のように出る） Ollama本体は常駐36MB。ディスクは2.1GB。モデルを3つ入れた時点で合計3.4GBだった 実測値は「実測」、公式ドキュメントの記載は「公式」と書き分けます。 基本のコマンドと、実際にかかった時間 コマンド 何をするか このサーバーでの実測 ollama pull <model> モデルを取得する 0.5B: 38.6秒 / 1B: 2分4秒 / 3B: 2分56秒 ollama run <model> "..." 1回だけ実行する 初回はロード時間が乗る（後述） ollama list 入っているモデルを見る 即時 ollama ps いま動いているモデルを見る 即時。Processor列が重要 ollama rm <model> モデルを消す 未測定 ollama serve サーバーとして起動する systemdに任せている 覚えるのはこれで足りました。 以下は、この表に書ききれない裏側です。 ...

本記事はプロモーションを含みます。 記事内の一部のリンクは広告リンクです。リンクの有無で内容を変えていません。 掲載している数値はすべて自分のサーバーで実際に測った値か、公式ドキュメントの記載です。 ローカルLLMの構築記事を探すと、出てくるのは自分のPC（WindowsやMac、自作機）か、自社サーバー（ハードウェアを買う話）のどちらかです。 VPSに立てる話が、ほとんど見つかりません。 私は、さくらのVPS 2Gプラン（GPUなし・CPUのみ）にOllamaを入れて動かしています。その過程で、PCに入れるのとは違う問題に2つぶつかりました。 どちらも、PCなら起きないか、起きても実害が出ないものです。 確認できたこと 公式のインストールスクリプトは、1.34GBを一発勝負で落とす構造。実測で89分かけて55.6%で切れた。途中から再開できない wget -c で落としてから展開すれば2分1秒で終わった 公式のアップグレード手順も、同じスクリプトの再実行。つまり更新のたびに同じ賭けをする Ollamaに認証はない。 公式ドキュメントには「公開のしかた」は書いてあるが、公開したあと誰が叩けるのかは書かれていない systemdでメモリ枠を切ると、モデルが暴れても同居しているサービスが巻き添えにならない PCに入れるのとVPSに入れるのは、前提が3つ違う 自分のPC VPS GPU 載っていることがある 基本的にない 稼働 使うときだけ 24時間動き続ける ネットワーク 家庭内LANの内側 グローバルIPで直結 3つ目が、この記事のいちばん重要な点です。 自分のPCで OLLAMA_HOST を広げても、届くのは家の中だけです。VPSで同じことをすると、インターネット全体から届きます。 GPUがないことの影響（どのモデルまで載るか）はGPUなしでローカルLLMは使えるのかに分けて書きました。この記事は構築の手順と、立てたあとの安全に絞ります。 公式の「3行」は、1.34GBの一発勝負 Ollamaの公式インストール手順はこれです。 curl -fsSL https://ollama.com/install.sh | sh これを実行したら、89分かけて55.6%で切れました。 curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1) tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now やり直しです。 このスクリプトは curl | zstd -d | tar -x と直結していて、ダウンロードしながら展開しています。 そのため途中で切れても再開できません。 ...

「GPUがないパソコンやサーバーでローカルLLMは動くのか」。動きます。ただし、載せられるモデルの大きさは、ほぼ計算で決まります。 載せられるモデルファイル ≒ 空きメモリ ÷ 2.4 この2.4という倍率は、GPUなしのVPSで実際に測って出した値です。そしてこの計算を外れた瞬間、速度は段階的にではなく崖のように落ちます。 確認できたこと 必要メモリの目安はモデルファイルの約2.4倍。0.5Bのモデル（380MB）で実測930MBだった 0.5Bは15.36 tokens/秒で動き、1Bでは0.07 tokens/秒に落ちた。219分の1。段階的ではなく崖 Ollamaの公式ドキュメントには、必要メモリの記載がない。2026年9月13日に確認した 重いのはツールではなくモデル。Ollama本体の常駐メモリは36MBで、Dockerの49MBより軽い 先に埋まるのはメモリではなくディスクのことがある。Ollama本体だけで2.1GB 商用利用の可否はモデルごとに違う。同じQwen2.5でもサイズによってライセンスが分かれている この記事の数字には実測値と計算値が混ざっています。 どちらなのかは、その都度書きます。 載るモデルは「空きメモリ ÷ 2.4」で決まる 出発点は、GPUのないVPSで測った1本の実測値です。 モデルファイル 380MB → 実際のメモリピーク 930MB（2.4倍） さくらのVPS 2Gプラン、Ubuntu 24.04、GPUなし・CPUのみ。qwen2.5:0.5b を載せたときの値です。測定の詳細は2GBのVPSでローカルLLMは動くのかに書きました。 この倍率で逆算すると、載せられるモデルの上限が出ます。 載せられるモデルファイル ≒ 空きメモリ ÷ 2.4 同じ実測から、1Bのモデルが動かない理由も説明がつきます。 1Bのファイルは1,260MB。2.4倍すると約3,000MBが必要になります。そのときの枠は1,200MBでした。入るはずがありません。そして実際に入りませんでした。 倍率が1本のモデルからしか出ていない点は、そのまま弱点です。 0.5B以外では検証していません。 なお、この2.4倍はcgroupの memory.current から取った値で、モデルファイルのページキャッシュを含みます。 「アプリが確保した量」より大きめに出る数字です。余裕を見る方向に効くので、目安としては安全側ですが、そういう数字だという前提で読んでください。 公式のファイルサイズから逆算した早見表 ここから先は計算値です。 各モデルのファイルサイズは2026年9月13日にOllama公式ライブラリで確認した値、必要メモリはそれを2.4倍したものです。 モデル 公式のファイルサイズ 必要メモリの目安（×2.4） gemma3:270m 292MB 約700MB qwen2.5:0.5b 398MB 約960MB（実測930MB） gemma3:1b 815MB 約1,960MB qwen2.5:1.5b 986MB 約2,370MB llama3.2:1b 1.3GB 約3,120MB qwen2.5:3b 1.9GB 約4,560MB llama3.2:3b 2.0GB 約4,800MB gemma3:4b 3.3GB 約7,920MB 実測と一致しているのは2行目だけです。 他は倍率からの計算で、私は確かめていません。 ...

本記事はプロモーションを含みます。 記事内の一部のリンクは広告リンクです。リンクの有無で内容を変えていません。 掲載している数値はすべて公式ドキュメントの記載か、自分のサーバーで実際に測った値です。 Claude Codeを自分のVPSで動かしたい。まず決まるのは「どのプランを買うか」です。 各社のページを調べたら、全社が「4GB以上」と書いていました。 一方、Anthropicの公式要件も4GB以上です。 では2GBでは動かないのか。2GBのVPSに手で入れて、動かしました。最大268MBでした。 結論 結果 各社の要件 4GB以上（2GB以下は非対応と明記する社もある） 2GBでの実測 最大268MB / ファイル作成もコード実行も成功 Node.js 不要（ネイティブインストーラ） ディスク +206MB インストール時間 6分46秒 アカウント 有料プラン必須（無料のClaude.aiでは使えない） ただし、「4GBは要らない」とは書きません。 理由は最後に書きます。 対応している4社と、その必要メモリ Claude Codeのテンプレート／アプリイメージを公式に出しているのは、確認できた範囲でこの4社です。 提供元 形式 公表している必要メモリ XServer VPS アプリイメージ 4GB以上。2GB以下のプランでは利用不可 シンVPS アプリイメージ 4GB以上。2GB以下のプランでは利用不可 ConoHa VPS スタートアップスクリプト 最小3GB、推奨4GB以上 KAGOYA CLOUD VPS テンプレート 記載を確認できず （表のXServer VPSとConoHa VPSは広告リンクです。他社は提携していないため通常のリンクです。リンクの有無と、この表に書いた内容は無関係です。） XServer VPSとシンVPSは、2GB以下のプランでは選択肢に出てきません。 「安いプランを買ってから気づく」ことになります。 Anthropicの公式ドキュメントも同じです。 Hardware: 4 GB+ RAM, x64 or ARM64 processor 4社と公式で、数字が一致しています。 ConoHaのスクリプトが入れるもの ConoHaのドキュメントには、中身まで書いてあります。 ソフト バージョン Claude Code 最新 Node.js 22 ripgrep 13.0.0 UFW 最新 Fail2ban 最新 対応OSは Ubuntu 24.04 LTS のみ。 ...

「2GBのVPSでローカルLLMは動くのか」。動きます。ただし0.5Bまでです。 0.5Bから1Bに上げた瞬間、生成速度が 15.36 tokens/秒 → 0.07 tokens/秒 に落ちました。219分の1です。段階的に遅くなるのではなく、崖から落ちます。 3Bはサービスごと落ちました。 結論 モデル ファイル ディスク増 メモリピーク 生成速度 結果 qwen2.5:0.5b 397MB +380MB 930MB 15.36 tok/s 動く llama3.2:1b 1.3GB +1,260MB 1,201MB（上限） 0.07 tok/s 実用不可 qwen2.5:3b 1.9GB +1,840MB — — 落ちた 必要メモリの目安は「モデルファイルの約2.4倍」。 0.5B（380MB）で930MBでした。 測定条件 サーバー：さくらのVPS 2Gプラン / Ubuntu 24.04 LTS（GPUなし・CPUのみ） Ollama：0.33.3 枠：systemdの MemoryMax=1200M / MemorySwapMax=1024M でOllamaを隔離 同居：定期的にデータを取得して予測を回すバッチ処理と、静的サイト1本が動いている実運用サーバー プロンプト：「日本の首都はどこですか。一文で答えてください。」 同居しているものがあるので、free の全体値は他の処理の影響を受けます。そのため、Ollama単体の数字はすべてcgroup（memory.current）から取っています。 Ollama本体だけで、ディスク2.1GB・メモリ36MB モデルを1つも入れていない状態です。 値 ディスク +2,160MB 常駐メモリ（cgroup） 36MB 待ち受け 127.0.0.1:11434 メモリは驚くほど軽い。 比較すると位置づけが分かります。 常駐メモリ Ollama本体 36MB Docker（dockerd + containerd） 約49MB n8n 402MB Dify（16コンテナ） 2,076MB 「AIツールは重い」わけではありません。重いのはモデルです。 ...

Difyとn8nを実測したあと、VPSのディスクに 13GB のイメージが残りました（Difyの実測記事）。 片付けようと docker system prune を叩きました。79.75MBしか消えませんでした。 「掃除コマンド」は1つではありません。4段階あり、それぞれ触る場所が違います。 段階ごとに df と docker system df を取って、どこで何が消えるかを測りました。 結論：4段階で消えるものはこれだけ違う 段階 コマンド 消えたもの 回収 1 docker system prune 停止中のコンテナ 79.75MB 2 docker image prune -a 未使用イメージ13個 12.96GB 3 docker volume prune 匿名ボリューム20個 51.45kB 4 docker volume prune -a 名前付きボリューム3個 5.713MB 第1段階だけで止めると、13GBがそのまま残ります。 第3段階で止めると、データが入っているほうが残ります。 測定条件 サーバー：さくらのVPS 2Gプラン / Ubuntu 24.04 LTS / Docker 29系 片付ける対象：Difyのイメージ12個（10.6GB）、n8nのイメージ1個（2.47GB）、コンテナ1個、ボリューム23個 稼働中のコンテナ：なし（測定前にすべて停止・削除済み） 開始時：ディスク使用 23,724MB / 空き 71,808MB 掃除を始める前の docker system df です。 ...

記事を1本追加して hugo を叩いたら、ビルドごと落ちました。 ERROR error building site: render: failed to render pages: render of "/categories" failed: ".../themes/PaperMod/layouts/baseof.html:24:7": execute of template failed: template: taxonomy.html:24:7: executing "taxonomy.html" at <partialCached "header.html" . .Page>: error calling partialCached: ".../PaperMod/layouts/_partials/header.html:92:38": execute of template failed: template: _partials/header.html:92:38: executing "_partials/header.html" at <site.GetPage>: error calling GetPage: page reference "選び方" is ambiguous 追加した記事のフロントマターは、これでした。 categories: ["選び方"] tags: ["VPS", "さくらのVPS", "メモリ", "n8n", "Dify", "スペック", "選び方"] 選び方 をカテゴリとタグの両方に書いていました。 これだけです。 犯人はテーマのこの1行 _partials/header.html の92行目です。 {{- $is_search := eq (site.GetPage .KeyName).Layout `search` }} メニュー項目が検索ページかどうかを判定するために、site.GetPage を呼んでいます。 ...

本記事はプロモーションを含みます。 記事内の一部のリンクは広告リンクです。リンクの有無で内容を変えていません。 掲載している数値はすべて自分のサーバーで実際に測った値か、公式ドキュメントの記載です。 「AI用途のVPSは4GB以上がおすすめです」。よく見る書き方です。 その4GBの内訳がどこにも書いてありません。 OSがいくら使うのか、ツールがいくら足されるのか、どこに余裕を見ているのか。根拠が出てこないので、自分の用途に当てはめようがない。 このサイトでは、ここまで4本の記事で全部自分で測ってきました。 その数字を積み上げて、必要なスペックを出します。 先に結論 やりたいこと メモリ ディスク 根拠 静的サイト＋小さな業務アプリ 1〜2GB 20GB〜 実測（アプリ3本で166MB） ＋ n8n で自動化 2GB 50GB〜 実測（+402MB、空き1.1GB残） ＋ Dify（起動して置くだけ） 4GB 100GB〜 実測（Dify単体で2,076MB） Dify を実際に使う 8GB 100GB〜 推定・未検証 ＋ ローカルLLM（0.5Bクラス） 2GB 20GB〜 実測（本体2.1GB＋モデル） ローカルLLM（1B以上） 4GB〜 50GB〜 推定・未検証 「実測」と書いた行は測った数字です。「未検証」の行は測っていません。どこまでが実測でどこからが推測か、はっきり分けて書きます。 土台：OSと常駐デーモンで何MB持っていかれるか まずアプリを何も載せない状態のコストです。ここを知らないと積み上げができません。 このサーバー（さくらのVPS 2Gプラン / Ubuntu 24.04）で、再起動直後・Dockerとnginxと自作アプリ1本が動いている状態が 398MB でした。 内訳のうち、多くの人が見落とすものが2つあります。 1. VPSでは働きようがないデーモンが50〜100MB 最初の記事で測った内訳です。 プロセス RSS 本来の用途 fwupd 44.0MB 物理デバイスのファームウェア更新 multipathd 26.7MB ストレージへの複数I/Oパスの管理 udisksd 13.4MB ディスク・リムーバブルメディアの管理 ModemManager 12.8MB モバイル通信モデムの管理 VPSに物理ファームウェアはありません。モバイル通信のモデムも刺さっていません。常駐3つで約53MB、fwupd が起動していると約97MB。 ...

前回、n8nは2GBのVPSに 402MB で載りました（実測記事）。そのとき「次はDifyを入れてみます」と書きました。 Difyの公式要件は 2CPU / 4GB。今回の環境は2GB、しかも本番の処理と公開中のサイトが同居しています。要件を満たしていません。 それを承知で載せて、10秒ごとに測りました。 結論から書きます。載ります。ただし2,076MB要求してきます。 上のオレンジ色が、物理メモリに収まらずスワップへ追い出された分です。881MB。 そして下のグラフ、起動から4分間はI/O待ちが最大91%。この間、SSHの接続が切れました。 測定条件 サーバー：さくらのVPS 2Gプラン / Ubuntu 24.04 LTS 同居しているもの：定期的にデータを取得して予測を回すバッチ処理と、静的サイト1本 Dify：1.17.0（公式リポジトリの docker/ をそのまま使用、ベクトルDBは既定のweaviate） 記録：10秒間隔・自作スクリプト。free / vmstat / ps と cgroup の memory.current を読むだけ 時間：10分間（起動から自動停止まで） 前回までに43時間のベースラインと、n8nを載せた前後の数字が取ってあります。「載せる前」が分かっているので、増えた分がそのままDifyのコストになります。 先に：ディスクが10.6GB増える メモリの話の前に、こちらのほうが先に効きます。 イメージ取得前 12,971MB イメージ取得後 23,572MB 差分 +10,601MB イメージだけで10.6GB。 n8nは2.47GBだったので、4.3倍です。 内訳の上位はこうなっています。 イメージ サイズ dify-api 4.06GB dify-plugin-daemon 2.28GB dify-agent-backend 1.45GB dify-web 892MB dify-sandbox 848MB dify-agent-local-sandbox 779MB postgres / squid / nginx / weaviate / redis ほか 計 1.25GB dify-api の1本だけで4GB。n8nのイメージ全体（2.47GB）より大きい。 ...

「2GBのVPSでn8nは動くのか」を調べると、たいてい「動く」か「厳しい」のどちらかしか書いてありません。具体的に何MB増えるのかは、ほとんど出てきません。 実際に載せて、1分刻みで測りました。 合計402MB。 そして載せ終わってもまだ1.1GB空いています。 測定条件 サーバー：さくらのVPS 2Gプラン / Ubuntu 24.04 LTS 元から動いていたもの：定期的にデータを取得して予測を回すバッチ処理と、静的サイト1本 記録：1分ごとにcronで自動記録（スクリプトは前の記事に載せています） 時間：2026-09-07 01:12 〜 01:37 前の記事で43時間分のベースラインを取ってあります。「載せる前」が分かっているので、増えた分がそのままn8nのコストになります。 結果：4段階に分けて測る 多くの記事は「n8nは○MB」で終わります。しかし実際に増えるものは1つではありません。 段階 システム全体のメモリ 増分 元の状態 438MB — ＋Dockerデーモン 476MB +38MB ＋n8nコンテナ起動 804MB +328MB ＋UIを開いてワークフローを1本 840MB +36MB 合計 +402MB ディスクは 10GB → 13GB（+3GB）。スワップは 0 → 37MB 使われました。 発見1：Dockerデーモンだけなら38MB 「Dockerは重い」とよく言われます。実際に測ると、デーモン単体では38MBでした。 導入直後の記録がこれです。 01:14 431MB python 90.8, systemd-journal 72.7, multipathd 26.7 ← 導入前 01:15 523MB apt-get 98.3, python 90.8, dockerd 87.6 ← インストール中 01:16 483MB python 90.8, dockerd 88.3, systemd-journal 72.9 ← 完了 01:19 478MB python 90.8, dockerd 87.0, systemd-journal 73.0 ← 安定 インストール中は apt-get で523MBまで上がりますが、終われば478〜485MBに落ち着きます。 ...

前回の記事で、VPSのメモリを1回だけ測りました。ただしあれはアイドルに近い状態の1サンプルです。ピークは写っていません。 そこで、1分ごとに記録するスクリプトを仕掛けて放置しました。43時間、2,590サンプル、欠測ゼロ。 結果、予想は外れました。メモリのピークを作っていたのは、自分のアプリではありませんでした。 上がメモリ、下がCPUです。山が重なっていません。 これが今回いちばん面白かったところです。 測定条件 サーバー：さくらのVPS 2Gプラン / Ubuntu 24.04 LTS 期間：2026-09-04 01:10 〜 09-05 20:19（43.1時間） 間隔：1分（cron） サンプル数：2,590（120秒を超える欠測ゼロ） 載せているもの：定期的にデータを取得して予測を回すバッチ処理と、静的サイト1本 使ったスクリプト 追加パッケージは不要です。free / vmstat / ps / awk だけで動きます。 #!/usr/bin/env bash set -u OUT="${1:-$HOME/vps-metrics.csv}" if [ ! -f "$OUT" ]; then echo "timestamp,mem_total_mb,mem_used_mb,mem_available_mb,swap_used_mb,load1,load5,cpu_idle_pct,p1_name,p1_rss_mb,p2_name,p2_rss_mb,p3_name,p3_rss_mb" > "$OUT" fi ts=$(date '+%Y-%m-%d %H:%M:%S') mem=$(free -m | awk '/^Mem:/{print $2","$3","$7}') swp=$(free -m | awk '/^Swap:/{print $3}') ld=$(awk '{print $1","$2}' /proc/loadavg) idle=$(vmstat 1 2 | awk 'NR==2{for(i=1;i<=NF;i++) if($i=="id") c=i} END{print (c?$c:"")}') top=$(ps -eo comm=,rss= --sort=-rss | head -3 | tr -d ',' \ | awk '{printf "%s,%.1f,", $1, $2/1024}' | sed 's/,$//') echo "$ts,$mem,$swp,$ld,$idle,$top" >> "$OUT" cronに1行足すだけです。 ...

さくらのVPS 2Gプランで、自作の業務システムを3本動かしています。9日間連続稼働、ロードアベレージ0.20、メモリは7割が空いたままです。 測ってみて、想定外だったことがあります。アプリ3本が使っているのは約166MB。一方で、このサーバーでは働きようがないOSのデーモンが、合計50〜100MBを占めていました。 自分のアプリより、使う予定のない仕組みのほうが目立つ。プラン変更を考える前に、見るべき場所がありました。 測定条件 数字を出す記事なので、どういう状態で測ったかを先に書きます。 サーバー：さくらのVPS 2Gプラン / Ubuntu 24.04 LTS 測定時刻：平日15:57、業務時間内だがアクセスはほぼない状態 稼働日数：9日15時間（無停止） サンプル数：1回（vmstat のみ5秒間） したがって以下の数字はアイドルに近い状態のものです。ピーク時の値ではありません。負荷時の測定は別途行い、追記します。 動かしている3本 すべて自作の業務システムです。フロントには Caddy を置いています。 システム 構成 常駐メモリ(RSS) 反応計測システム FastAPI 0.141.1 / uvicorn 0.52.4 / SQLite 約66MB 基幹システム Python + gunicorn（-w 1 --threads 8 -t 120） 約65MB 仮想待合室 Go（静的リンクの単一バイナリ）/ 設定はJSON 約35MB 3本合計 約166MB Caddy リバースプロキシ / HTTPS 約23MB 3本とも 127.0.0.1 のポートで待ち受けていて、外部に直接は晒していません。Caddyが受けて振り分けています。 基幹システムは自社の業務用なので、フレームワークやデータ構造の詳細は伏せます。この記事で必要なのはメモリの数字だけなので、そこは支障ありません。 3本で166MBに収まっている理由 DBサーバーを1台も動かしていないからです。 systemctl list-units --type=service --state=running \ | grep -iE "postgres|mysql|maria|redis|mongo" # → 何も返らない PostgreSQLもMySQLもRedisも入っていません。反応計測システムはSQLiteのファイル1つ（data/dareyomi.db）で動いています。 ...