5153
|
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
|
5155
|
40 3nd test: memory constrained Docker containers
|
|
41 ..............................................
|
|
42
|
|
43 In this last test, we lowered the memory allocation to 300MB and have been able to
|
|
44 run the first test script for at least 7 minutes (we did not try longer !). The
|
|
45 consumed memory is most of the time around 99% but it seems that the memory constrain
|
|
46 is handled correctly. Note that, in this configuration, 128 MB are used by the Dicom
|
|
47 Cache.
|
|
48
|
|
49 The same test without malloc_trim could never run for more than 35 seconds.
|
|
50
|
|
51
|
|
52 Note:
|
|
53 ----
|
|
54
|
|
55 The use of malloc_trim does not guarantee that Orthanc will never reach a
|
5153
|
56 out-of-memory error, especially on very constrained systems.
|
|
57 Depending on the allocation pattern, the Orthanc memory can get
|
|
58 very fragmented and increase since malloc_trim only releases memory
|
|
59 at the end of each of malloc arena. However, note that, even long before the
|
|
60 introduction of malloc_trim, we have observed Orthanc instances running for years
|
|
61 without ever reaching out-of-memory errors and Orthanc is usually considered as
|
|
62 very stable.
|
|
63
|
|
64
|
|
65
|
|
66
|
|
67
|
|
68
|
|
69 malloc_trim documentation
|
|
70 -------------------------
|
|
71
|
|
72 from (https://stackoverflow.com/questions/40513716/malloc-trim0-releases-fastbins-of-thread-arenas)
|
|
73
|
|
74 If possible, gives memory back to the system (via negative
|
|
75 arguments to sbrk) if there is unused memory at the `high' end of
|
|
76 the malloc pool. You can call this after freeing large blocks of
|
|
77 memory to potentially reduce the system-level memory requirements
|
|
78 of a program. However, it cannot guarantee to reduce memory. Under
|
|
79 some allocation patterns, some large free blocks of memory will be
|
|
80 locked between two used chunks, so they cannot be given back to
|
|
81 the system.
|
|
82
|
|
83 The `pad' argument to malloc_trim represents the amount of free
|
|
84 trailing space to leave untrimmed. If this argument is zero,
|
|
85 only the minimum amount of memory to maintain internal data
|
|
86 structures will be left (one page or less). Non-zero arguments
|
|
87 can be supplied to maintain enough trailing space to service
|
|
88 future expected allocations without having to re-obtain memory
|
|
89 from the system.
|
|
90
|
|
91 Malloc_trim returns 1 if it actually released any memory, else 0.
|
|
92 On systems that do not support "negative sbrks", it will always
|
|
93 return 0.
|