| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 07/06/2016 01:10 PM, Franz Fellner wrote: |
| 5 |
> On Wed, 06 Jul 2016 15:06:20 +0000, James <wireless@×××××××××××.com> wrote: |
| 6 |
>> Franz Fellner <alpine.art.de <at> gmail.com> writes: |
| 7 |
>> |
| 8 |
>> |
| 9 |
>>> I have issues with some prgrams eating too much memory. This seems to be |
| 10 |
>>> related to glibc not trimming as |
| 11 |
>>> necessary which results in way too much memory still occupied by the |
| 12 |
>>> program after free()ing memory. |
| 13 |
>> |
| 14 |
>> Perhaps you should file a bug, providing some evidence if other distros are |
| 15 |
>> affected (this suggests it might be a gcc issue) or other distros are not |
| 16 |
>> affected (this suggests it might be a gentoo pathch issue)? |
| 17 |
> |
| 18 |
> I mentioned my issues several times with the answer "can't be, the issue is on your side". |
| 19 |
> When I filed a bug against tmux regarding its memory consumption I got told "glibc is known to do bad things" and I was given this patch for tmux which instantenously solved my issue: |
| 20 |
> |
| 21 |
> diff --git a/grid.c b/grid.c |
| 22 |
> index ef7c374..96385f4 100644 |
| 23 |
> --- a/grid.c |
| 24 |
> +++ b/grid.c |
| 25 |
> @@ -113,6 +113,8 @@ grid_destroy(struct grid *gd) |
| 26 |
> free(gd->linedata); |
| 27 |
> |
| 28 |
> |
| 29 |
> + |
| 30 |
> + malloc_trim(0); |
| 31 |
> } |
| 32 |
> |
| 33 |
> /* Compare grids. */ |
| 34 |
> @@ -326,6 +328,8 @@ grid_clear_lines(struct grid *gd, u_int py, u_int ny) |
| 35 |
> free(gl->celldata); |
| 36 |
> memset(gl, 0, sizeof *gl); |
| 37 |
> } |
| 38 |
> + |
| 39 |
> + malloc_trim(0); |
| 40 |
> } |
| 41 |
> |
| 42 |
> /* Move a group of lines. */ |
| 43 |
> |
| 44 |
> I have some other applications that are unusable to a certain degree. Having to patch every single application isn't possible, I want to get to the root of the issue :) And USE=vanilla is my first attempt. |
| 45 |
> |
| 46 |
> Thx |
| 47 |
> Franz |
| 48 |
> |
| 49 |
|
| 50 |
Check out the mallopt(3) man page. You can fine-tune glibc heap through environment variables without patches. Specifically use MALLOC_TRIM_THRESHOLD_ to tell glibc when to trim and MALLOC_MMAP_THRESHOLD_ to tell it to use mmap() to allocate large chunks (so they're returned to the kernel when free()d). |
| 51 |
|
| 52 |
Just setting the trim treshold too low or calling malloc_trim(0) may be a bad idea. In some cases it will make your process numbers look better but hurt performance because malloc() will have to request memory from the kernel more often and on a system with swap it will just be swapped out if needed so it shouldn't be a problem unless it's a lot. And if it is a lot I think you should be looking somewhere else for the source of the problem. |
| 53 |
|
| 54 |
|
| 55 |
-----BEGIN PGP SIGNATURE----- |
| 56 |
Version: GnuPG v2 |
| 57 |
|
| 58 |
iQIcBAEBCAAGBQJXfVIcAAoJEPbOFX/5UlwcwT4P/RDvLd6zsvNulN7AYCvPYFr/ |
| 59 |
2+BZmSSDeKJh5kbdGUzWb8FnqucAeFIBHYdpviEG7umDpZT6RN8MiFeDnK8W8Ww9 |
| 60 |
jLQyPgSXxTlfFNMGyxnJ/+EphSxPQ0LNjk98etHOKZNx6lM9NSN4kESRpk0LzSEs |
| 61 |
Qqp5WWipZU0kMqpfXZDr9U92MFLuSSe/LMRxuovIkz/tqlDHA1HTScob5CCAGmBx |
| 62 |
G4m1vxM7dPyv9YDAOELLR2y8CuoJzbiwhxOBAUBFJk3hF9Z1wDW0/8DbcogSwZkd |
| 63 |
T4mEQB28zEawjs0aguBXSKYemN3Nik1d1sPokZQ7SKCgVpIT0bHDV/cuoccTsWr0 |
| 64 |
eliobWgCzipXa15hvccU+xqSD25tZYX3f47T7/IMiwZW4CMFZZtY4X9BX/KTn7/C |
| 65 |
Q29M3ZM4NkbmSU27FtpKUQNl4/KrvMypmNBGcqb1BH74Y9Pay0Y9wHb+qeu8eITQ |
| 66 |
A07wgCJTtCm0s3dtyU7tu5SU6R2CSbJurJ9pvAHC1qNhQfCQYy3yxOEh0CCrCXC1 |
| 67 |
5nH94W1W1wjthJzYf728lvFloEpI7uT0RngpTJIR5Fg6Ku5ZA14rv8qANEbLEnTe |
| 68 |
hFV32a0cSbp3jMnUyvdYyxx89aOhJ08AU2Wf1L5DF5bMG864E5oH3AZc5a3OeNNu |
| 69 |
jJ+zTzNMF2lZ2ePZYcRg |
| 70 |
=ALKt |
| 71 |
-----END PGP SIGNATURE----- |
Archives