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

Debug High CPU Usage For simple_torrent #116

Open
GGist opened this issue Aug 6, 2017 · 3 comments
Open

Debug High CPU Usage For simple_torrent #116

GGist opened this issue Aug 6, 2017 · 3 comments

Comments

@GGist
Copy link
Owner

GGist commented Aug 6, 2017

Seeing high CPU usage when running the example, which should be mostly IO bound (aside from checksumming).

Interestingly, even when disabling the disk manager, I am still seeing a lot of calls to sha1 digest...

@GGist
Copy link
Owner Author

GGist commented Aug 8, 2017

Seems that most of the CPU was coming from the disk manager.

However, I still see an issue (both on windows and linux), where after the download is complete, the CPU is pegged at 13% (windows desktop) or 40% (linux droplet). Interestingly enough, that CPU pegging seems to go away when adding a println statement here https://github.com/GGist/bip-rs/blob/master/bip_peer/src/manager/mod.rs#L335.

I thought it may be due to our usage of Mutex polling in the futures themselves, but switching those out for RefCell didnt make a difference. Additionally, I tried using unsync channels as opposed to the sync channels, and that did nothing as well (though interestingly, it seems the channel capacitys for sync and unsync mean different things, as an unsync capacity of 0 caused the channel to block, but I think thats a separate issue...).

I am going to try and reproduce using just the futures crate, as it may be that tasks are waking up more than they should (though it would be for both unsync and sync, which seems like a stretch).

@GGist
Copy link
Owner Author

GGist commented Aug 9, 2017

Looks like its an issue with tokio-timer Sleep notifying us too frequently. Changing our tick duration doesnt seem to have a large effect on the CPU usage for us waking up, perhaps more often than we need to.

Will look in to what we can do to fix this.

@GGist
Copy link
Owner Author

GGist commented Aug 10, 2017

So I was able to re-produce this very reliably yesterday, but today I can't reproduce it at all. Going to leave it here for a while in case it comes back...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant