Opened 10 years ago

Closed 10 years ago

#542 closed defect (fixed)

Suboptimal multicore CPU usage... IMHO :)

Reported by: DISABLED Owned by:
Priority: minor Milestone: 0.8.11
Component: router/general Version: 0.8.10
Keywords: threads balancing Cc:
Parent Tickets: Sensitive: no



Since a couple of releases now, I found out that my Atom N330 CPU (yeah, I hesitate to call it a "CPU" but still ;)) usage wasn't really optimal. It's a dual-core HT, so 4 cores are shown to the system.
What I can see when router manages ~2.5K to 3K tunnels is that 1 of these 4 cores is 100% busy all the time, while 3 others are between 20-50% (all this load is due to I2P JVM, of course). Meanwhile backlog is increasing and max tunnels won't go past this ~3K value.
As a consequence, even if I set router.maxParticipatingTunnels=4000 and despite a 100Mbps WAN access, BW is usage is low and CPU has processing ressources left unused.

So I'm wondering if there could be some reflexion on IP2 workload to prevent some sort of "main thread" being "monolithic"



I2P version: 0.8.10-0
Java version: Sun Microsystems Inc. 1.6.0_22 (OpenJDK Runtime Environment 1.6.0_22-b22)
Wrapper version: 3.5.9
Platform: Linux i386 3.0.4-hardened-r2
Processor: Atom (atom)
Jbigi: Locally optimized native BigInteger? library loaded from file
Encoding: UTF-8

Active: 1124 / 2894
Fast: 75
High capacity: 150
Integrated: 176
Known: 3026

Bandwidth in/out
3 sec: 246,3 / 243,0 KBps
5 min: 290,5 / 282,5 KBps
Total: 167,0 / 161,5 KBps
Used: 21,75 GB / 21,03 GB

Exploratory: 6
Client: 10
Participating: 3029
Share ratio: 86,54

Job lag: 1 ms
Message delay: 97 ms
Backlog: 19


Change History (2)

comment:1 Changed 10 years ago by zzz

see related thread http://zzz.i2p/topics/996

comment:2 Changed 10 years ago by zzz

Resolution: fixed
Status: newclosed
Type: enhancementdefect

As of 0.8.10-2:

BuildHandler? split out from BuildExecutor? thread.
2nd BuildHandler? thread when shared bandwidth > 512 KBps
3rd BuildHandler? thread when shared bandwidth > 1 MBps
This is just a guess whether this is enough threads to prevent 100% on one core, we can tweak it more later if necessary.

Note: See TracTickets for help on using tickets.