|
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
|
|
|
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.
|
