Bug 975241
Summary: | cups-browsed uses too much CPU | |||
---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Zdenek Kabelac <zkabelac> | |
Component: | cups-filters | Assignee: | Tim Waugh <twaugh> | |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
Severity: | unspecified | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 20 | CC: | jpopelka, twaugh, zkabelac | |
Target Milestone: | --- | Keywords: | Reopened | |
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | cups-filters-1.0.40-4.fc20 | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1547828 (view as bug list) | Environment: | ||
Last Closed: | 2013-11-10 06:38:23 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1547828 | |||
Attachments: |
Description
Zdenek Kabelac
2013-06-17 21:19:14 UTC
Created attachment 762218 [details]
Short 'perf' capture
Here is short capture of:
perf record -ag -p pid_of_cups-browsed
From the trace it looks like there is some frequent networking going on?
I've also looked at output of callgrind and it seems like there is huge number of calls to: 1. strcmp() 2. compare_sp_items() 3. cups_array_find() 4. cupsArrayFind() 5. _cupsStrAlloc() 6. _cupsStrFree() Another interesting area seems to be: 1. recv() 2. http_read() 3. http_read_buffered() 4. httpRead2() 5. ipp_read_http() (which seems to correspond to perf trace) Thanks. (In reply to Zdenek Kabelac from comment #1) > From the trace it looks like there is some frequent networking going on? I'll look at it but I think this is actually one of the reasons why the CUPS Browsing protocol was deprecated and then removed from CUPS completely, i.e. because it doesn't meet requirements of current networking technologies and for a long time we've had a mechanism (Zeroconf) designed to address this needs and to avoid the downsides. Well - maybe at least some configurable define 'how often to scan' could be probably exported to cups-browsed.conf file ? I mean - someone may need high precession results and likes scanning every few second - in my case I don't mind if it would be refreshing its state once in 5 minutes.... Yes, CUPS (up to 1.5.4) had a BrowseInterval directive. From documentation: The BrowsePoll directive polls a server for available printers once every BrowseInterval seconds. The BrowseInterval directive specifies the maximum amount of time between browsing updates. Specifying a value of 0 seconds disables outgoing browse updates but allows a server to receive printer information from other hosts. As I understand it it was used to specify interval for sending browsing information as well as for polling a server. There's been also a patch for adding separate "BrowsePollInterval" directive for polling: http://permalink.gmane.org/gmane.comp.printing.cups.devel/4471 ...and there's nothing that can be done about it from the cups-browsed side: it just listens for packets on the network and has no control over their frequency. What's in /etc/cups/cups-browsed.conf? How many other CUPS servers are on the network, broadcasting information about their printers using CUPS Browsing? How many printers does each server broadcast about? (In reply to Tim Waugh from comment #6) > it just listens for packets on the network and has no control over their frequency it can change how often to poll the servers, can't it ? This is now hard-wired to 60s. I see in log: cups-browsed: will browse poll cups.brq.redhat.com every 60s and it does indeed It seems that Jiri is right - the scan is started once per minute - but it's quite lengthy - since there are about 25 printers. There are few optimization possible - 1st. Keep md5 hash of already parsed http printer description - and if you see the same hash - skip whole parsing - this would be great at lowering CPU usage. 2nd. Advanced solution would replace very poor parser of html document that using 'strcmp()' is the primary way to recognize tokes - replacing it with some well designed library for this purpose (or writing some grammar) 3rd. Simple option - allowing i.e. 10minuts delays between parsing (yep - that would meet the goal from my comment 1 ) - but implementing md5 hash would be nice as well. What's in /etc/cups/cups-browsed.conf? cups-browsed will behave differently depending on its configuration. Without that, it's hard to say what's going on. Only 2 lines: BrowseRemoteProtocols CUPS,DNSSD BrowsePoll cups.brq.redhat.com OK, so it's listening for CUPS Browsing packets (BrowseRemoteProtocols CUPS) *and* it's also sending a CUPS-Get-Printers request to cups.brq.redhat.com explicitly, every 60s. Both cups-browsed and the old cups-polld from CUPS 1.5 used libcups for IPP request parsing, so there is no reason to expect cups-browsed to be less efficient. (The default BrowseInterval value in CUPS 1.5 was 30s.) What would certainly make 'BrowsePoll' more CPU and bandwidth efficient, in environments where the population of printers does not change much over time, would be to use IPP subscriptions, so that cups-browsed could subscribe to events relating to printers being added or removed. In this case it would only need to pull the full list once. Created attachment 762924 [details]
0001-Use-IPP-notifications-to-improve-BrowsePoll-efficien.patch
Here's the patch. I'm testing it locally now.
It's pretty rudimentary, in that it only uses notifications to decide when to get the complete printer list again. In most situations it should help though. Created attachment 762993 [details]
0001-Use-IPP-notifications-to-improve-BrowsePoll-efficien.patch
Updated version of the patch, to:
* cancel subscriptions on exit
* prevent authentication prompts
So, some servers allow IPP-Create-Subscription without authentication but require authentication for IPP-Get-Notifications and IPP-Cancel-Subscription. In that case, this approach won't help. (Allowing IPP-Get-Notifications and IPP-Cancel-Subscription without authentication will fix that.) I wonder whether we should change the default browse interval to be much longer, for example 300 seconds instead of 60? How is this going to work in the case I'm moving laptop between multiple networks - i.e. home/office. I typically suspend at office, resume home and later I'm connecting to VPN connection - but not always. The same way it always worked: they will eventually time out and disappear. Created attachment 763007 [details]
0001-Use-IPP-notifications-to-improve-BrowsePoll-efficien.patch
Another updated patch to fix this:
* Browse polling failed if subscription no good
(In reply to Tim Waugh from comment #17) > The same way it always worked: they will eventually time out and disappear. Couldn't cups-browsed listen for NetworkManager changes somehow and drop printers and rescan at that moment ? Rather than adding additional problems to this bug report, I've opened a separate one to track that: bug #975933. This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle. Changing version to '20'. More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20 Patch sent upstream. cups-filters-1.0.39-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/cups-filters-1.0.39-1.fc20 Package cups-filters-1.0.39-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing cups-filters-1.0.39-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-18453/cups-filters-1.0.39-1.fc20 then log in and leave karma (feedback). Package cups-filters-1.0.40-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing cups-filters-1.0.40-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-18453/cups-filters-1.0.40-1.fc20 then log in and leave karma (feedback). Package cups-filters-1.0.40-2.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing cups-filters-1.0.40-2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-18453/cups-filters-1.0.40-2.fc20 then log in and leave karma (feedback). ghostscript-9.10-4.fc19, cups-filters-1.0.40-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/ghostscript-9.10-4.fc19,cups-filters-1.0.40-3.fc19 Package cups-filters-1.0.40-3.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing cups-filters-1.0.40-3.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-18453/cups-filters-1.0.40-3.fc20 then log in and leave karma (feedback). ghostscript-9.10-4.fc19, cups-filters-1.0.40-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. Package cups-filters-1.0.40-4.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing cups-filters-1.0.40-4.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-18453/cups-filters-1.0.40-4.fc20 then log in and leave karma (feedback). cups-filters-1.0.40-4.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. |