mirror of
https://github.com/processone/ejabberd.git
synced 2024-10-07 14:58:56 +02:00
0d557566fb
(thanks to Sander Devrieze, Sergei Golovan, Torsten Werner and Badlop) * src/ejabberdctl.cfg.example: Likewise * src/ejabberd.inetrc: Likewise * src/Makefile.in: Likewise SVN Revision: 959
72 lines
2.7 KiB
Plaintext
72 lines
2.7 KiB
Plaintext
# Additional options passed to erlang while starting ejabberd.
|
|
#
|
|
#export ERL_OPTIONS="-heart"
|
|
|
|
# ERL_MAX_PORTS: Maximum number of simultaneously open Erlang ports
|
|
#
|
|
# Erlang consumes one port for every connection, either from a client or from
|
|
# another Jabber server. The option ERL_MAX_PORTS limits the number of
|
|
# concurrent connections and can be specified when starting ejabberd.
|
|
#
|
|
# Default value: 1024
|
|
# Maximum value: 268435456
|
|
|
|
export ERL_MAX_PORTS=32000
|
|
|
|
# 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
|
|
|
|
# PROCESSES: Maximum number of Erlang processes (default=32768, max=268435456)
|
|
#
|
|
# 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.
|
|
|
|
#PROCESSES="+P 32768"
|
|
|
|
# POLL: Kernel polling (-K true)
|
|
#
|
|
# The kernel polling option requires that you have support for it in your
|
|
# kernel. By default, Erlang currently supports kernel polling under FreeBSD,
|
|
# Mac OS X, and Solaris. If you use Linux, you need to apply a patch.
|
|
# Additionaly, you need to enable this feature while compiling Erlang.
|
|
|
|
#POLL="-K true"
|
|
|
|
# ERL_MAX_ETS_TABLES: Maximum number of ETS and Mnesia tables (default=1400)
|
|
#
|
|
# 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.
|
|
|
|
ERL_MAX_ETS_TABLES="-env ERL_MAX_ETS_TABLES 1400"
|
|
|
|
# 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
|