[6953] in Release_7.7_team
Fwd: Re: Reports of serious printer slowness
daemon@ATHENA.MIT.EDU (Geoffrey Thomas)
Thu Sep 9 19:19:14 2010
Date: Thu, 9 Sep 2010 19:19:07 -0400 (EDT)
From: Geoffrey Thomas <geofft@MIT.EDU>
To: release-team@mit.edu
Message-ID: <alpine.DEB.1.10.1009091916070.31711@dr-wily.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Figured some Release Team folks might want to see this. Basically, if you
print PDF directly to the 9050s, they work quite well.
--
Geoffrey Thomas
geofft@mit.edu
---------- Forwarded message ----------
Date: Thu, 9 Sep 2010 18:45:07 -0400 (EDT)
From: Geoffrey Thomas <geofft@MIT.EDU>
To: Garry P Zacheiss <zacheiss@mit.edu>
Cc: "ops@mit.edu" <ops@mit.edu>, "sipb-staff@mit.edu" <sipb-staff@mit.edu>
Subject: Re: Reports of serious printer slowness
Hmm... it does look like these printers support PDF directly, and PDFs tend to
be smaller and easier to render than PostScript. I'm also suspecting the issue
is more on the printer end, and not on the print server end. Here's some data
on that theory:
So I just added my cluster machine's IP address to the web ACL of a printer
(homer) and printed a document we were having trouble with directly to the
printer over BSD lpr (mit-lpr -Phomer@homer-p file.pdf), and it rendered the
PDF worked fine, and printed at one page every second or two, as you would have
expected.
Since this was a legal-sized document and we were getting the edges cut off on
letter paper, I opened it with acroread, told it to scale the document down,
and printed via the mit-lpr command (which presumably renders it to
PostScript), again directly to the printer. This got a few pages in and then
crashed the printer. After a few reboots it made progress, at a page every few
seconds, and we got the document out that way.
I wonder if there's a way to send PDFs directly to the printer, instead of
rendering them to PostScript on the Athena CUPS servers. Short of that, I
wonder if using Adobe's acroread -toPostScript instead of a Poppler-based
pdftops might work.
I can provide the document in question to you if you want. It's a scanned
booklet, 800k on disk; it was showing up as either 10 MB or 4 GB in lpq output
against the Athena servers, and is 9 MB as rendered to PostScript by Adobe
Reader.
(Note to sipb-staff -- I do not actually recommend sketching on the ACLs if you
have to print something. This is just debugging. If you have to print something
and are having trouble, I think my current recommendation is lerman, the
hold-and-release printer in W20-1.)
--
Geoffrey Thomas
geofft@mit.edu
On Thu, 9 Sep 2010, Garry P Zacheiss wrote:
> Hi Geoff,
>
> We are aware of this, and have taken several steps to improve cluster
> printing performance:
>
> - We've recently increased the amount of CPU, RAM, and disk space allocated
> to the systems serving cluster printers.
>
> - We're in the process of testing a configuration change to limit the size of
> spooled jobs to something reasonable, to prevent huge jobs from impacting
> performance on other queues. This should be deployed in production early
> next week once we've concluded our testing.
>
> - Some additional performance tuning has gone into place on the cluster print
> servers in the last hour or so, which may address the issue.
>
> We're also continuing to follow up on the possibility of a interaction
> between our deployed software and the new cluster printers (HP 9050s)
> although we've received some reports of slowness from queues still served by
> HP 8150s, so it's not clear if the hardware is an issue, although it may be a
> contributing factor.
>
> I can provide further updates as we continue to adjust things.
>
> Garry
>
> On Sep 9, 2010, at 1:08 AM, Geoffrey Thomas wrote:
>
>> Hi ops,
>>
>> It looks like several of the printers on campus (including all the W20
>> printers, when I was in there earlier this evening) are printing extremely
>> slowly. Users are reporting print jobs coming out at less than one page
>> per minute. I'm also seeing very large print jobs in the queue -- on the
>> order of gigabytes.
>>
>> It's worth noting that most (all?) of the cluster printers have been
>> replaced with CopyTech's hardware, so I'm curious if it's something like a
>> PPD for the old hardware generating PostScript that's hard for these
>> printers to render quickly, or somesuch.
>>
>> Relatedly, I'm seeing a lot of print queues (as reported by BSD lpq, at
>> least) with the active job being some distance down in the queue, not the
>> first job either by display order or chronologically, which I think are
>> the same. I'm not sure what's up with this or if it's related, except that
>> I see an anecdotal correlation that these non-first active jobs tend to be
>> one of the largest ones in the queue.
>>
>> If one of you is going to be at release-team, we can discuss this there,
>> and figure out if there's misbehaving client software involved, but I
>> wanted to make sure this was reported.
>>
>> --
>> Geoffrey Thomas
>> geofft@mit.edu
>
>
