「チームメンバーが一斉にリクエストを投げるとCPUが張り付いて共有サーバー全体が重くなる」
そんな問題を抱えるLinuxエンジニアや情シス担当者は多いはずです。この記事では、systemdのDrop-inファイルを使ってOllamaのCPU使用率・メモリ上限・ディスクI/O優先度を設定する手順を解説します。
cgroup v2を使ったsystemdのリソース制御はOllama固有の技術ではなく、systemdで管理された任意のサービスに適用できる汎用的なLinux技術です。Ollamaのsystemdサービス自体の基本構築はUbuntu ServerでローカルLLMを構築する方法で確認してください。
この記事のポイント
・systemdのDrop-in設定でOllamaにCPUQuota・MemoryMaxをサービス単位で適用できる
・/etc/systemd/system/ollama.service.d/override.confに記述してdaemon-reloadで即時反映する
・/sys/fs/cgroup/system.slice/ollama.service/配下のファイルで設定値とリアルタイム使用量を確認できる
・MemorySwapMax=0でSwap書き出しを禁止し、メモリ不足時はOOMで素早く回復させる運用が実務に向く
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜOllamaのリソース制限が共有Linuxサーバーで必要なのか
Ollamaはデフォルトではリソースに上限がありません。Llama3.3の70bモデルを複数のチームメンバーが同時に呼び出すと、空いているメモリとCPUをフル活用します。その結果、同じサーバーで動いているWebサーバーやデータベースのレスポンスが急激に悪化することがあります。知人のインフラエンジニアから聞いた話では、開発チームが業務中に一斉にOllama経由でコードレビューを依頼したところ、同じサーバー上のNginxがOOMキラーに落とされたことがあったそうです。原因はOllamaへのメモリ制限がなく、LinuxカーネルがNginxを優先度が低いと判断してプロセスをキルしたためでした。
社内でChatGPTの代替としてローカルLLMを展開する場合、複数の部署や利用者が同じサーバーを共有するケースが増えます。社内利用全体の設計については社内でChatGPTが使えないときの代替手段も参考にしてください。
systemdのリソース制限を設定することで、Ollamaが使えるリソースの上限を事前に決め、他のサービスへの影響を予防できます。設定は `/etc/systemd/system/ollama.service.d/override.conf` に数行書くだけで完結します。
cgroup v2の基礎知識｜systemdがリソースを管理する仕組みを理解する
Ubuntu 22.04 LTS以降では、cgroup v2がデフォルトで有効になっています。cgroup（コントロールグループ）は、プロセスグループに対してCPU・メモリ・I/Oの上限を設定するLinuxカーネルの機能です。systemdはサービスごとに自動的にcgroup v2の名前空間を作成します。Ollamaのサービスは `/sys/fs/cgroup/system.slice/ollama.service/` 配下にcgroupエントリが存在します。ここにあるファイルを読み書きすることで、リソース使用量の確認や制限値の確認ができます。
systemdの設定ファイルに値を書くと、systemdがcgroup v2の対応ファイルへ変換して書き込む仕組みです。cgroup v2のファイルを直接編集する必要はありません。まず自分の環境でcgroup v2が有効かを確認します。
$ findmnt -t cgroup2 TARGET SOURCE FSTYPE OPTIONS /sys/fs/cgroup cgroup2 cgroup2 rw,nosuid,nodev,noexec,relatime
$ grep cgroup2 /proc/filesystems nodev cgroup2
Drop-inファイルでOllamaのCPU使用率を制限する手順
1. Drop-inディレクトリを作成する
systemdのユニットファイル（/lib/systemd/system/ollama.service）を直接編集すると、Ollamaのアップデート時に設定が上書きされます。Drop-inファイルを使うことでアップデートに影響されない設定管理ができます。$ sudo mkdir -p /etc/systemd/system/ollama.service.d/
2. override.confにCPU制限を書く
$ sudo nano /etc/systemd/system/ollama.service.d/override.conf
[Service] CPUQuota=200%
3. systemdにDrop-inを反映してOllamaを再起動する
$ sudo systemctl daemon-reload $ sudo systemctl restart ollama $ systemctl status ollama * ollama.service - Ollama Service Loaded: loaded (/etc/systemd/system/ollama.service; enabled; preset: enabled) Drop-In: /etc/systemd/system/ollama.service.d └─override.conf Active: active (running) since Thu 2026-10-01 09:00:00 UTC; 5s ago
4. CPU制限がcgroupfsに反映されたことを確認する
$ cat /sys/fs/cgroup/system.slice/ollama.service/cpu.max 200000 100000
OllamaのメモリとSwap使用量をsystemdで制限する手順
1. MemoryMaxとMemoryHighをoverride.confに追加する
先ほど作成したDrop-inファイルにメモリ制限の設定を追記します。$ sudo nano /etc/systemd/system/ollama.service.d/override.conf
[Service] CPUQuota=200% MemoryHigh=10G MemoryMax=12G MemorySwapMax=0
MemoryMaxの値は使用するモデルのサイズより余裕をもって設定します。Llama3.3の `llama3.3:70b-instruct-q4_0` はCPU-onlyで約40GB、Gemma 3の `gemma3:27b-instruct-q4_0` は約16GBが目安です。モデルに必要なメモリ量より2GB以上の余裕を持たせてください。
2. 設定を反映してメモリ上限を確認する
$ sudo systemctl daemon-reload && sudo systemctl restart ollama $ cat /sys/fs/cgroup/system.slice/ollama.service/memory.max 12884901888
$ systemctl show ollama | grep -E 'MemoryMax|MemoryHigh|CPUQuota' CPUQuotaPerSecUSec=2000ms MemoryHigh=10737418240 MemoryMax=12884901888
IOWeightでOllamaのディスクI/O優先度を調整する手順
モデルのロード時にOllamaは大量のディスクI/Oを発生させます。CPUやメモリと同様に、I/Oを制限しないとデータベースの書き込みを圧迫することがあります。1. IOWeightをoverride.confに追加する
$ sudo nano /etc/systemd/system/ollama.service.d/override.conf
[Service] CPUQuota=200% MemoryHigh=10G MemoryMax=12G MemorySwapMax=0 IOWeight=50
IOWeightが機能するにはブロックデバイスのI/Oスケジューラーが `bfq` または `mq-deadline` であることが必要です。現在のスケジューラーは以下で確認できます。
$ cat /sys/block/sda/queue/scheduler [mq-deadline] kyber bfq none
設定変更後は `sudo systemctl daemon-reload && sudo systemctl restart ollama` で反映します。
リソース制限の効果をcgroupfsとsystemctlで確認する手順
1. 現在の設定値をすべて一覧表示する
$ systemctl show ollama | grep -E 'CPU|Memory|IO|Tasks' CPUShares=18446744073709551615 CPUQuotaPerSecUSec=2000ms MemoryAccounting=yes MemoryMin=0 MemoryLow=0 MemoryHigh=10737418240 MemoryMax=12884901888 MemorySwapMax=0 MemoryLimit=infinity IOAccounting=yes IOWeight=50 TasksMax=infinity
2. 実際のメモリ使用量をリアルタイムで確認する
モデルをロードしながら以下のコマンドでメモリ使用量を監視できます。$ watch -n 1 "cat /sys/fs/cgroup/system.slice/ollama.service/memory.current \ | awk '{printf \"%.1f GB\n\", \$1/1024/1024/1024}'" Every 1.0s: ... 5.0 GB
3. CPU使用率の制限が効いているか確認する
cpu.maxファイルを確認します。$ cat /sys/fs/cgroup/system.slice/ollama.service/cpu.max 200000 100000
よくあるトラブルと注意が必要な設定
CPUQuotaを設定してもCPU使用率が下がらない場合
cgroup v2が有効でない古いシステムや、Dockerコンテナ内でOllamaを動かしている環境では `CPUQuota` が効かないケースがあります。まず `findmnt -t cgroup2` でcgroup v2の有効を確認してください。Dockerコンテナ上のOllamaにリソース制限をかける場合は、systemdではなくDockerの `--cpus` と `--memory` オプションを使います。
$ docker run -d --gpus=all --cpus=2 --memory=12g -v ollama:/root/.ollama \ -p 11434:11434 --name ollama ollama/ollama
MemoryMaxを設定するとOllamaが頻繁に落ちる場合
使用モデルのサイズに対してMemoryMaxが小さすぎる可能性があります。OOMキラーが発動するたびにjournalctlにログが残るので確認してください。$ journalctl -u ollama --since "1 hour ago" | grep -i "oom\|killed\|memory"
daemon-reloadを忘れると設定が反映されない
override.confを編集した後、`daemon-reload` なしでOllamaをrestartするだけでは変更前の設定が使われることがあります。Drop-inファイルを変更したら必ず以下の順で実行してください。$ sudo systemctl daemon-reload $ sudo systemctl restart ollama $ systemctl show ollama | grep -E 'MemoryMax|CPUQuota'
MemorySwapMax=0にするとモデルが使えなくなる場合
実メモリが不足している状態でMemorySwapMax=0を設定すると、モデルのロード中にOOMキラーが発動します。この場合はMemorySwapMax=2Gのように小さな値を許可するか、モデルを小さい量子化サイズ（`-q4_0`）に変更することを検討してください。本記事のまとめ
OllamaのsystemdサービスにDrop-inファイルを使ってCPU・メモリ・I/Oの上限を設定する手順を解説しました。| 設定項目 | キー名 | 設定例 |
|---|---|---|
| CPU使用率上限 | CPUQuota | CPUQuota=200%（2コア分） |
| メモリソフト制限 | MemoryHigh | MemoryHigh=10G |
| メモリハード制限 | MemoryMax | MemoryMax=12G |
| Swap書き出し禁止 | MemorySwapMax | MemorySwapMax=0 |
| I/O優先度重み | IOWeight | IOWeight=50（デフォルト100） |
複数のチームが同じサーバーを共有する環境では、モデルのサイズと同時リクエスト数に応じてMemoryMaxを調整する必要があります。Llama3.3・Mistral・Gemma 3・Phi-4の各モデルが必要とするメモリ量の目安はローカルLLMのモデルを比較する方法で確認してください。
ローカルLLMのサーバー管理技術を2日間のハンズオンで体験する
systemdのリソース制限から監視・チーム公開まで、ローカルLLMの本番運用スキルを体系的に習得したい方向けに、「ローカルAIマスターセミナー」を開催しています。
少人数（最大8名）ZOOMハンズオン形式で実施しています。
・Ubuntu ServerでローカルLLMを構築する方法｜Ollamaで機密データを外に出さず業務AIを動かす完全ガイド
・社内でChatGPTが使えないときの代替手段｜機密データを守るローカルLLMという選択肢
・ローカルLLMのモデルを比較する方法｜Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：OllamaをマルチGPU環境で動かす方法｜複数NVIDIAカードのVRAM合算で70BモデルをLinuxサーバーで稼働させる手順
- この記事の属するカテゴリ：ローカルLLMへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます