[GNUnet-developers] Re: [Help-gnunet] OK to use a FQDN for 'IP' in gnunet.conf?

[Christian Grothoff]

On Saturday 26 February 2005 15:53, Ludovic Courtès wrote:
> I ran gnunetd for approximately half an hour and used `ps' to get more
> accurate information on what's going on.  It was connected to 17 nodes
> at the end.  While my `MAXCPULOAD' was set to 20, gnunetd was clearly
> eating 100% of the CPU time:
>
>   [ludo ~]$ ps -m --cumulative --format "pid command %cpu time wchan" 958
>     PID COMMAND          %CPU     TIME WCHAN
>     958 /usr/bin/gnunetd  0.0 00:00:01 -
>       - -                 0.0 00:00:01 schedule_timeout
>       - -                 0.0 00:00:00 schedule_timeout
>       - -                34.0 00:22:28 schedule_timeout
>       - -                33.1 00:21:52 -
>       - -                 0.2 00:00:10 schedule_timeout
>       - -                 0.0 00:00:01 schedule_timeout
>       - -                13.7 00:09:04 schedule_timeout
>       - -                 2.7 00:01:48 schedule_timeout
>
> This shows that 8 threads (not 9) have been running.  Three of those
> threads have been sharing the whole CPU time while the others have been
> mostly sleeping.  The `WCHAN' field shows "the name or the address of
> the kernel function in which the task is currently sleeping", or a dash
> for running threads (quoting the `top' manual page).  So the idle
> threads are effectively waiting for I/O or for a sleep(3) timeout (see,
> e.g., `io_schedule_timeout' in Linux' `kern/sched.c').
>
> Now, we need to identify the working threads and see why they are
> working so much.  ;-)  Christian, if you know the order in which threads
> are spawned, assuming the first thread shown by `ps' is the main thread,
> you might be able to tell us more about it?

Look at the consumption for threads 3 and 4, they are almost identical.  There 
are only 2 threads in GNUnet that do the same thing: the threads spawned in 
core.c to do the packet processing. This is also consistent with their rather 
low number since they are started quite early on.  Now, these threads can 
execute almost all of the GNUnet codebase (minus cron-functions and 
transports and some other minor bits), so knowing its them does not really 
help to narrow it down ;-).

> PS: Should we rather use `gnunet-developers' for this sort of
>     discussion?

Yes, I think that would be more appropriate ;-).

Christian