Bug #15696

[Linux DS] Memory leak

Added by MiB over 4 years ago. Updated almost 3 years ago.

Status:Expired Start date:12/07/2010
Priority:Normal Due date:02/01/2012
Assignee:- % Done:

0%

Category:Server
Target version:-
Affected ArmA II version:1.59.79548 Linux Server First affected build:
Reproduced by another DH user:No First affected ArmA II version:
I am using some Mods:No Single / Multi Player?:
I am using:OA only BIForumURL:
Reproducible for you:Yes NGUrl:
Related to content of DLC: WIKIurl:

Description

I think, it is a memory leak: http://goo.gl/ZJqJu
Server build 1.56.76188
Debian 2.6.32-5-amd64

20101207-mjjk-226kb.jpg - the same screen in description (226.3 kB) MiB, 12/07/2010 23:42

War-4-Front-1-0.Takistan.rar - PID 11706 (313.1 kB) MiB, 12/08/2010 14:43

WarfareBE_V2.064OA_40.Takistan.rar - PID 11765 (229.2 kB) MiB, 12/08/2010 14:43

20101208-hdcw-219kb.jpg (219.2 kB) Fireball, 12/08/2010 19:25

Snap2.png - PID 11765 Snap2.png still works without restart about 2 days and use 3980M VRAM. (34.2 kB) MiB, 12/09/2010 21:25

Snap3.png - 22:44:00 - 2 player - VRAM 1558M (34.2 kB) MiB, 12/09/2010 21:25

Snap5.png - 23:22:00 - 2 player - VRAM 1567M (34.3 kB) MiB, 12/09/2010 21:25

Snap7.png - 23:32:00 - 2 player - VRAM 1571M - Snap7.png (34.7 kB) MiB, 12/09/2010 21:25

Snap8.png - 00:21:00 - 1 player - VRAM 2034M - Snap8.png (31.9 kB) MiB, 12/09/2010 21:25

2010-12-23_memleak.png - Linux DS 1.57.76894 (31.5 kB) MiB, 12/23/2010 15:42

arma2_1.60.87589_linux_memleak.png (13.6 kB) MiB, 12/25/2011 02:36

History

Updated by kju over 4 years ago

  • Due date set to 01/01/2011
  • Category set to Server
  • Status changed from New to Feedback
  • Target version deleted (1.56 BETA)
  • Affected ArmA II version set to 1.56.76134

how long does it take?

Updated by MiB over 4 years ago

