As you know I'm seedboxing. which is a good stresstest
htop view of amuled without amulgui connected is pretty benign
PID△USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
1721408 alan 20 0 20.0T 2402M 45324 R 5.8 1.9 6h50:22 │ │ └─ amuled
1721987 alan 20 0 20.0T 2414M 0 S 0.0 1.9 1:24.98 │ │ ├─ amuled
1721988 alan 20 0 20.0T 2414M 0 S 0.0 1.9 0:23.19 │ │ ├─ amuled
1721989 alan 20 0 20.0T 2414M 0 S 0.0 1.9 0:00.00 │ │ ├─ amuled
1721990 alan 20 0 20.0T 2414M 0 S 0.0 1.9 0:00.32 │ │ ├─ amuled
1721993 alan 20 0 20.0T 2414M 0 S 0.0 1.9 0:12.57 │ │ ├─ amuled
1721996 alan 20 0 20.0T 2414M 0 S 0.0 1.9 0:00.31 │ │ ├─ amuled
1722023 alan 20 0 20.0T 2414M 0 R 27.1 1.9 1h17:12 │ │ ├─ amuled
1722024 alan 20 0 20.0T 2414M 0 S 10.3 1.9 45:51.66 │ │ ├─ amuled
1722025 alan 20 0 20.0T 2414M 0 S 2.6 1.9 16:44.07 │ │ ├─ amuled
1722026 alan 20 0 20.0T 2414M 0 S 1.9 1.9 16:45.77 │ │ ├─ amuled
1722027 alan 20 0 20.0T 2414M 0 S 1.9 1.9 16:47.05 │ │ ├─ amuled
1722028 alan 20 0 20.0T 2414M 0 S 1.9 1.9 16:48.56 │ │ ├─ amuled
1724024 alan 20 0 20.0T 2414M 0 S 0.0 1.9 0:08.21 │ │ ├─ amuled
3563852 alan 20 0 20.0T 2414M 0 S 0.0 1.9 0:00.02 │ │ ├─ amuled
3563853 alan 20 0 20.0T 2414M 0 S 0.0 1.9 0:00.02 │ │ ├─ amuled
3565511 alan 20 0 20.0T 2414M 0 S 0.0 1.9 0:00.00 │ │ ├─ amuled
3565512 alan 20 0 20.0T 2414M 0 S 0.0 1.9 0:00.00 │ │ ├─ amuled
3565707 alan 20 0 20.0T 2414M 0 S 0.0 1.9 0:00.00 │ │ ├─ amuled
3565708 alan 20 0 20.0T 2414M 0 S 0.0 1.9 0:00.00 │ │ └─ amuled
Parent thread mostlky sits between 0-7% cpu with threads bubbling away ay generally low CPU usage with occasional bursts to 100% when hashing.
Note that there's a slow leak in RSS, but that's already been raised in another ticket
With amulegui connected, it looks more like this:
PID△USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
1721408 alan 20 0 20.0T 2652M 45324 R 100.0 2.1 6h50:52 │ │ └─ amuled
1721987 alan 20 0 20.0T 2648M 0 S 0.0 2.1 1:25.01 │ │ ├─ amuled
1721988 alan 20 0 20.0T 2648M 0 S 0.0 2.1 0:23.20 │ │ ├─ amuled
1721989 alan 20 0 20.0T 2648M 0 S 0.0 2.1 0:00.00 │ │ ├─ amuled
1721990 alan 20 0 20.0T 2648M 0 S 0.0 2.1 0:00.32 │ │ ├─ amuled
1721993 alan 20 0 20.0T 2648M 0 S 0.0 2.1 0:12.62 │ │ ├─ amuled
1721996 alan 20 0 20.0T 2648M 0 S 0.0 2.1 0:00.32 │ │ ├─ amuled
1722023 alan 20 0 20.0T 2648M 0 S 0.0 2.1 1h17:29 │ │ ├─ amuled
1722024 alan 20 0 20.0T 2648M 0 S 0.0 2.1 46:01.05 │ │ ├─ amuled
1722025 alan 20 0 20.0T 2648M 0 S 0.0 2.1 16:47.74 │ │ ├─ amuled
1722026 alan 20 0 20.0T 2648M 0 S 0.0 2.1 16:49.43 │ │ ├─ amuled
1722027 alan 20 0 20.0T 2648M 0 S 0.0 2.1 16:50.94 │ │ ├─ amuled
1722028 alan 20 0 20.0T 2648M 0 S 0.0 2.1 16:52.43 │ │ ├─ amuled
1724024 alan 20 0 20.0T 2648M 0 S 0.0 2.1 0:08.23 │ │ ├─ amuled
3568726 alan 20 0 20.0T 2648M 0 S 0.0 2.1 0:00.01 │ │ ├─ amuled
3568885 alan 20 0 20.0T 2648M 0 S 0.0 2.1 0:00.01 │ │ ├─ amuled
3570308 alan 20 0 20.0T 2648M 0 S 0.0 2.1 0:00.00 │ │ ├─ amuled
3570309 alan 20 0 20.0T 2648M 0 S 0.0 2.1 0:00.00 │ │ ├─ amuled
3570319 alan 20 0 20.0T 2648M 0 S 0.0 2.1 0:00.00 │ │ ├─ amuled
3570395 alan 20 0 20.0T 2648M 0 S 0.0 2.1 0:00.00 │ │ ├─ amuled
3570396 alan 20 0 20.0T 2648M 0 S 0.0 2.1 0:00.00 │ │ ├─ amuled
3570397 alan 20 0 20.0T 2648M 0 S 0.0 2.1 0:00.00 │ │ ├─ amuled
3570398 alan 20 0 20.0T 2648M 0 S 0.0 2.1 0:00.00 │ │ ├─ amuled
3570399 alan 20 0 20.0T 2648M 0 S 0.0 2.1 0:00.00 │ │ └─ amuled
The parent is constantly busy, mostly at 100%, dropping down to 20% occasionally.
Child threads mostly sit at 0% with occasional spikes in 2-3 to 10-30%
Connecting an EC becomes hit and miss - whilst the port is open, the setup handshake has a tendency to timeout (this applies across amulegui, amulecmd and amuleweb)
Amulegui is slow to update (1 minute or so on downloads page) and one of the more notable oddities is that the status summary of upload/download speeds bears little relationship to the sums of transfers showing in the upload/download panes. Additionally, upload clients are disconnecting on timeouts when downloads complete and start hashing, although the delay appears to be between the download hitting 100% and "Suspending/Resuming uploads of x", as that latter step is 1-3 seconds at most.
This is clearly load-dependent and I know I'm pushing it to extremes but that opens opportunities to identify and hopefully deal with remaining bottlenecks.
The number of bug fixes over the last couple of months is simply incredible and I'm really happy to see new life breathed into a project which was for all intents and purposes "dead" mostly due to poor performance (which is what sent people skipping off to torrentland). It was essentially impossible to seedbox in the past without a dedicated machine and regular restarts, which discouraged most people from trying. Performance degradation past a few hundred shared files was simply too much to tolerate for most.
What's the best way to diagnose where both processes are spinning their wheels?
(BTW, most (but not all) of that 234MB RSS growth went away when amulegui disconnected. RSS is now hovering 2465MB
As you know I'm seedboxing. which is a good stresstest
htop view of amuled without amulgui connected is pretty benign
Parent thread mostlky sits between 0-7% cpu with threads bubbling away ay generally low CPU usage with occasional bursts to 100% when hashing.
Note that there's a slow leak in RSS, but that's already been raised in another ticket
With amulegui connected, it looks more like this:
The parent is constantly busy, mostly at 100%, dropping down to 20% occasionally.
Child threads mostly sit at 0% with occasional spikes in 2-3 to 10-30%
Connecting an EC becomes hit and miss - whilst the port is open, the setup handshake has a tendency to timeout (this applies across amulegui, amulecmd and amuleweb)
Amulegui is slow to update (1 minute or so on downloads page) and one of the more notable oddities is that the status summary of upload/download speeds bears little relationship to the sums of transfers showing in the upload/download panes. Additionally, upload clients are disconnecting on timeouts when downloads complete and start hashing, although the delay appears to be between the download hitting 100% and "Suspending/Resuming uploads of x", as that latter step is 1-3 seconds at most.
This is clearly load-dependent and I know I'm pushing it to extremes but that opens opportunities to identify and hopefully deal with remaining bottlenecks.
The number of bug fixes over the last couple of months is simply incredible and I'm really happy to see new life breathed into a project which was for all intents and purposes "dead" mostly due to poor performance (which is what sent people skipping off to torrentland). It was essentially impossible to seedbox in the past without a dedicated machine and regular restarts, which discouraged most people from trying. Performance degradation past a few hundred shared files was simply too much to tolerate for most.
What's the best way to diagnose where both processes are spinning their wheels?
(BTW, most (but not all) of that 234MB RSS growth went away when amulegui disconnected. RSS is now hovering 2465MB