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.
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. Jeremy.
... or if you don't want to dive into git, use http://repo.or.cz/w/Samba.git?a=snapshot;h=v3-0-test;sf=tgz Volker
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.
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)?
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 ?
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).
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.
Do you have any chance to re-test with the new Samba 3.4 release ?
This bug has been silent for ~4 years. Please reopen if still an issue in recent Samba versions.