mirror of
https://github.com/processone/ejabberd.git
synced 2024-12-24 17:29:28 +01:00
90 lines
3.1 KiB
Plaintext
90 lines
3.1 KiB
Plaintext
#
|
|
# In this file you can configure options that are passed by ejabberdctl
|
|
# to the erlang runtime system when starting ejabberd
|
|
#
|
|
|
|
# POLL: Kernel polling (+K [true|false])
|
|
#
|
|
# The kernel polling option requires support in the kernel.
|
|
# Additionaly, you need to enable this feature while compiling Erlang.
|
|
#
|
|
# Default: +K false
|
|
#
|
|
#POLL="+K true"
|
|
|
|
# SMP: SMP support (-smp [enable|auto|disable])
|
|
#
|
|
# Explanation in Erlang/OTP documentation:
|
|
# enable: starts the Erlang runtime system with SMP support enabled.
|
|
# This may fail if no runtime system with SMP support is available.
|
|
# auto: starts the Erlang runtime system with SMP support enabled if it
|
|
# is available and more than one logical processor are detected.
|
|
# disable: starts a runtime system without SMP support.
|
|
#
|
|
# Default: -smp disable
|
|
#
|
|
#SMP="-smp auto"
|
|
|
|
# ERL_MAX_PORTS: Maximum number of simultaneously open Erlang ports
|
|
#
|
|
# ejabberd consumes two or three ports for every connection, either
|
|
# from a client or from another Jabber server. So take this into
|
|
# account when setting this limit.
|
|
#
|
|
# Default: 1024
|
|
# Maximum: 268435456
|
|
#
|
|
export ERL_MAX_PORTS=32000
|
|
|
|
# PROCESSES: Maximum number of Erlang processes
|
|
#
|
|
# Erlang consumes a lot of lightweight processes. If there is a lot of activity
|
|
# on ejabberd so that the maximum number of proccesses is reached, people will
|
|
# experiment greater latency times. As these processes are implemented in
|
|
# Erlang, and therefore not related to the operating system processes, you do
|
|
# not have to worry about allowing a huge number of them.
|
|
#
|
|
# Default: 32768
|
|
# Maximum: 268435456
|
|
#
|
|
#PROCESSES="+P 32768"
|
|
|
|
# ERL_MAX_ETS_TABLES: Maximum number of ETS and Mnesia tables
|
|
#
|
|
# The number of concurrent ETS and Mnesia tables is limited. When the limit is
|
|
# reached, errors will appear in the logs:
|
|
# ** Too many db tables **
|
|
# You can safely increase this limit when starting ejabberd. It impacts memory
|
|
# consumption but the difference will be quite small.
|
|
#
|
|
# Default: 1400
|
|
#
|
|
#ERL_MAX_ETS_TABLES="-env ERL_MAX_ETS_TABLES 1400"
|
|
|
|
# ERL_FULLSWEEP_AFTER: Maximum number of collections before a forced fullsweep
|
|
#
|
|
# To reduce memory usage, you can set environment variable ERL_FULLSWEEP_AFTER.
|
|
# But in this case ejabberd may work slower.
|
|
#
|
|
# The ERL_FULLSWEEP_AFTER option shrinks the size of the Erlang process after
|
|
# RAM intensive events. Note that this option may downgrade performance. Hence
|
|
# this option is only interesting on machines that also host other services
|
|
# (webserver, mail) on which ejabberd does not receive constant load.
|
|
#
|
|
# Default: 65535
|
|
#
|
|
#export ERL_FULLSWEEP_AFTER=0
|
|
|
|
# The next variable allows to explicitly specify erlang node for ejabberd
|
|
# It can be given in different formats:
|
|
# ERLANG_NODE=ejabberd
|
|
# Lets erlang add hostname to the node (ejabberd uses short name in this case)
|
|
# ERLANG_NODE=ejabberd@hostname
|
|
# Erlang uses node name as is (so make sure that hostname is a real
|
|
# machine hostname or you'll not be able to control ejabberd)
|
|
# ERLANG_NODE=ejabberd@hostname.domainname
|
|
# The same as previous, but erlang will use long hostname
|
|
# (see erl (1) manual for details)
|
|
#
|
|
#export ERLANG_NODE=ejabberd
|