Mercurial > hg > orthanc-book
comparison Sphinx/source/faq/scalability.rst @ 384:e4b0a4d69f42
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. |