Bug #15054
Memory leak
0%
Description
KSP 1.2.9.1773-pre Linux x86_64 (also seen on 1.2.1 but details here are from 1.2.9)
I just made a new mod-free install for this testing. I built a spaceplane, but I don't think it's particularly important. Attached .craft file anyway, in case it's one of the parts.
I attached a log of things I did with this fresh install. Numbers in percent are memory usage for the KSP process, as reported by top and ps. The RSS numbers are resident set size, from ps's man page:
resident set size, the non-swapped physical memory that a task has used (in kiloBytes). (alias rssize, rsz).
It seemed like loading new scenes did the most damage. Reverting to launch and to SPH, mainly. It's time to run valgrind against this puppy.
System specs:
8GB RAM
debian_version says 9.0; it's running testing.
Attached cpuinfo
$ uname -a
Linux tippity 4.9.0-2-amd64 #1 SMP Debian 4.9.13-1 (2017-02-27) x86_64 GNU/Linux
$ lspci
00:00.0 Host bridge: Intel Corporation Device 5904 (rev 02)
00:02.0 VGA compatible controller: Intel Corporation Device 5916 (rev 02)
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)
00:17.0 SATA controller: Intel Corporation Sunrise Point-LP SATA Controller [AHCI mode] (rev 21)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1)
00:1c.5 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #6 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Device 9d58 (rev 21)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
00:1f.3 Audio device: Intel Corporation Device 9d71 (rev 21)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 10)
02:00.0 Network controller: Intel Corporation Intel Dual Band Wireless-AC 3165 Plus Bluetooth (rev 99)
History
#2 Updated by Saskwach over 7 years ago
Some time later, with the game paused, the game's memory usage has creeped up by just under 17MB to 28.9%! It's just been sitting here in the pause menu for the last half hour.
#3 Updated by jclovis3 over 7 years ago
I watched my memory usage on the Windows 1.3 (64-bit) version and agree that switching around frequently between different physics enabled scenes causes memory usage to rise. Playing nine missions at once and hopping around between vessels, I was easily loading over 5GB on KSP alone with 16GB in my computer (eventually crashing as my total memory got near full). I've since upgraded to 32GB and after a day of playing have noticed the memory for KSP get as high as 9GB without a single reboot.
The heap isn't getting its garbage cleaned up often enough. Returning to the KSC or the main menu should cause all unused objects during physics play to be cleaned up. I know in Java and C# you can request the garbage collector to do a collection, but it doesn't guarantee it will happen right away. Any time the pause menu is up is a good time to request it too as it won't affect physics calculations.
A feature I could suggest to help with this is to set a time stamp on a vessel such that when you leave it to jump to another one, the vessel retains all active references to its parts in memory so you can quickly access those same parts when you switch back and after thirty minutes pass of real time, then dump the references and allow the garbage collector to clean it up. Having some sort of indicator that the user can use to flag a ship as needing to stay in memory could be helpful too as this will certainly reduce the number of duplicate copies of the ship end up in memory while waiting for older copies to be collected. My Minmus refueling ship is used frequently and would certainly qualify. keeping the KSC physics loaded and ready for each new launch will help too. Too many crashable buildings and structures to be duplicating this space every time. I understand though that reverting a flight to the design means a new and completely different ship might be coming out next time, so the old ship needs to be deleted from memory, but reverting from launch doesn't requiring dumping and rebuilding the ship if you can just reset its resource values and location/direction/speed variables.