Something in your flow is clobbering the processor.
Is it node-red ? What else is running on this pi ? I see vnc, lxpanel (full desktop) ?
Something else from your first screenshot
The system load average is something mentioned in an earlier topic too. Since this is a pi, a load average of 4.00 means your pi is having a 100% cpu load for everything together. Anything beyond that 4.00 will slow all systems down, though at reaching 4.00 you will already notice some of that slowdown. With those 3 values, it tells you that for at least the last 15 minutes the average load has been more than 100%, so something is running on the pi hogging all system resources.
Looking at the load average is often a quick way to see how the system has been behaving for the last bit.
Since this is a pi, a load average of
4.00means your pi is having a 100% cpu load for everything together.
To elaborate a bit more: 0.00 to 1.00 max per cpu core, pi has 4 cores = max 4.00
It is a busy pi for sure 
1 Like
Oh certainly, which I all explained in an earlier topic 
For reference, start here and keep reading downwards: CPU load giving funny output from machine
Hmmm... Yeah. And because I can't get information from that I am still stuck.
The problem kind of resolved itself. Hard to fix something which isn't happening.
Reading through other stuff I have since been shown:
I ran the command and got back the default 60.
I upped it to 80 and rebooted.
No visible change. 
But! (Some good news)
This is what top gives me now: (Cropped)
Not perfect, but better.
(Sorry - I missed that reply.)
Did it/ tried it. Alas no change.
Ok, taking a step back.
Sub-flows.
I have a couple of them in my flows.
If some/one/any of them get a bit confused that won't help the problem.
I have included messages so if a variable isn't set which is needed/used to get things done, it spits out a generic message telling me so.
Obviously I can't have the node identify itself if its name hasn't been set.
I have a bunch of them for each machine I have and now and then (when deploy is pressed) they spit the dummy saying they aren't configured.
Question:
I am doing "modified node" deploy.
At boot there is an inject node which injects the name/s for the node/s.
That survives a "modified node" deploy so long as the sub-flow isn't the node modified.
So why is it that these sub-flows are sending a "node not configured" message when they are? (Semi rhetorical)
And if they send that message, it should be on going every time they are sent a message.
They don't. It is just "now and then" - as said: usually after a deploy.
Timing.
It was set to 20 seconds.
I cranked it to 60 seconds. Leaving enough time for things to settle down from the previous round.
No change to CPU load.
Taking a step back too. Pkilling apache might shut it down for a bit, but not if it runs as a service, then the choice would be to stop the service.
A better question is the why question. Is there a specific reason you need apache to run on this pi? If not, uninstall it or disable the service. If yes, pkilling is not a wise choice either.
Because (probably) a node I am using says it needs it.
FOUND IT!
This is a problem with writing code to detect errors with the catch all node.
There was some feedback from a function node which wasn't getting a flow variable name.
(Which turns out wasn't set - and that in itself is a mystery as the flow value was/is/should be set by an inject node at start up.)
Anyway, following something else, I went to the flow which handles the errors and saw a node count going up at a great rate.
Stopping that has reduced the load back to 20%
New thread coming soon with questions about what I found on in that little journey.
