Fairly high resource usage

[r-vdp]

I deployed mycelium on three machines and on each of them I see regular (every couple of seconds) CPU spikes.
My router which is usually consistently at 0.00 load, even while routing all network traffic, sits consistently at 0.20 load when running mycelium without any active mycelium connections.

Is this to be expected? Do you have any idea what would be causing the high resource usage?

[LeeSmet]

In general that is not expected behavior if no traffic is coming through. What is the setup of your nodes? Also could you share some logs from the nodes, especially around the time of these spikes?

[r-vdp]

This seems to have gotten better with the latest release, so I'll close this for now. Thanks!

[r-vdp]

I'm reopening this issue since I'm noticing this again on the latest release. I see very regular CPU spikes, often up to 80%, that last for a couple of seconds.

I will try tomorrow to correlate them to any specific output in the debug logs.
Alternatively I might look into profiling options to see where this comes from.

I have a suspicion that it might be related to neighbour discovery, since the issue was not there when I was running the versions where the multicast probes were sent out on the wrong interface (and so neighbour discovery was not working on those versions).

[LeeSmet]

Is this still going on right now? We shut down one of the public nodes yesterday, and after that the other nodes we monitor suggest there is quite a bit less protocol traffic in the network. I wonder if that is related.

[r-vdp]

Yeah it looks a lot better now. Still some mild CPU spikes, but not nearly as bad as before. We're talking 10% on a core now compared to 80%+ over the weekend.

I noticed with tcpdump over the weekend that there were a lot of packets being sent over the mycelium port, and a lot of them having length 0. I didn't have the time to look into it in more detail though. I'm just mentioning it in case it's useful info to you.

[LeeSmet]

Thanks for the info. I'll check the packet length in tcpdump when I get around to it, I'm guessing its related to the tcp/quic connection layer (there are no explicit 0 length sends in the code)