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

Mercury in capture mode can have high CPU utilization after suspend #8

Open
davidmcgrew opened this issue Aug 9, 2020 · 1 comment

Comments

@davidmcgrew
Copy link
Member

After resuming from a suspend, mercury may cause high CPU utilization, in cases where it was running in capture mode before the suspend operation. Workarounds:

  1. Don't suspend while mercury is running, or
  2. Restart mercury; if you are using systemctl, as with the default install, you can perform 'sudo systemctl restart mercury'.

Speculation about the root cause: it is possible that the mercury code that uses the AF_PACKET ring buffer(s) shared with the kernel are getting out of sync during the suspend/resume process, and the application code keeps reading through the circular buffer in an attempt to catch up with the kernel.

@davidmcgrew
Copy link
Member Author

It seems that few people are bothered by this issue, so it is low priority. But it would be good to pay attention to interface events (up/down/etc) through Netlink, which would probably solve this problem, and we could also use Netlink to find the interface associated with the default route for use as a default interface for capture. If that's an acceptable default, it would make it possible to have a default capture configuration, which would make it possible to auto-start systemd from a Debian/RPM package.

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

No branches or pull requests

1 participant