1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
.TH erts_alloc_config 3 "runtime_tools 1.7.2" "Ericsson AB" "ERLANG MODULE DEFINITION"
.SH MODULE
erts_alloc_config \- Configuration tool for erts_alloc
.SH DESCRIPTION
.SS Note:
.LP
\fIerts_alloc_config\fR is currently an experimental tool and might be subject to backward incompatible changes\&.
.LP
erts_alloc(3) is an Erlang Run-Time System internal memory allocator library\&. \fIerts_alloc_config\fR is intended to be used to aid creation of an erts_alloc(3) configuration that is suitable for a limited number of runtime scenarios\&. The configuration that \fIerts_alloc_config\fR produce is intended as a suggestion, and may need to be adjusted manually\&.
.LP
The configuration is created based on information about a number of runtime scenarios\&. It is obviously impossible to forsee every runtime scenario that can occur\&. The important scenarios are those that cause maximum or minimum load on specific memory allocators\&. Load in this context is total size of memory blocks allocated\&.
.LP
The current implementation of \fIerts_alloc_config\fR concentrate on configuration of multi-block carriers\&. Information gathered when a runtime scenario is saved is mainly current and maximum use of multi-block carriers\&. If a parameter that change the use of multi-block carriers is changed, a previously generated configuration is invalid and \fIerts_alloc_config\fR needs to be run again\&. It is mainly the single block carrier threshold that effects the use of multi-block carriers, but other single-block carrier parameters might as well\&. If another value of a single block carrier parameter than the default is desired, use the desired value when running \fIerts_alloc_config\fR\&.
.LP
A configuration is created in the following way:
.RS 2
.TP 2
*
Pass the +Mea config command-line flag to the Erlang runtime system you are going to use for creation of the allocator configuration\&. It will disable features that prevent \fIerts_alloc_config\fR from doing it\&'s job\&. Note, you should \fInot\fR use this flag when using the created configuration\&. Also note that it is important that you use the same amount of schedulers when creating the configuration as you are going the use on the system using the configuration\&.
.TP 2
*
Run your applications with different scenarios (the more the better) and save information about each scenario by calling save_scenario/0\&. It may be hard to know when the applications are at an (for \fIerts_alloc_config\fR) important runtime scenario\&. A good approach may therefore be to call save_scenario/0 repeatedly, e\&.g\&. once every tenth second\&. Note that it is important that your applications reach the runtime scenarios that are important for \fIerts_alloc_config\fR when you are saving scenarios; otherwise, the configuration may perform bad\&.
.TP 2
*
When you have covered all scenarios, call make_config/1 in order to create a configuration\&. The configuration is written to a file that you have chosen\&. This configuration file can later be read by an Erlang runtime-system at startup\&. Pass the command line argument -args_file FileName to the erl(1) command\&.
.TP 2
*
The configuration produced by \fIerts_alloc_config\fR may need to be manually adjusted as already stated\&. Do not modify the file produced by \fIerts_alloc_config\fR; instead, put your modifications in another file and load this file after the file produced by \fIerts_alloc_config\fR\&. That is, put the -args_file FileName argument that reads your modification file later on the command-line than the -args_file FileName argument that reads the configuration file produced by \fIerts_alloc_config\fR\&. If a memory allocation parameter appear multiple times, the last version of will be used, i\&.e\&., you can override parameters in the configuration file produced by \fIerts_alloc_config\fR\&. Doing it this way simplifies things when you want to rerun \fIerts_alloc_config\fR\&.
.RE
.SS Note:
.LP
The configuration created by \fIerts_alloc_config\fR may perform bad, ever horrible, for runtime scenarios that are very different from the ones saved when creating the configuration\&. You are, therefore, advised to rerun \fIerts_alloc_config\fR if the applications run when the configuration was made are changed, or if the load on the applications have changed since the configuration was made\&. You are also advised to rerun \fIerts_alloc_config\fR if the Erlang runtime system used is changed\&.
.LP
\fIerts_alloc_config\fR saves information about runtime scenarios and performs computations in a server that is automatically started\&. The server register itself under the name \fI\&'__erts_alloc_config__\&'\fR\&.
.SH EXPORTS
.LP
.B
save_scenario() -> ok | {error, Error}
.br
.RS
.TP
Types
Error = term()
.br
.RE
.RS
.LP
\fIsave_scenario/0\fR saves information about the current runtime scenario\&. This information will later be used when make_config/0, or make_config/1 is called\&.
.LP
The first time \fIsave_scenario/0\fR is called a server will be started\&. This server will save runtime scenarios\&. All saved scenarios can be removed by calling stop/0\&.
.RE
.LP
.B
make_config() -> ok | {error, Error}
.br
.RS
.TP
Types
Error = term()
.br
.RE
.RS
.LP
This is the same as calling make_config(group_leader())\&.
.RE
.LP
.B
make_config(FileNameOrIODev) -> ok | {error, Error}
.br
.RS
.TP
Types
FileNameOrIODev = string() | io_device()
.br
Error = term()
.br
.RE
.RS
.LP
\fImake_config/1\fR uses the information previously saved by save_scenario/0 in order to produce an \fIerts_alloc\fR configuration\&. At least one scenario have had to be saved\&. All scenarios previously saved will be used when creating the configuration\&.
.LP
If \fIFileNameOrIODev\fR is a \fIstring()\fR, \fImake_config/1\fR will use \fIFileNameOrIODev\fR as a filename\&. A file named \fIFileNameOrIODev\fR is created and the configuration will be written to that file\&. If \fIFileNameOrIODev\fR is an io_device() (see the documentation of the module io), the configuration will be written to the io device\&.
.RE
.LP
.B
stop() -> ok | {error, Error}
.br
.RS
.TP
Types
Error = term()
.br
.RE
.RS
.LP
Stops the server that saves runtime scenarios\&.
.RE
.SH SEE ALSO
.LP
erts_alloc(3), erl(1), io(3)
|
