Multiple server processes are used in a Solr full-text environment:
-
Solr standalone server (full-text indexing and search)
-
ImageMaster application server (WildFly)
-
Tika Server (text extraction from binary documents – since Solr 10)
On all servers you must ensure that enough OS resources are available in production environments.
Recommended minimum limits
|
Limit |
Description |
Recommended minimum |
|---|---|---|
|
nofile |
Number of open files |
65536 |
|
nproc |
Number of max user processes |
65536 |
|
Table 328: Recommended minimum limits |
||
Why: Solr opens many index segment files simultaneously. The default Linux limit of 1024 open files is insufficient and will cause “Too many open files” errors under production load.
Option A: /etc/security/limits.conf (traditional)
Identify the process owners for each server. Example assumptions:
|
Server |
Process owner |
|---|---|
|
Solr standalone server |
solradm |
|
ImageMaster application server |
imaadm |
|
Tika Server (since Solr 10) |
solradm (or tikaadm if separate) |
Add the following to /etc/security/limits.conf:
# Solr + Tika Server settings for user solradm solradm hard nofile 65536 solradm soft nofile 65536 solradm hard nproc 65536 solradm soft nproc 65536 # ImageMaster application server settings for user imaadm imaadm hard nofile 65536 imaadm soft nofile 65536 imaadm hard nproc 65536 imaadm soft nproc 65536
Option B: systemd service unit (modern Linux)
If Solr and/or Tika run as systemd services, limits in /etc/security/limits.conf may be ignored - systemd manages its own limits per service. Instead, add the limits directly to the service unit file:
# /etc/systemd/system/solr.service (or override via systemctl edit solr) [Service] LimitNOFILE=65536 LimitNPROC=65536 # /etc/systemd/system/tika.service [Service] LimitNOFILE=65536 LimitNPROC=65536
After editing, reload and restart:
systemctl daemon-reload systemctl restart solr systemctl restart tika
Option C: Solr’s built-in SOLR_ULIMIT_CHECKS
Solr’s bin/solr.in.sh can automatically check and set ulimit at startup. Ensure the following is set (or uncommented) in bin/solr.in.sh:
SOLR_ULIMIT_CHECKS=true
This causes Solr to warn at startup if limits are too low. However, it can only raise the soft limit up to the hard limit – it cannot increase the hard limit itself. Therefore, you still need Option A or B to set the hard limit.
Verifying Current Limits
Use ulimit to check the effective limits for the process owner:
# Check hard limits (the actual enforced maximum) su - solradm -c "ulimit -Hn" # open files (hard) su - solradm -c "ulimit -Hu" # max processes (hard) # Check soft limits (currently active - may be lower) su - solradm -c "ulimit -Sn" # open files (soft) su - solradm -c "ulimit -Su" # max processes (soft)
Expected output (after configuration):
65536
If you see 1024 (the default), the limits have not been applied correctly.
For a running Solr process, you can also check via /proc:
cat /proc/$(pgrep -f "solr")/limits | grep "open files"