Skip to content
Snippets Groups Projects
Commit c726afa2 authored by Konstantin Osipov's avatar Konstantin Osipov
Browse files

User guide: extend the language reference. 

Extend language-reference.xml.
Minor edits of salloc.m.
parent ee57c04c
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
core/salloc.m
+ 3
− 3
View file @ c726afa2
...@@ -191,7 +191,7 @@ format_slab(struct slab_class *class, struct slab *slab) ...@@ -191,7 +191,7 @@ format_slab(struct slab_class *class, struct slab *slab)
} }
static bool static bool
full_formated(struct slab *slab) fully_formatted(struct slab *slab)
{ {
return slab->brk + slab->class->item_size >= (void *)slab + SLAB_SIZE; return slab->brk + slab->class->item_size >= (void *)slab + SLAB_SIZE;
} }
...@@ -284,7 +284,7 @@ salloc(size_t size) ...@@ -284,7 +284,7 @@ salloc(size_t size)
VALGRIND_MAKE_MEM_UNDEFINED(item, sizeof(void *)); VALGRIND_MAKE_MEM_UNDEFINED(item, sizeof(void *));
} }
if (full_formated(slab) && slab->free == NULL) if (fully_formatted(slab) && slab->free == NULL)
TAILQ_REMOVE(&class->free_slabs, slab, class_free_link); TAILQ_REMOVE(&class->free_slabs, slab, class_free_link);
slab->used += class->item_size + sizeof(red_zone); slab->used += class->item_size + sizeof(red_zone);
...@@ -302,7 +302,7 @@ sfree(void *ptr) ...@@ -302,7 +302,7 @@ sfree(void *ptr)
struct slab_class *class = slab->class; struct slab_class *class = slab->class;
struct slab_item *item = ptr; struct slab_item *item = ptr;
if (full_formated(slab) && slab->free == NULL) if (fully_formatted(slab) && slab->free == NULL)
TAILQ_INSERT_TAIL(&class->free_slabs, slab, class_free_link); TAILQ_INSERT_TAIL(&class->free_slabs, slab, class_free_link);
assert(valid_item(slab, item)); assert(valid_item(slab, item));
......
doc/user/language-reference.xml
+ 139
− 28
View file @ c726afa2
...@@ -144,34 +144,145 @@ ...@@ -144,34 +144,145 @@
administrative console. A reference description also follows administrative console. A reference description also follows
below:</para> below:</para>
<para><emphasis xml:id="reload-configuration" xreflabel="RELOAD CONFIGURATION" role="tntadmin">reload <variablelist>
configuration</emphasis> Re-read the configuration file. If the
file contains changes to dynamic parameters, update the runtime <varlistentry>
settings. If configuration syntax is incorrect, or a read-only parameter is changed, produce an error and do nothing.</para> <term xml:id="save-snapshot" xreflabel="SAVE SNAPSHOT">
<para><emphasis xml:id="show-configuration" xreflabel="SHOW CONFIGURATION" role="tntadmin">show configuration</emphasis> Show the current settings. Displays all <emphasis role="tntadmin">save snapshot</emphasis>
settings, including those that have default values and thus are </term>
not necessarily present in the configuration file.</para> <listitem><para>
Take a snapshot of all data and store it in
<para><emphasis xml:id="save-snapshot" xreflabel="SAVE SNAPSHOT" <filename><olink
role="tntadmin">save snaspshot</emphasis> targetptr="snap_dir"/>/&lt;latest-lsn&gt;.snap</filename>.
Take a snapshot of all data and store it in To take a snapshot, Tarantool forks and quickly
<filename><olink targetptr="snap_dir"/>/&lt;latest-lsn&gt;.snap</filename>. <function>munmap(2)</function>s all memory except one that
To take a snapshot, Tarantool forks and quickly stores tuples. Since all modern operating systems support
<function>munmap(2)</function>s all virtual memory copy-on-write, this effectively creates a
memory except one that stores tuples. Since all modern operating consistent snapshot of all tuples in the child process,
systems support virtual memory copy-on-write, this effectively which is then written to disk tuple by tuple. Since a
creates a consistent snapshot of all tuples in the child snapshot is written sequentially, you can expect a very
process, which is then written to disk tuple by tuple. Since a high write performance (averaging to 70MB/second on modern
snapshot is written disks), which means an average database instance gets
sequentially, you can expect a very high write performance saved in a matter of minutes. Note, that as long as there
(averaging to 70MB/second on modern disks), which means an are any changes to the parent memory through concurrent
average database instance gets saved in a matter of minutes. updates, there are going to be page splits, and therefore
Note, that as long as there are any changes to the parent you need to have some extra free memory to run this
memory through concurrent updates, there are going to be page command. 15%-30% of <olink targetptr="slab_alloc_arena"/>
splits, and therefore you need to have some extra free memory is, on average, sufficient.
to run this command. 15%-30% of <olink </para></listitem>
targetptr="slab_alloc_arena"/> is, on average, sufficient. </varlistentry>
</para>
<varlistentry>
<term xml:id="reload-configuration" xreflabel="RELOAD CONFIGURATION">
<emphasis role="tntadmin">reload configuration</emphasis>
</term>
<listitem><para>
Re-read the configuration file. If the file contains
changes to dynamic parameters, update the runtime
settings. If configuration syntax is incorrect, or a
read-only parameter is changed, produce an error and do
nothing.
</para></listitem>
</varlistentry>
<varlistentry>
<term xml:id="show-configuration" xreflabel="SHOW CONFIGURATION">
<emphasis role="tntadmin">show configuration</emphasis>
</term>
<listitem><para>
Show the current settings. Displays all settings,
including those that have default values and thus are not
necessarily present in the configuration file.
</para></listitem>
</varlistentry>
<varlistentry>
<term xml:id="show-info" xreflabel="SHOW INFO">
<emphasis role="tntadmin">show info</emphasis>
</term>
<listitem><para>
<programlisting>
tarantool> show info
---
info:
version: "1.4.0-30-ge500b95"
uptime: 441524
pid: 16180
wal_writer_pid: 16182
lsn: 15481913304
recovery_lag: 0.000
recovery_last_update: 1306964594.980
status: primary
</programlisting>
</para></listitem>
</varlistentry>
<varlistentry>
<term xml:id="show-stat" xreflabel="SHOW STAT">
<emphasis role="tntadmin">show stat</emphasis>
</term>
<listitem><para>
<programlisting>
tarantool> show stat
---
statistics:
INSERT: { rps: 139 , total: 48207694 }
SELECT_LIMIT: { rps: 0 , total: 0 }
SELECT: { rps: 1246 , total: 388322317 }
UPDATE_FIELDS: { rps: 1874 , total: 743350520 }
DELETE: { rps: 147 , total: 48902544 }
</programlisting>
</para></listitem>
</varlistentry>
<varlistentry>
<term xml:id="show-slab" xreflabel="SHOW SLAB">
<emphasis role="tntadmin">show slab</emphasis>
</term>
<listitem><para>
Show the statistics of slab allocator. The slab allocator
is the main allocator used to store tuples. This can be
used to monitor the total memory use and memory
fragmentation.
</para></listitem>
</varlistentry>
<varlistentry>
<term xml:id="show-palloc" xreflabel="SHOW PALLOC">
<emphasis role="tntadmin">show palloc</emphasis>
</term>
<listitem><para>
A pool allocator is used for temporary memory, when
serving client requests. Every fiber has an own
pool. Shows the current state of pools of all fibers.
</para></listitem>
</varlistentry>
<varlistentry>
<term xml:id="save-coredump" xreflabel="SAVE COREDUMP">
<emphasis role="tntadmin">SAVE COREDUMP</emphasis>
</term>
<listitem><para>
Fork and dump a core. Since Tarantool stores all tuples
in memory, it can take some time. Mainly useful for
debugging.
</para></listitem>
</varlistentry>
<varlistentry>
<term xml:id="show-fiber" xreflabel="SHOW FIBER">
<emphasis role="tntadmin">show fiber</emphasis>
</term>
<listitem><para>
Show all running fibers, with their stack.
Mainly useful for debugging.
</para></listitem>
</varlistentry>
</variablelist>
</section> </section>
</chapter> </chapter>
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment