(Relatively) high CPU use

[xxxserxxx]

etserver is unexpectedly busy, even when no clients are connected. While the CPU use is not pegging the CPU, the fact that it is often at the top of the process list on a mostly quiescent VPS is curious. What is it doing?

Related: #11

The baseline comparison is mosh. Mosh is on-demand, so when there are no clients, mosh server is not running. When a client is connected, mosh server rarely (if ever) consumes enough CPU to enter the top 20. The only other non-standard services running on this server are wireguard and sshguard. There is no graphical environment, so other load is light.

In contrast, etserver regularly sits at the top of the CPU usaeage list at around ca 0.7% - 1.0%, over top and even the sshguard. This is with no clients. If a client connects, then etterminal is started and etserver jumps to a consistent 1.0% - 1.3% in addition to 1.0% for etterminal. With a connection eternalterminal processes consumes between 2-2.5% CPU use when idle.

Compared to running a rather busy terminal program, gotop with a 500ms refresh in mosh (same server, different connection), etserver remains the top process. Applications with high drawing demands -- ncurses, etc -- do not increase either the etserver or etterminal loads, so this CPU use appears to be baseline background busywork.

In the logs for etserver are only the starting and listening messages, until a client connects; after a client connection are a few connection set-up INFO messages, no errors, and then a series of keep alive messages. The client log (on the server) is even more quiet, with merely a connection message and an "is a good socket" confirmation. The server at -v 9 reports no more information (with no connection) than at verbosity 0: literally, just 4 start-up INFO messages.

• Arch 5.15.64-1-lts
• etserver 6.2.1
• etserver-2022-11-29_08-28.log
• etterminal-ser-tiEplprDIqn7QMjr.log
• et.cfg.txt (renamed to .txt for github)

1. Why is etserver so busy (~1%) when it is idle, and with no client connections?
2. Why are the pair (etserver and etterminal) so busy (~2-2.5% combined) with a client connection?

[inspire22]

I was just noticing the same thing and came here to investigate what might be going on as well :)

[MisterTea]

I think this is because the timeout in the select() calls is too short. If you are comfortable building the source, increasing those should fix it.

[xxxserxxx]

That does it. I changed all assignments of tv.tv_usec in src/terminal/TerminalServer.cpp from 10000 to 100000 and etserver drops out of the top of the CPU use list. It jumps up to 0.3% occasionally, but is mostly quiet.

I noticed no perceptable lag, but didn't perform any significant testing. I'd probably want to run a couple of high demand terminal apps, like the notcurses demo since I'm not sure what the impact of changing all of the selects will be.

[MisterTea]

@jshort Something to consider!

[jshort]

@xxxserxxx How has running with 1/10s be for you with that select timeout? Any noticeable regression or concerns?

[xxxserxxx]

No issues at all. I only changed the timeouts in etserver. I've had it running on three servers since Dec 5, and have had a login to each running since Dec 8. I haven't seen any isuses.

I'm not playing (console) games on them, or anything, so I doubt I'm stressing ET too much, but regardless, I've encountered no issues with the change, and CPU use is down to mostly invisible.

[oliverkurth]

I came here to look for this issue. et is running in a Linux VM on my MacBook, and the fan is on because of this. I noticed with strace that the timeout is too short (10ms):

pselect6(11, [8 9 10], NULL, NULL, {tv_sec=0, tv_nsec=10000000}, NULL) = 0 (Timeout)
pselect6(11, [8 9 10], NULL, NULL, {tv_sec=0, tv_nsec=10000000}, NULL) = 0 (Timeout)

[oliverkurth]

@xxxserxxx do you have a patch for your changes? Better yet, create pull request, to keep this issue from being ignored.

[MisterTea]

Yes, please submit a PR!