Mercurial > hg > orthanc-book

comparison Sphinx/source/faq/scalability.rst @ 384:e4b0a4d69f42

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
note about memory usage
author Sebastien Jodogne <s.jodogne@gmail.com>
date Thu, 16 Apr 2020 12:13:49 +0200
parents a5f7fc9fb611
children 0fb9369e893e
comparison
equal deleted inserted replaced
382:64b32cb19571 384:e4b0a4d69f42
1 .. _scalability: 1 .. _scalability:
2 2
3 Scalability of Orthanc 3 Scalability of Orthanc
4 ====================== 4 ======================
5
6 .. contents::
7
8 Overview
9 --------
5 10
6 One of the most common question about Orthanc is: *"How many DICOM 11 One of the most common question about Orthanc is: *"How many DICOM
7 instances can be stored by Orthanc?"* 12 instances can be stored by Orthanc?"*
8 13
9 The source code of Orthanc imposes no such hard limit by itself. 14 The source code of Orthanc imposes no such hard limit by itself.
37 of DICOM instances (check out the :ref:`postgresql` and 42 of DICOM instances (check out the :ref:`postgresql` and
38 :ref:`mysql`). It is also true that the performance of Orthanc in the 43 :ref:`mysql`). It is also true that the performance of Orthanc in the
39 presence of large databases has continuously improved over time, 44 presence of large databases has continuously improved over time,
40 especially when it comes to the speed of :ref:`DICOM C-FIND 45 especially when it comes to the speed of :ref:`DICOM C-FIND
41 <dicom-find>`. 46 <dicom-find>`.
47
48
49 .. _scalability-setup:
50
51 Recommended setup for best performance
52 --------------------------------------
42 53
43 Here is a generic setup that should provide best performance in the 54 Here is a generic setup that should provide best performance in the
44 presence of large databases: 55 presence of large databases:
45 56
46 * Make sure to use the latest release of Orthanc (1.6.0 at the time of 57 * Make sure to use the latest release of Orthanc (1.6.0 at the time of
100 space becomes needed. 111 space becomes needed.
101 112
102 * If using the :ref:`DICOMweb server plugin <dicomweb-server-config>`, 113 * If using the :ref:`DICOMweb server plugin <dicomweb-server-config>`,
103 consider setting configuration option ``StudiesMetadata`` to 114 consider setting configuration option ``StudiesMetadata`` to
104 ``MainDicomTags``. 115 ``MainDicomTags``.
116
117
118 .. _scalability-memory:
119
120 Controlling memory usage
121 ------------------------
122
123 The absence of memory leaks in Orthanc is verified thanks to `valgrind
124 <https://valgrind.org/>`__.
125
126 On GNU/Linux systems, you might however `observe a large memory
127 consumption
128 <https://groups.google.com/d/msg/orthanc-users/qWqxpvCPv8g/47wnYyhOCAAJ>`__
129 in the "resident set size" (VmRSS) of the application, notably if you
130 upload multiple large DICOM files using the REST API.
131
132 This large memory consumption comes from the fact that the embedded
133 HTTP server is heavily multi-threaded, and that many so-called `memory
134 arenas <https://sourceware.org/glibc/wiki/MallocInternals>`__ are
135 created by the glibc standard library (up to one per thread). As a
136 consequence, if each one of the 50 threads in the HTTP server of
137 Orthanc (this was the default value in Orthanc <= 1.6.0) allocates at
138 some point, say, 50MB, the total memory usage reported as "VmRSS" can
139 grow up to 50 threads x 50MB = 2.5GB, even if the Orthanc threads
140 properly free all the buffers.
141
142 .. highlight:: bash
143
144 A possible solution to reducing this memory usage is to ask glibc to
145 limit the number of "memory arenas" that are used by the Orthanc
146 process. On GNU/Linux, this can be controlled by setting the
147 environment variable ``MALLOC_ARENA_MAX``. For instance, the following
148 bash command-line would use one single arena that is shared by all the
149 threads in Orthanc::
150
151 $ MALLOC_ARENA_MAX=1 ./Orthanc
152
153 Obviously, this restrictive setting will use minimal memory, but will
154 result in contention among the threads. A good compromise might be to
155 use 5 arenas::
156
157 $ MALLOC_ARENA_MAX=5 ./Orthanc
158
159 Memory allocation on GNU/Linux is a complex topic. There are other
160 options available as environment variables that could also reduce
161 memory consumption (for instance, ``MALLOC_MMAP_THRESHOLD_`` would
162 bypass arenas for large memory blocks such as DICOM files). Check out
163 the `manpage <http://man7.org/linux/man-pages/man3/mallopt.3.html>`__
164 of ``mallopt()`` for more information.