Re: How can the process be consuming significant CPU time and always have "nanslp" state?

[I forgot to include the list in the reply the first time.]

Yuri <yuri_at_FreeBSD.org> wrote on
Date: Sun, 22 Dec 2024 22:34:01 UTC :

> I am running one long-running process that is always shown in ps(1) with 
> WCPU between 50% and 400% and STATE=nanslp, like this:

What was the specific ps command used?

> 
>  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU 
> COMMAND
> 61262 yuri         29  20    0    13G  5986M nanslp   2 161:47  85.55% 
> python3.11

I expect that "THR" being "29" means 29 FreeBSD threads are in use in the
FreeBSD process.

STATE at the process level does not say much about the thread-by-thread
status. The threads of a process need not all be the same over any given
interval, no matter how short or how long.

>  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU 
> COMMAND
> 61262 yuri         29  20    0    13G  5912M nanslp   5 164:25 121.84% 
> python3.11

That is part of how the WCPU figure can be notably over 100% , something
single threaded can not normally do.

>  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU 
> COMMAND
> 61262 yuri         29  20    0    13G  5912M nanslp   2 164:52 158.78% 
> python3.11
> 
>  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU 
> COMMAND
> 61262 yuri         29  20    0    13G  5835M nanslp   4 172:58 234.43% 
> python3.11
> 
> 
> I sampled it hundreds of times, but STATE was always "nanslp".

Do not expect thread-by-thread detail tracking from a process-level
summary, unless you know the process is basically single threaded.

> How can this be that the process is never in RUN or any other state, but 
> it keeps running?

Threads are each scheduled separately. There is no, single, accurate
overall process STATE generally. (There are limiting conditions with
such a status with all/most threads in the same STATE.)

> Shouldn't STATE at least sometimes be RUN?

It might only be showing the original main-thread's state, the thread
that was present before the others were created. "STATE" is not
something that shows proportions across multiple examples well.

You could choose to have ps show all the threads individually. Then
you would likely see a mixture with RUN or CPUn's involved.


===
Mark Millard
marklmi at yahoo.com