Bug 5409 - printing operations cause much higher load than earlier version
Summary: printing operations cause much higher load than earlier version
Alias: None
Product: Samba 3.6
Classification: Unclassified
Component: Printing (show other bugs)
Version: unspecified
Hardware: Other Solaris
: P3 normal
Target Milestone: ---
Assignee: printing-maintainers
QA Contact: Samba QA Contact
Depends on:
Reported: 2008-04-22 09:11 UTC by Michael Young
Modified: 2013-01-18 15:02 UTC (History)
0 users

See Also:

bzipped log extract of cpu grabbing behaviour (25.40 KB, application/x-bzip)
2008-10-27 05:57 UTC, Michael Young
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Young 2008-04-22 09:11:51 UTC
About a month ago I upgraded our printing server from 3.0.22 to 3.0.28a to try to get it working with vista. It was fine outside University term, but now term has started the load has increased greatly and the server is struggling with run queues up to 50. This seem to suggest that the new version of samba is much less efficient under some circumstances. The pattern seems to be several processes trying to take a share of the available cpu. I did a system trace on one such process and it seemed to be repeatedly doing system calls of the form
fcntl(17, F_SETLKW64, 0xFFBFE9C8)               = 0
(fd 17 corresponds to ntprinters.tdb). I am wondering if some less than optimal code has been introduced somewhere between the two samba versions.
Comment 1 Jeremy Allison 2008-04-25 14:09:24 UTC
I added a change that will be in the next 3.0.x release that should reduce the load on a CUPS from Samba. Is it possible you can use git to download and test the current 3.0.x code ?
Check out git.samba.org for details.

Comment 2 Volker Lendecke 2008-04-25 14:18:28 UTC
... or if you don't want to dive into git, use


Comment 3 Michael Young 2008-08-15 05:56:23 UTC
I updated to 3.0.31 and this still looks to be an issue. One thing I noticed is that the connections to one of my print servers running 3.0.31 is very quick, but another is slow (maybe 3 or 4 seconds), and the most significant  difference is that the first has a lot of print queues on it (over 100) whereas the other has something like 6 queues.
Comment 4 Michael Young 2008-08-17 03:37:43 UTC
Actually, part of what is going on is that the print server is trying to connect back to the client (spoolss_connect_to_client), and there is a delay when that fails and times out, since the clients are fairly tightly firewalled. Is there any way of turning this off (other than hacking the code)?
Comment 5 Jeremy Allison 2008-08-18 18:04:00 UTC
Not currently. I could add a new parameter "spoolss client connect" or "printing client connect" to allow this to be turned off. Would that work ?
Comment 6 Michael Young 2008-08-21 03:52:05 UTC
Yes, that would be good. I am not sure how much it relates to the original loading problem I was seeing (the print system isn't loaded enough at the moment to tell) but disabling the connection back to the client does fix the issue of the connection taking time to start up properly, which was the symptom I was taking to indicate that the loading problem was still there. (The difference I was seeing between two 3.0.31 servers in comment #3 is I think down to other differences between them, and not the number of queues served).
Comment 7 Michael Young 2008-10-27 05:57:52 UTC
Created attachment 3691 [details]
bzipped log extract of cpu grabbing behaviour

With regard to the original loading problem, I am currently seeing the situation where two or three processes are getting into a state where they soak up all the available cpu time. From a look at the syscalls used it seemed primarily to be locking printers.tdb. I am attaching a debug 10 log extract of one such process.
Comment 8 Guenther Deschner 2009-07-15 07:24:31 UTC
Do you have any chance to re-test with the new Samba 3.4 release ?
Comment 9 David Disseldorp 2013-01-18 15:02:21 UTC
This bug has been silent for ~4 years. Please reopen if still an issue in recent Samba versions.