Mercurial > hg > orthanc

comparison OrthancServer/Resources/ImplementationNotes/memory_consumption.txt @ 5153:217863b09457 malloc-trim

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
malloc_trim doc
author Alain Mazy <am@osimis.io>
date Wed, 01 Feb 2023 19:23:58 +0100
parents
children 20911302c6e7
comparison
equal deleted inserted replaced
5152:c81f363d3aa3 5153:217863b09457
1 In Orthanc 1.11.3, we have introduced a Housekeeper thread that
2 tries to give back unused memory back to the system. This is implemented
3 by calling malloc_trim every 100ms.
4
5 Here is how we validated the effect of this new feature:
6 -------------------------------------------------------
7
8 We compared the behaviour of 2 osimis/orthanc Docker images from the mainline
9 on Feb 1st 2023. One image without the call to malloc_trim and the other with
10 this call.
11
12 1st test: unconstrained Docker containers
13 .........................................
14
15 5 large studies are uploaded to each instance of Orthanc (around 1GB in total).
16 A script triggers anonymization of these studies as quick as possible.
17 We compare the memory used by the containers after 2 minutes of execution
18 (using `docker stats`):
19 - without malloc_trim: 1500 MB
20 - with malloc_trim: 410 MB
21
22 2nd test: memory constrained Docker containers
23 ..............................................
24
25 Each Orthanc container is limited to 400MB (through the docker-compose configuration
26 `mem_limit: 400m`)
27 5 large studies are uploaded to each instance of Orthanc (around 1GB in total).
28 Each study is anonymized manually, one by one and then, we repeat the operation.
29 We compare the memory used by the containers after 2 minutes of execution
30 (using `docker stats`):
31
32 # study without malloc_trim with_malloc_trim
33 0 ~ 50 MB ~ 50 MB
34 1 ~ 140 MB ~ 140 MB
35 2 ~ 390 MB ~ 340 MB
36 3 ~ 398 MB ~ 345 MB
37 4 out-of-memory crash ~ 345 MB
38 5..20 ~ 380 MB (stable)
39
40 Note: the use of malloc_trim does not guarantee that Orthanc will never reach a
41 out-of-memory error, especially on very constrained systems.
42 Depending on the allocation pattern, the Orthanc memory can get
43 very fragmented and increase since malloc_trim only releases memory
44 at the end of each of malloc arena. However, note that, even long before the
45 introduction of malloc_trim, we have observed Orthanc instances running for years
46 without ever reaching out-of-memory errors and Orthanc is usually considered as
47 very stable.
48
49
50
51
52
53
54 malloc_trim documentation
55 -------------------------
56
57 from (https://stackoverflow.com/questions/40513716/malloc-trim0-releases-fastbins-of-thread-arenas)
58
59 If possible, gives memory back to the system (via negative
60 arguments to sbrk) if there is unused memory at the `high' end of
61 the malloc pool. You can call this after freeing large blocks of
62 memory to potentially reduce the system-level memory requirements
63 of a program. However, it cannot guarantee to reduce memory. Under
64 some allocation patterns, some large free blocks of memory will be
65 locked between two used chunks, so they cannot be given back to
66 the system.
67
68 The `pad' argument to malloc_trim represents the amount of free
69 trailing space to leave untrimmed. If this argument is zero,
70 only the minimum amount of memory to maintain internal data
71 structures will be left (one page or less). Non-zero arguments
72 can be supplied to maintain enough trailing space to service
73 future expected allocations without having to re-obtain memory
74 from the system.
75
76 Malloc_trim returns 1 if it actually released any memory, else 0.
77 On systems that do not support "negative sbrks", it will always
78 return 0.