Massive jam at start / memleaks on linux

Page of 2 (29 records)

sort
rooks[vegan] 7 years ago Since like 3 months ago, When game starts there is massive lag with placing labs, up to a point of rejoining menu popping up and joining up for like 3-5 minutes. It happens on linux ubuntu 64 chobby.exe Also since ~1 month ago there is massive memleak somewhere. after couple of games the process occupies like 17gig of ram including swap. ending game to return to menu was instantenous in late winter, but now takes like 3 minutes. i got more mem to full 5 gig and it still does it. Previoulsy on 3 gig mem was instantenous. And now it often quits during loading or loads very slow so i miss out games from it when it starts with catching up menu that waits for 5 minutes... So like 3 issues. Massive memleak after completed game Long loading times that lead to long catching up time 5minute Sometimes short catching up after normal start when many place factory at once. Anyone noticed that? +0 / -0
malric 7 years ago Happened to me today for the first time, after one played game extremely long loading time while HDD was used. Killed and rejoined worked without an issue. Third game happened the same (had to kill process and rejoin). Specced like 5-6 games after but did not notice the problem (but was not always by the computer). arch 64 bit, chobby +0 / -0
GoogleFrog 7 years ago (edited 7 years ago) Try doing '/cheat' then '/give all' in a skirmish game. See this ticket: https://github.com/ZeroK-RTS/Zero-K/issues/2301 Can either of you link to a bug report where you had this issue? malric is referring to this game: https://zero-k.info/Battles/Detail/464667 +0 / -0
GoogleFrog 7 years ago rooks[vegan] are you using 64 bit Spring? Within the last few months Spring started doing fancier things with memory management, for LuaMenu support. Some of these things were quickly found to crash 32 bit Spring so were disabled. Everyone on windows uses 32 bit Spring due to some lingering issues with 64 bit Spring on windows. Perhaps some issues with memory management were not restricted to 32 bit Spring but the larger amount of memory and fewer uses has made the issues harder to find. Try my test with both 64 bit spring and 32 bit spring and watch memory. +0 / -0
Firepluk 7 years ago (edited 7 years ago) GoogleFrog is there any chance of getting 64bit spring for windows? It could have some performance benefits for users: 16 x 64 bit general purpose registers and 16 x SSE registers instead of 8 x 32 bit general purpose registers and 8 x SSE registers compilers will be able to use registers more effectively and as you know CPU register is the fastest way to store and access a variable. Also if Spring currently uses 64 bit calculations for ANYTHING when compiled to x86 this gonna be implemented thru ass and works much much slower than when compiled to x64 If we are looking for performance, this would be high priority target to solve Yes, process would use 15-30% more memory - but memory is cheap and affordable nowdays, while CPUs stagnate in single thread performance +0 / -0
Firepluk 7 years ago (edited 7 years ago) https://www.viva64.com/en/k/0003/ > Note also that when you launch 32-bit versions of software on 64-bit systems of the Windows family, old 32-bit applications are executed a bit slower because of the WoW64 subsystem which emulates the 32-bit environment. An average performance loss because of this WoW64 layer is 2-3%, although in some special cases it might be much more. +0 / -0
GoogleFrog 7 years ago As far as I can tell win64 Spring basically works. Here is the current win64 blocker: https://springrts.com/mantis/view.php?id=5637 Testing it would be useful. To test it download this: https://springrts.com/dl/buildbot/default/develop/103.0.1-1253-g39b8cbf/win64/spring_%7bdevelop%7d103.0.1-1253-g39b8cbf_win64-minimal-portable.7z Replace everything in your 'Spring\engine\win64\103.0.1-1253-g39b8cbf' folder with the contents of that zip, except for done.txt. +1 / -0
rooks[vegan] 7 years ago (edited 7 years ago) I have it on ubuntu 64 14.04.4, core2duo 2.33 Radeon HD 7350/8350 / R5 220 fglrx drivers 5 gig ram. mono chobby worked ok previously on 3 gig ram, now it does wierd memory things... the process sometimes has like 18gig of virtual mem including all physical, so maybe that new mem thing messes things up. it also looks like from process tracker like the menu doesnt releasse mem alocated previously from spring engine... and with each game that number grows till it makes it unplayable due to hdd page swap lag... hard to hard reset computer few times +0 / -0
GoogleFrog 7 years ago Submit a crash report or link to your infolog. +0 / -0
rooks[vegan] 7 years ago I wish i could submit any report. but the symptom is whole system goes to standstill because of page swap with hdd blocking everything so i have to hard reset... +0 / -0
Firepluk 7 years ago Duh, why in almost 2018 year people still use HDD? Those who do shall be punished with low performance, freezes and lags as they certainly deserve it for optioning out of buying SSD +0 / -0
malric 7 years ago Firepluk: you should use only RAM, and have a nuclear plant (or fusion if you prefer :p) not to depend on the electricity grid! HDD-s can be fine and spring loads like in ~5-10s for me, when it does not behave same as for rooks. And as I want to play I generally just kill it and rejoin... Should try once to check what happens. +0 / -0
GoogleFrog 7 years ago There is potentially a fix in the engine. I'll update to it. https://springrts.com/mantis/view.php?id=5691 +0 / -0
Lynx 7 years ago (edited 7 years ago) I think I may have been suffering from this too (Archlinux); I noticed huge memory usage spikes, my system ground to a halt and I had to hard reset a and rejoin match on a few occasions. At the time I thought it was due to an unrelated problem relating to colord: Archlinux bug 54205. But perhaps it was actually this. +1 / -0
mojjj 7 years ago 32gb ram with ubuntu1404. did not have any issues -.- +1 / -0
Lynx 7 years ago (edited 7 years ago) I just experienced a hard crash [needed to reset computer] last night on loading a game (Archlinux). Nothing visible on journalctl and infolog got overwritten once I hurriedly rejoined. Perhaps it would be helpful if infolog or whatever log file we need kept an account of last few games rather than just last game. Or serious errors could be spewed out elsewhere. Or a separate longer infolog is kept for last few games. +1 / -0
GoogleFrog 7 years ago Past infologs exist in Spring/logs/ +1 / -0
Lynx 7 years ago Doh; I'll take a look. Thanks. +0 / -0
Lynx 7 years ago (edited 7 years ago) GoogleFrog does this help I wonder: https://pastebin.com/ZjBYej4d I copied end of previous game up to loading next game where I think crash occurred. Last line seems incomplete: "[f=-000001] Load" +0 / -0
Lynx 7 years ago (edited 7 years ago) Something feels broken. So GoogleFrog last night I witnessed another hard lockup on loading a game following earlier game. Again it loaded fine when I reset computer and re-entered the match. Here is the (hopefully) relevant portion of the infolog again: https://pastebin.com/y8gRcL9t It's not related to the old manually needing to delete files or directories is it? If so I should give that a shot since I never do it unless I'm told to. Of course the issue could be something other than Zero-K. But I see nothing in 'journalctl -b -1' which captures system level errors. I do have mumble open at the same time. Next time I will check the problem is not being caused by my trying to change workspace whilst the game is loading (not that that should cause hard lockup). +0 / -0

Page of 2 (29 records)

Forum index > General discussion >