Mercurial > hg > orthanc
comparison OrthancServer/Resources/ImplementationNotes/memory_consumption.txt @ 5153:217863b09457 malloc-trim
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. |