Bug 47866 - Large number of queued files very slow to print
Summary: Large number of queued files very slow to print
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: LPRng   
(Show other bugs)
Version: 7.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Crutcher Dunnavant
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-07-08 07:31 UTC by Chris Dunlop
Modified: 2007-04-18 16:34 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-08-29 08:43:38 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Chris Dunlop 2001-07-08 07:31:17 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.19-7.0.1smp i686)

Description of problem:
With 200 files in the queue, there is an elapsed time of about 25 seconds
(on a PII/233) between the finish of one print and the start of data
transmission to the printer for the next print.

How reproducible:

Steps to Reproduce:
1. Put 200 files in the queue.
2. Wait for them to print.

Actual Results:  There is a long delay between each print.

Expected Results:  There should be minimal delay

Additional info:

Using a combination of strace and lsof on the lpd "Server" process shows
it's spending all it's time opening the "hf" queue files, stat'ing the "df"
files and writing to /var/spool/lpd/lp/db.lp.  Over and over and over and
over and over....

Comment 1 Chris Dunlop 2001-07-08 07:47:10 UTC
If I queue a smaller number (e.g. 10) of the exact same of files there is no
delay between the printing of the files (i.e. the printer runs continuously
until all files are printed).

Comment 2 Helge Skrivervik 2001-08-29 08:43:32 UTC
We have the same problem, although a lot worse: We're frequently creating print jobs which generate thousands of entries in the spool queue. The 
first 10 or 20 pages come out as expected, then the speed dimishes until reaching zero. In some cases I can get a couple of jobs to print by sending 
off a new job to the queue, but in most cases we have found no way to get the printing restarted (except for deleting the queue and start over with 
small batches). We're seeing references to 'lp.db' not found at times (lpq command) and have also noted that the spooling system consumes lots of 
cpu time. The work around seem to be to make sure the jobs get sent to the queue with approximately the same frequency as they get physically 
printed. A real pain.  I would call this a serious problem which should be given high priority - given the environments into which Linux (RH) is being 
marketed and sold these days...
I guess we can reinstall the old lpr system from 6.2?

Comment 3 Crutcher Dunnavant 2001-10-11 14:45:05 UTC
This should be cleaned up by a db change in the next release.

try this to fix, or grab LPRng from rawhide:

install the LPRng src rpm.
after the line 'configure --enable-nls \' add this line to LPRng.spec:
  --disable-gdbm \

rebuild the rpms, after adding '.gdbm_off' to the release number.
install the rpms.

Note You need to log in before you can comment on or make changes to this bug.