github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-07-17 05:36:16 -05:00
Code Issues 16.9k Packages Projects Releases 122 Wiki Activity

[GH-ISSUE #7387] Ollama Docker Container Disk Usage Growing Exponentially #66751

New Issue
Closed
opened 2026-05-04 08:05:05 -05:00 by GiteaMirror · 6 comments
GiteaMirror commented 2026-05-04 08:05:05 -05:00
Owner
Copy Link

Originally created by @vanduc2514 on GitHub (Oct 27, 2024).
Original GitHub issue: https://github.com/ollama/ollama/issues/7387

Originally assigned to: @dhiltgen on GitHub.

What is the issue?

I've observed significant disk usage growth within the Ollama Docker container, even when using external volume for model storage. Initially, the container occupies approximately 2GB of overlay2 disk space. However, after processing a few prompts with different models, the disk usage increases rapidly, often exceeding 5 times the initial size.

It seems like during running, ollama writes something to /tmp which increases the disk space

Container ENVs

OLLAMA_MODELS: /root/.ollama/models
OLLAMA_NUM_PARALLEL: 2
OLLAMA_FLASH_ATTENTION: true
OLLAMA_NOHISTORY: true

Here is the disk usage graph in my homelab

image

OS

WSL2

GPU

Nvidia

CPU

Intel

Ollama version

0.3.8

Originally created by @vanduc2514 on GitHub (Oct 27, 2024). Original GitHub issue: https://github.com/ollama/ollama/issues/7387 Originally assigned to: @dhiltgen on GitHub. ### What is the issue? I've observed significant disk usage growth within the Ollama Docker container, even when using external volume for model storage. Initially, the container occupies approximately 2GB of overlay2 disk space. However, after processing a few prompts with different models, the disk usage increases rapidly, often exceeding 5 times the initial size. It seems like during running, ollama writes something to `/tmp` which increases the disk space Container ENVs ```shell OLLAMA_MODELS: /root/.ollama/models OLLAMA_NUM_PARALLEL: 2 OLLAMA_FLASH_ATTENTION: true OLLAMA_NOHISTORY: true ``` Here is the disk usage graph in my homelab <img width="804" alt="image" src="https://github.com/user-attachments/assets/4ccf5d85-d907-4394-abb2-c711fb1c5d6d"> ### OS WSL2 ### GPU Nvidia ### CPU Intel ### Ollama version 0.3.8
GiteaMirror added the bugdockerlinux labels 2026-05-04 08:05:06 -05:00
GiteaMirror commented 2026-05-04 08:05:09 -05:00
Author
Owner
Copy Link

@rick-github commented on GitHub (Oct 27, 2024):

What does ollama list show?

<!-- gh-comment-id:2440206634 --> @rick-github commented on GitHub (Oct 27, 2024): What does `ollama list` show?
GiteaMirror commented 2026-05-04 08:05:09 -05:00
Author
Owner
Copy Link

@vanduc2514 commented on GitHub (Nov 1, 2024):

@rick-github

These models

image

<!-- gh-comment-id:2451229510 --> @vanduc2514 commented on GitHub (Nov 1, 2024): @rick-github These models ![image](https://github.com/user-attachments/assets/c656666c-c8c7-49f9-a87d-6bc633fdf1bb)
GiteaMirror commented 2026-05-04 08:05:11 -05:00
Author
Owner
Copy Link

@rick-github commented on GitHub (Nov 1, 2024):

Without server logs this is a bit of a guess, but I think think is the server restarting. ollama has a bunch of runners for different architectures embedded in it, these are extracted at run time to do the actual inference. By default these are stored in /tmp/ollama<pid>. If the server is restarted without restarting the container, the server will get a new and create another copy of the runners in /tmp/ollama<newpid>. I'm not sure if this is the problem though, because the default ollama docker container will exit if the server exits. If you've used the ollama image as a base for your own, that may be the reason. You can override this behaviour of a new directory for each server restart by setting OLLAMA_TMPDIR.

<!-- gh-comment-id:2451757792 --> @rick-github commented on GitHub (Nov 1, 2024): Without [server logs](https://github.com/ollama/ollama/blob/main/docs/troubleshooting.md) this is a bit of a guess, but I think think is the server restarting. ollama has a bunch of runners for different architectures embedded in it, these are extracted at run time to do the actual inference. By default these are stored in /tmp/ollama\<pid\>. If the server is restarted without restarting the container, the server will get a new <pid> and create another copy of the runners in /tmp/ollama\<newpid\>. I'm not sure if this is the problem though, because the default ollama docker container will exit if the server exits. If you've used the ollama image as a base for your own, that may be the reason. You can override this behaviour of a new directory for each server restart by setting `OLLAMA_TMPDIR`.
GiteaMirror commented 2026-05-04 08:05:13 -05:00
Author
Owner
Copy Link

@vanduc2514 commented on GitHub (Nov 4, 2024):

@rick-github Thank you for the feedback. I can't provide a server log yet due to how log handling works in my server for the time being. However, I think that could be the issue. Last time I checked /tmp contains a bunch of runner like you said. I don't restart the ollama container frequently and only re-creating the container can solve this issue. But why does ollama do this ? And why doesn't it cleanup this directory later ?

<!-- gh-comment-id:2453692440 --> @vanduc2514 commented on GitHub (Nov 4, 2024): @rick-github Thank you for the feedback. I can't provide a server log yet due to how log handling works in my server for the time being. However, I think that could be the issue. Last time I checked `/tmp` contains a bunch of runner like you said. I don't restart the `ollama` container frequently and only re-creating the container can solve this issue. But why does ollama do this ? And why doesn't it cleanup this directory later ?
GiteaMirror commented 2026-05-04 08:05:16 -05:00
Author
Owner
Copy Link

@rick-github commented on GitHub (Nov 4, 2024):

ollama does try to clean up the temp directory when it extracts runners: 18237be9b2/runners/common.go (L226)

If it's not working for you, there may be entries in the log file that explain why.

As alternative, upgrade to 0.3.13 or later where how runners are packaged has changed, and they are no longer unpacked into /tmp.

<!-- gh-comment-id:2454856582 --> @rick-github commented on GitHub (Nov 4, 2024): ollama does try to clean up the temp directory when it extracts runners: https://github.com/ollama/ollama/blob/18237be9b2a4f8b060b9888996a8cc8b02796290/runners/common.go#L226 If it's not working for you, there may be entries in the log file that explain why. As alternative, upgrade to 0.3.13 or later where how runners are packaged has changed, and they are no longer unpacked into /tmp.
GiteaMirror commented 2026-05-04 08:05:17 -05:00
Author
Owner
Copy Link

@dhiltgen commented on GitHub (Nov 5, 2024):

@vanduc2514 if you still see high disk usage in the latest version let us know and I'll reopen the issue, but this should be resolved now.

<!-- gh-comment-id:2458127658 --> @dhiltgen commented on GitHub (Nov 5, 2024): @vanduc2514 if you still see high disk usage in the latest version let us know and I'll reopen the issue, but this should be resolved now.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label bug docker linux
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#66751
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?