Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

High CPU usage of embedded node #450

Open
samuelmaddock opened this issue Apr 12, 2018 · 5 comments
Open

High CPU usage of embedded node #450

samuelmaddock opened this issue Apr 12, 2018 · 5 comments
Labels
status/blocked/upstream-bug Blocked by upstream bugs status/blocked Unable to be worked further until needs are met status/deferred Conscious decision to pause or backlog

Comments

@samuelmaddock
Copy link

samuelmaddock commented Apr 12, 2018

I installed the Chrome extension earlier today and found it to have high CPU usage. I don't think I was using any IPFS-compatible websites besides checking the ipfs.io blog.

macOS: 10.13.2
Chrome: 65.0.3325.181
IPFS Companion: 2.2.0

screen shot 2018-04-12 at 3 31 48 pm

@lidel
Copy link
Member

lidel commented Apr 12, 2018

Thank you for reporting this. Was it running against external or embedded node?

@samuelmaddock
Copy link
Author

Thank you for reporting this. Was it running against external or embedded node?

Embedded node

@lidel lidel changed the title High CPU usage High CPU usage of embedded node Apr 12, 2018
@lidel lidel added the status/blocked/upstream-bug Blocked by upstream bugs label Apr 13, 2018
@lidel
Copy link
Member

lidel commented Apr 13, 2018

Embedded node uses js-ipfs, which is not as mature as go-ipfs. I was able to confirm problem under Chromium: after a few minutes with embedded node the CPU usage is indeed very high.

Let's keep this issue open until upstream issues are resolved:


Workarounds for lowering CPU usage

For the time being I suggest using external node (go-ipfs) which requires smaller amount of resources.
If you run on laptop or other mobile device and want to improve battery life, try additional settings suggested in ipfs/kubo#4137 (comment), namely:

  • you probably want to use ipfs daemon --routing=dhtclient
  • Its probably also worth turning off the reprovider with: ipfs config Reprovider.Interval "0" so your node doesnt rebroadcast all this things it has every 12 hours.

Also related:

@ghost
Copy link

ghost commented Apr 18, 2018

Why not just use the new WASM functionality of golang ?
It would keep the J's and golang versions aligned

@lidel
Copy link
Member

lidel commented Apr 30, 2018

@gedw99 "just" is bit too optimistic :) We may investigate that route, but my intuition is that it won't be easy. There are low details (such as lack of raw socket API in web browser, storage) that require custom handling etc. Also, there is a huge benefit in having two independent implementations interop in the wild: it verifies if the spec is clear enough.

It may be easier to optimize js-ipfs by introducing WASM (as a technology) in hot paths (eg. crypto), but that is a discussion for https://github.com/ipfs/js-ipfs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status/blocked/upstream-bug Blocked by upstream bugs status/blocked Unable to be worked further until needs are met status/deferred Conscious decision to pause or backlog
Projects
No open projects
Status: Needs Grooming
Development

No branches or pull requests

3 participants