7.3.18. database_unmap¶
7.3.18.1. Summary¶
New in version 5.0.7.
database_unmap unmaps already mapped tables and columns in the
database. “Map” means that loading from disk to memory. “Unmap” means
that releasing mapped memory.
Note
Normally, you don’t need to use database_unmap because OS
manages memory cleverly. If remained system memory is reduced, OS
moves memory used by Groonga to disk until Groonga needs the
memory. OS moves unused memory preferentially.
Caution
You can use this command only when thread_limit returns
1. It means that this command doesn’t work with multithreading.
7.3.18.2. Syntax¶
This command takes no parameters:
database_unmap
7.3.18.3. Usage¶
You can unmap database after you change the max number of threads to
1:
Execution example:
thread_limit --max 1
# [[0, 1337566253.89858, 0.000355720520019531], 2]
database_unmap
# [[0, 1337566253.89858, 0.000355720520019531], true]
If the max number of threads is larger than 1, database_unmap
fails:
Execution example:
thread_limit --max 2
# [[0, 1337566253.89858, 0.000355720520019531], 1]
database_unmap
# [
# [
# -2,
# 1337566253.89858,
# 0.000355720520019531,
# "[database_unmap] the max number of threads must be 1: <2>",
# [
# [
# "proc_database_unmap",
# "proc.c",
# 3705
# ]
# ]
# ],
# false
# ]
7.3.18.4. Parameters¶
This section describes all parameters.
7.3.18.4.1. Required parameters¶
There is no required parameter.
7.3.18.4.2. Optional parameters¶
There is no optional parameter.
7.3.18.5. Return value¶
The command returns true as body on success such as:
[HEADER, true]
If the command fails, error details are in HEADER.
See Output format for HEADER.