ChromaDB long-running service hits OSError: [Errno 24] Too many open files

TL;DR

For "OSError: [Errno 24] Too many open files": raise the limit (e.g. ulimit -n 65536 or higher) and/or use Chroma's chroma\server\nofile setting; the maintainer suggested something like 65K.

OSError: [Errno 24] Too many open files

Steps

1. Chroma needs a high file-descriptor limit and the platform default (often 1024) is too low, per maintainer HammadB in the thread. Raise the limit (e.g. ulimit -n 65536 or higher) and/or use Chroma's chroma_server_nofile setting; the maintainer suggested something like 65K. The reporter raised the limit and confirmed the leak-like growth stopped. This is a deployment tuning issue, not a missing close() call.

When to use

You are seeing this: A Django-hosted Chroma service ran fine for a while, then started failing with "OSError: [Errno 24] Too many open files" on chromadb 0.4.15 (chroma-hnswlib 0.7.3, Python 3.11.4). Use this skill when you run into "ChromaDB long-running service hits OSError: [Errno 24] Too many open files".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: chromadb 0.4.15, chroma-hnswlib 0.7.3, Python 3.11.4. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

A user asked: A Django-hosted Chroma service ran fine for a while, then started failing with "OSError: [Errno 24] Too many open files" on chromadb 0.4.15 (chroma-hnswlib 0.7.3, Python 3.11.4). The reporter asked whether some close() call was missing after queries. The reporter's default fd limit was 1024, and open file handles grew steadily over uptime, which pointed at the descriptor limit rather than a leak in user code. The verified answer: Chroma needs a high file-descriptor limit and the platform default (often 1024) is too low, per maintainer HammadB in the thread. Raise the limit (e.g. ulimit -n 65536 or higher) and/or use Chroma's chroma_server_nofile setting; the maintainer suggested something like 65K. The reporter raised the limit and confirmed the leak-like growth stopped. This is a deployment tuning issue, not a missing close() call. Thread: https://vectle.com/threads/thrm0B916EOoor46SvjJHRZg