Lots of CPU stalls, Render thread spikes

Hello,

Our prototype suddenly started experiencing CPU stalls every second, as shown in the screenshot. We were using UE 4.11.2 when this started happening. The map in question is a simple playtrack with just one character and one vehicle. We also tried with either character or vehicle as standalone and the issue persists.

We have disabled almost all tick events except those needed for bare minimum, like inputs to narrow down on CPU overhead. The spikes involve game as well as GPU times suggesting a communication issue between CPU and GPU too.

Additional information:

1] We recently transferred the project from a failing SATA HDD to an IDE backup HDD, so it’s running on IDE mode instead of AHCI.

2] We tried upgrading to 4.15 to see if the issue persists, and sure enough it is still there.

3] System specifications:
Processor: AMD FX 8350
RAM: 32 GB DDR3
Graphics: RX 480 8GB
OS: Windows 10 PRO 64-bit
HDD setup: OS on SSD, engine and launcher on 1TB SATA HDD, project on a temporary 320 GB IDE HDD instead of a 3TB SATA (damaged)

It might be a project specific issue. However, we have not tested this on a blank project yet.

We can not ignore this issue because it is disrupting synchronisation and timings of all the animations. Can someone help us figure out why there are so many CPU stalls not related to the Tick events? If anyone needs the profiler data, we can upload the ue4stats file here.

Best regards,

Markus.

The problem was found in garbage collection. The time between purging pending kill objects was set to 1 second for testing purposes and left out. For anyone else experiencing similar ‘hitches’ every few seconds, make sure that ‘Time Between Purging Pending Kill Objects’ is set to its default of 60 seconds in Project Settings → Engine → Garbage Collection.

Or better yet, disable GC if not needed to eliminate these hitches all together as specified in the following document:

1 Like

Yeah now how about posting something that isn’t a dead link, I’m tired of seeing that same ■■■■ page.