if I understand you right (but i'm not sure) - it's happen all time, and memory is freed only after a restart - http://goo.gl/gtSYU (20101208-hdcw-219kb.jpg) screen after few hours, as you can see, a memory leak still there.

Updated by Fireball over 4 years ago

Image hosters expire content from time to time, thus, please always attach images to the ticket.

Updated by Fireball over 4 years ago

  • Subject changed from memory leak - linux server to [Linux DS] Memory leak
  • Due date changed from 01/01/2011 to 02/01/2011
  • Status changed from Feedback to Assigned

Updated by MiB over 4 years ago

PID 22863 - War-4-Front-1-0.Takistan
The server was restarted and worked for about 4 hours without players.

21:18:46 - 1 player - VRAM 438M
21:21:21 - 2 player - VRAM 564M
21:23:50 All users disconnected - VRAM 564M
After disconnecting all the players, memory is not freed on any of the servers - persistent=0.
- PID 11765 Snap2.png still works without restart about 2 days and use 3980M VRAM.

21:41:19 - 2 player - VRAM 588M
21:57:30 - 2 player - VRAM 601M
22:44:00 - 2 player - VRAM 1558M - Snap3.png
23:22:00 - 2 player - VRAM 1567M - Snap5.png
23:32:00 - 2 player - VRAM 1571M - Snap7.png
00:21:00 - 1 player - VRAM 2034M - Snap8.png
01:26:00 - 0 player - VRAM 2034M

Updated by kju over 4 years ago

  • Due date changed from 02/01/2011 to 03/01/2011
  • Assignee set to Dwarden

Updated by MiB over 4 years ago

Affected ArmA II version: 1.57.76894

Updated by kju over 4 years ago

  • Affected ArmA II version changed from 1.56.76134 to 1.57.76894 Linux Server
  • I am using set to OA only
  • Reproducible for you changed from No to Yes

ty

Updated by MiB over 4 years ago

Affected ArmA II version: v1.57.77737 Linux Server.

..I tried to do some experiment.
I set -maxmem=512 and ulimit -v 512000, but the server crashed after reach mem limit(

Please fix this leak as soon as possible. It's really annoying and it's is a one of the reason servers crashes.

Updated by Fireball over 4 years ago

Well funny is, my Linux BETA 77737 DS runs on FreeBSD with Linuxulator like since 27th and it occupies merely 37% of the memory despite of prolonged Insurgency playing with up to 4 players were going on (people leaving, joining, leaving again, joining again, continuing the mission etc.

But it was told that FreeBSD memory allocation syscalls wrapped around the linux ones are superior and might prevent bugs such as double-free and might also discard memory, which is no longer in use by any process, so this might not mean anything.

OTOH the mission was never changed/reloaded since I started the server, so it could also be that.

Updated by MiB over 4 years ago

Fireball wrote:

Well funny is, my Linux BETA 77737 DS runs on FreeBSD with Linuxulator like since 27th and it occupies merely 37% of the memory despite of prolonged Insurgency playing with up to 4 players were going on (people leaving, joining, leaving again, joining again, continuing the mission etc.

But it was told that FreeBSD memory allocation syscalls wrapped around the linux ones are superior and might prevent bugs such as double-free and might also discard memory, which is no longer in use by any process, so this might not mean anything.

OTOH the mission was never changed/reloaded since I started the server, so it could also be that.

Your system is 64 bit? And you mean 37% of the allocated memory by maxmem?
In my case memleak occurs without change/reload missions.

Updated by Fireball over 4 years ago

Yes 64bit system and I mean 37% of the physical memory as shown by 'top'.

Updated by Dwarden over 4 years ago

  • Operating system set to Linux

Updated by kju almost 4 years ago

  • Due date changed from 03/01/2011 to 12/01/2011
  • Affected ArmA II version changed from 1.57.76894 Linux Server to 1.59.79548 Linux Server

Updated by kju almost 4 years ago

  • Status changed from Assigned to Feedback
  • Assignee changed from Dwarden to Fireball
  • Audio card deleted (Please specify!)
  • Size of OS swap file deleted (Please specify!)

Any chance for new logs Fireball / MiB / anyone?

1.60 beta server is available.

Updated by MiB over 3 years ago

not fixed.

Updated by kju over 3 years ago

What mission is used?

Updated by Fireball over 3 years ago

  • Assignee deleted (Fireball)

Seeing that those are 5 different servers, my take is that they use some rotation and/or users vote for a mission and missions used do not matter, but only some runtime with decent usage.

Updated by kju over 3 years ago

I am asking due to this #27026.

AFAIK arma2.ru runs also at least one warfare server.

Updated by Fireball over 3 years ago

I see where you're getting at, but terminating the mission should yield the (mis-)used resources again, since it was not a genuine memory/resource leak.

Updated by Fireball over 3 years ago

  • Due date changed from 12/01/2011 to 02/01/2012
last pid:  1524;  load averages:  2.22,  2.23,  1.82                                  up 3+21:16:01  13:29:19
75 processes:  2 running, 73 sleeping
CPU: 31.6% user,  0.0% nice, 67.7% system,  0.8% interrupt,  0.0% idle
Mem: 846M Active, 880M Inact, 150M Wired, 43M Cache, 112M Buf, 47M Free
Swap: 1956M Total, 116K Used, 1956M Free

PID USERNAME      THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
20022 a2oa            1  99    0   842M   640M RUN    947:12 13.67% server
20027 a2oa            1  44    0   842M   640M futex   11:19  0.00% server
20030 a2oa            1  44    0   842M   640M select  10:28  0.00% server
20029 a2oa            1  44    0   842M   640M select  10:09  0.00% server
20031 a2oa            1  44    0   842M   640M select   6:51  0.00% server
20023 a2oa            1  44    0   842M   640M futex    0:02  0.00% server

Nothing special here; as you can see it just used the memory to its full extent, but doesn't drive the OS into swapping. It might be that the a2oa server on linux buffers lots of data and only releases it when it needs to, hence: 880M Inact

Prolonging it a bit into new year, but I think only full dumps (maybe try gdb) can tell the truth.

Updated by Suma over 3 years ago

I see where you're getting at, but terminating the mission should yield the (mis-)used resources again

Not true. Many resources which are not mission specific are cached to improve performance in subsequent missions.

Updated by Fireball over 3 years ago

Suma wrote:

Not true. Many resources which are not mission specific are cached to improve performance in subsequent missions.

I still don't see the relevance for the server regarding a mis-coded mission. Except for some optimization potential - maybe unused cached resources should be yielded (i.e. freed) some time after loading a new mission?

Updated by Fireball almost 3 years ago

  • Status changed from Feedback to Expired

No more useful feedback, so we can assume this is regular behavior and no implications in effective memory usage.

Also available in: Atom PDF