View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011719 | GNUnet | transport service | public | 2026-08-07 20:42 | 2026-08-14 23:07 |
| Reporter | Jllx | Assigned To | schanzen | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | assigned | Resolution | open | ||
| Product Version | Git master | ||||
| Target Version | 0.29.0 | ||||
| Summary | 0011719: gnunet-transport consuming 100% CPU of a ryzen 7 5825U | ||||
| Description | after a day of run of the service __PID____UTIL.___PR__NI__VIRT___RES____SHR_S_%CPU_%MEM_TEMPS+___COM. 320490_gnunet__20__0__83772_79484__5396_R__98,9____0,2___8:37.88__gnunet-service- cat /proc/320490/cmdline /usr/lib64/gnunet/libexec/gnunet-service-transport-c/etc/gnunet.conf | ||||
| Tags | No tags attached. | ||||
|
|
Spiking transport CPU usage may happen occasionally, usually on startup. But not that extreme. Unless you maybe enabled debug logging? |
|
|
no debug logging (by the way, it would be really NICE to be able to enable and stop logging on the fly) did reproduced today (after more 8h of run), had to stop everything upon restart it did happen fast will stop the service for today, will investigate tonight |
|
|
again this morning (relaunched gnunet yesterday before going to sleep) gnunet-transport is consuming 100% CPU and su gnunet -c "gnunet-transport -a" No virtual links. no "-L DEBUG" when launching (started with init.d script with "gnunet-arm -s") but seems to create some debug log in /var/lib/gnunet/.cache/gnunet/ I attach the last, there is some data loss (run out of disk space after system update tonight) but it resumed today logs yesterday log is available at https://filevert.fr/d/2N3IkNrzUpKoHPr6KyXw until the 11 will restart the service now that disk space is available, clean the logs and see if I can get something usefull by the way, I've a debug build, so I can produce coredumps, but I wonder how I can do it, since this is gnunet-arm that spawn the services... |
|
|
today log https://filevert.fr/d/2N3IkNrxUsKnGvf9JSii (link valid until 2026-08-11) |
|
|
I have retrieved the logs. Is it possible that this is just DEBUG logging hammering your drive and IO in general? |
|
|
no, I don't think so, even 100% is only one core over 16... it just make more noise due to fan. And the SSD is far from beeing over charged. gnunet works for hours without issue, don't know why it end filling queues my 500+ firefox tabs are more trouble makers ;) |
|
|
I commited some fixes, hope that helps |
|
|
right now, everything seems fine, it stayed alive the whole day.... I tried to resolve gns as well to be sure everything works I wonder if I can know what host has the DHT record? just to know if it is in one of my peers or if it was forwarded further? gnunet-transport -a PEER ROUTE VIA CORE-WIN STALLED PENDING RTT PBM3 dv (2 hops) udp,tcp 4 0 20 422 ms V512 dv (2 hops) - 4 0 0 0 ms DXYV direct udp,tcp 4 0 20 163 ms N78G dv (2 hops) udp,tcp 4 0 3 136 ms jlRyzen7-5700 /home/jlm # su gnunet -c "gnunet-gns -t TXT -u info.higepi.gnunet.gns.alt" >>> Looking for `TXT' records under `info.higepi.gnunet.gns.alt' <<< 2 record(s) found: TXT: `Thu Aug 13 18:34:41 2026: Connected (R) DXYV (timeout in 283 s)' TXT: `Thu Aug 13 18:34:41 2026: Hello sent (I) N78G (timeout in 0 ms)' Resolution finished after 72 s Record set expires in 20 m. |
|
|
The origin host is V512 |
|
|
To be clear: The hosts actually storing the DHT record are unknown to me. |
|
|
last tries, V512 was in peer list.... so the test is not really concluant, the origin is known to my host will continue to test with your last modifications the situation improved : after more than a day, the peer list still contains connections, the transport CPU usage dropped to 46% and now the gnunet-communicator-udp is consumming about 40% CPU.... that is improvements : the links are still alive and transport usage dropped will have to find how to deactivate the logs because if I run it long term, after a day it filled 1G of disk space ;) what is strange is that I didn't enabled any log.... processes are launched by gnunet-arm -s... is it because I have a debug build? |
|
|
seems that previous usage was an unknown peak.... I'm watching the gnunet processes for 5 min now, and CPU usage is low, most of the time below 1%, with some peaks to 12% so if tomorrow the service is still running, and CPU usage is still the same profile, I think you can close the issue, there is still some CPU perf to improve, because my CPU is recent and other old CPU might struggle... will try to deploy gnunet on my old i7... to have some realistic view of usage |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-08-07 20:42 | Jllx | New Issue | |
| 2026-08-08 08:27 | schanzen | Note Added: 0029411 | |
| 2026-08-08 10:29 | Jllx | Note Added: 0029415 | |
| 2026-08-09 10:31 | Jllx | Note Added: 0029423 | |
| 2026-08-09 10:31 | Jllx | File Added: gnunet-2026-08-09.log.zst | |
| 2026-08-09 13:00 | Jllx | Note Added: 0029426 | |
| 2026-08-13 17:50 | schanzen | Note Added: 0029486 | |
| 2026-08-13 22:31 | Jllx | Note Added: 0029489 | |
| 2026-08-14 11:57 | schanzen | Note Added: 0029490 | |
| 2026-08-14 11:57 | schanzen | Assigned To | => schanzen |
| 2026-08-14 11:57 | schanzen | Status | new => assigned |
| 2026-08-14 14:33 | schanzen | Target Version | => 0.29.0 |
| 2026-08-14 17:29 | Jllx | Note Added: 0029491 | |
| 2026-08-14 22:29 | schanzen | Note Added: 0029492 | |
| 2026-08-14 22:29 | schanzen | Note Added: 0029493 | |
| 2026-08-14 22:56 | Jllx | Note Added: 0029494 | |
| 2026-08-14 23:07 | Jllx | Note Added: 0029495 |
