Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPFS with cluster-follower run out of memory and got killed by OOM-Job #7292

Closed
RubenKelevra opened this issue May 8, 2020 · 4 comments · Fixed by #7299
Closed

IPFS with cluster-follower run out of memory and got killed by OOM-Job #7292

RubenKelevra opened this issue May 8, 2020 · 4 comments · Fixed by #7299
Labels
kind/bug A bug in existing code (including security flaws) status/duplicate This issue or pull request already exists

Comments

@RubenKelevra
Copy link
Contributor

Version information:

go-ipfs version: 0.5.0-rc3-8cb67ab
Repo version: 9
System version: amd64/linux
Golang version: go1.14.2

Description:

I run an ipfs client and a cluster-follower on a VM on CentOS 7. This machine has two AMD EPYC 7551 32-Core Processor cores and 1 GB of memory. The machine has 8 GB of swap.

The machine run out of memory, so 8 GB of swap and 1 GB of RAM got filled by IPFS until IPFS got killed from the OOM job of the kernel.

Sadly journalctl dropped more than 100,000 lines from the stack trace, hope it's helpful anyway (it's attached).

The screen in which I had run the cluster-follower also printed a stack trace, I attach this as well.

The cluster I was following is the pacman.store collab cluster.

stacktrace_cluster_follower.txt
out_of_memory_stacktrace_ipfs.txt

@RubenKelevra RubenKelevra added kind/bug A bug in existing code (including security flaws) need/triage Needs initial labeling and prioritization labels May 8, 2020
@Stebalien
Copy link
Member

Swap is basically useless to IPFS and is likely the cause of your problem. What's your swappiness set to?

@RubenKelevra
Copy link
Contributor Author

What's your swappiness set to?

Swappiness is 90.

Swap is basically useless to IPFS and is likely the cause of your problem.

The machine just runs IPFS and one cluster follower, nothing else (except a sshd) - when IPFS is not running, the machine uses 60 MB of memory.

I understand that Go has a garbage collector which is probably not optimized for daemon like IPFS and might up cluttering the memory into small chunks. But I thought with enough memory pressure the kernel would clean up and no longer used space from go. How is the kernel unable to regain the space used by IPFS and completely fill up the 8 GB swap file with it?

Free swap = 52kB

@Stebalien Stebalien added status/duplicate This issue or pull request already exists and removed need/triage Needs initial labeling and prioritization labels May 9, 2020
@Stebalien
Copy link
Member

TL;DR: go-ipfs can instantly fill up 1GiB of memory due to ipfs/go-ds-badger#86. When that happens, it's game over.

Also note, with a swappiness of 90 and 1GiB of memory, Linux will start swapping a 10% memory usage. You should probably set it to something like 1 or 10.

However, if you're only running go-ipfs, you should just disable swap.


Some context:

Anything that touches swapped out memory will slow to a crawl. Unfortunately, this applies more to closing connections than it does to forming connections because we need to touch a bunch of different state to close a connection while forming a connection usually touches shared state (keys, etc.) likely to be kept in-memory.

Basically, this issue is #1482.

@RubenKelevra
Copy link
Contributor Author

In this case, we should just disable swapping for IPFS, right? 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug A bug in existing code (including security flaws) status/duplicate This issue or pull request already exists
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants