PSF/AIX PCL2AFP (was performance, now lost jobs)
ITEM: RTA000157469
Q:
Topic thread:
Printer Systems (PRINT - NA/ATS)
PSF/AIX
I am following up with my customer on a PMR (PSF/AIX - pcl2afp),
performance problems with large pcl2afp transform.
1. The psf/aix admin guide states that the maximum memory is (N)for
pcl2afp.cfg(no limit) Why does psf/aix get unstable at 32mb??
Customer is set at 60mb and has problems.
2. The customer was advised to migrate to infoprint manager. While this
is a good long-term direction, what will make the pcl2afp transform
better on infoprint manager? My understanding is that the same code
from psf/aix is used in infoprint/mgr for pcl2afp. Is this the case?
3. What could I provide for capacity planning in regards to throughput
and maximum size of pcl2afp transforms in infoprint/mgr?
4. Is there a tuning parameter or any other options in psf/aix??
would a bigger/faster RISC with more memory help?
5. background info on PMR:
************************** START OF PMR ******************************
PROBLEM:
All of customer's print ques all of a sudden went to an initing state.
ACTION TAKEN:
I had the customer check his qdaemons and they were up, but he went
ahead and recycled them anyway. I then had him recycle his print
queues, but that did not help. I then had him check his space for
/var/psf and it came as 57% used. The customer stated that he has a
monitor system that monitors for space. he then checked the pcl2afpd
daemon and it was sitting at a stand still and using up 223 minutes of
CPU time since 6:30 this morning.. I had him recycle that daemon and
then pring it back up and then I had him enable his test ques and try
printing from them. I think this is the whole reason his print ques
were at an intting state.
I am having him send me his pcl2afpd.log through testcase and I will
search on it to see why this daemon went into a loop.
After Scott brought down and then brought pcl2afpd back up all of his
print queues went to a ready status and his printer started printing.
He Emailed me his pcl2afpd.log to look at and he wants to see if he can
get an explanation of why the dameon went into a loop.
ACTION PLAN;
I will research and see what I can do and call Scott back and lt ehim
know what I found out.
Action Taken:
Found out that the PCL2AFPD is only capable of supporting 32 meg
stabily and the customer has his at 60 meg. I called the customer and
told him that he was just trying to do to much with PCL2AFPD and
explained that their will be no design request changes made to it either
since InfoPrint Manager will be taking PSF/PSMs place in the near
future. He understood and asked about InfoPrint and I directed him to
his Marketing Rep.
**************** END OF PMR **********************************
A:
R1) See RTA000148041 for some relevant information, then let me know
if you have additional questions on this item. The books are
stating the hardcoded rather than the practical limits. I agree
there should be some guidelines provided and will mention that to
the Info Developers for inclusion in future Infoprint Manager
documentation.
R2) The pcl2afp code in Infoprint Manager is currently the same as in
PSF/AIX. If product marketing determines the requirement to modify
the pcl2afp transform at a future date, only the PCL transform in
Infoprint Manager would be updated since PSF/AIX has been withdrawn
from marketing.
R3) PCL is nearly impossible to predict performance for because the
PCL source can vary so widely, particularly if recursive macros
are used. We do have empirical data for very specific PCL files,
but it's not necessarily valid to extrapolate that data for your
customer's files. Performance will also vary based on the type
of image produced and the resolution of that image.
R4) There aren't really any tuning options for the PCL transform.
The bottleneck is usually the CPU power and possibly memory, disk
and paging space. It's impossible to say in your case without
some customer-specific performance analysis and information on
their current configuration.
Infoprint Manager does have higher resource requirements in general
than does PSF/AIX, so that's something to keep in mind.
My turn for some questions:
1) Is it the transform time or the required disk space with which you
are more concerned, or both?
2) What is the customer's current RS/6000 configuration (model, CPU,
memory, paging space, disk space and disk allocation)?
3) What printer are they trying to print to and what resolution?
4) What is the type of PCL data they are producing -- text, image --
and what application is producing it?
5) Do they have a "typical" PCL print job? Although there's not a
group in Boulder currently tasked with performance analysis for
specific customer cases, we can probably get either the PRTSAMP
folks or Tech Support (me) or the developer to test a dataset on
a specific configuration for some feedback.
6) Does the customer have current PSF/AIX PTFs installed?
7) Have you run any of the AIX performance analysis tools or commands
to see what the bottleneck might be?
Back to you for additional information.
Q:
Here are the answers to the questions you had.
From the techs point of view, the main concern actually is Lost
Policies, (missing reports). Since they are generated on other AIX
servers, They have not been able to trace and find out what really
happened. Any thoughts on how they could trap/trace this issue??
I think the policies could be as small as 1 page..
Note::: the initial concern about performance was as a result of the L1
AIX TEch's advice that psf/aix was unstable with large pcl2afp
transforms and that they should be looking at infoprint manager..
FROM THE CUSTOMER:
Here are the answers to your questions. I want to emphasize that our
concern is not with the throughput of the system, but rather the
integrity and reliability of the environment. Many of the problems
we've had seemed to have been cleared up by the maintenance that was
applied in mid-June.
However, on July 1, we encountered yet another problem that caused lost
prints. This is a critical issue for us because these are insurance
policy documents and our customers may not be aware that the documents
have been lost until two weeks later.
Q1) Is it the transform time or the required disk space with which you
are more concerned, or both? What size are the big jobs (# of
records)
R1) Not concerned w/ transform time or disk space, they are not issues.
Jobs vary as well as records, still not a concern as far as i know.
The issue we are extremely concerned about is the integrity of the
environment. We continue to experience lost prints. This is a
critical issue with our customers.
Q2) What is your current RS/6000 configuration (Model, CPU, memory,
paging space, disk space and disk allocation)?
R2) Using a 7012 Model 397 w/ 128 mb. memory, 384 mb paging space, 1024
mb. disk space for /var/psf, 8592 mb. TOTAL disk alloc. to HMPPR1.
Q3) What printers are you trying to print to and what resolutions/
attachments (DPI 240 300 600) Channel or TCP/IP (Ethernet 10/100
or T/R 4/16)?
R3) Unix printing on the INFOPRINT 60(3160) at a resolution of 600.
TCP/IP connected to ethernet 10/100.
Q4) What is the type of PCL data they are producing -- text, image or
both .. and what application is producing it and where does it run?
R4) I believe the answer to this is both, being that we are printing
signature files & fonts to create policies. Genarate is the
application that runs on remote AIX/4.2.1 servers.
Q5) Do you have a "typical" PCL print job? Maybe a test dataset that we
could try on a specific configuration and provide feedback?
R5) As far as I know, there are some policies that may print the same
type of output. But, there really isn't a typical print job.
There are policy files that have been backed up that serve as
feedback.
Q6) What is the release levels of AIX and PSF/AIX and the latest PTF's
applied/installed?
R6) The level of AIX is 4.2.1 w/ Feb. 99' PTF's installed. PSF is at
2.1.0.0 w/ U462626 last applied/committed on /05/31/99.
Q7) Have you run any of the AIX performance analysis tools or commands
to see what the bottleneck might be?
R7) Iptrace and iostat/vmstat...
Let me know if I didn't answer any of the questions correctly or w/
enough details.
A:
Given that the real customer issue is that PCL jobs are being "lost",
the question of course is where? Since the jobs are being submitted
from remote systems to LPD on the RS/6000 to PSF/AIX, there are a
number of spots where this could happen, and the problem may not
necessarily be within PSF/AIX and the pcl2afp transform.
For example, there are limitations in the print spool in AIX 4.2.
Only 999 jobs can be received from a remote client using lpd. If more
than 999 jobs are submitted, what could happen is that a client will
send a file to the server in the form of dfAxxx where xxx
is a 3-digit job number. If the client goes through more than a thousand
job numbers (either local printing or remote), then the possibility
existed that another dfA filename with the exact job number could be
sent to the server. If the first job had not yet printed on the server,
then the filename would be overwritten.
In AIX 4.3, the AIX developers have added a timestamp to the created
filename in /var/spool/lpd. With the timestamp added to the end of the
dfA filename, now all of these files will be unique.
Could this be a possibility at your customer?
Or there's a possibility that it could be something in PSF/AIX. I
don't have an easy way to trace a job through the system. I would
recommend activating the accounting exit for the PSF/AIX queue(s)
in question. This can be done by going into Show/Change Characteristics
of a PSF/AIX queue, User Exits, Accounting -- and setting ACTIVATE
accounting exit to "YES". To have the accounting information written
to a log file (instead of printing out after each job), the
ACCOUNTING PROGRAM name should be "ainacclog" (which is the default)
with current maintenance; if you wanted to print out the accounting
log with each job, the correct exit to use would be "ainuxacc".
Activation of this log would allow you to run the sample accounting
programs for reporting, ainurpt1, ainurpt2, and ainurpt3. See
libraried ViewBlue item RTA000144351 for additional information on
these programs. Although these exits run immediately before the job
is printed, it should give some guidance on the fate of a job.
Other than that, I think you will need to work through the Support
Center to debug this as this is beyond the scope of what ViewBlue
can address effectively. If you do not feel that you're getting
adequate assistance from the SupportLine folks, ask them to escalate
the item to Level 2 in Boulder.
I hope this helps. Thanks for using ViewBlue.
S e a r c h - k e y w o r d s:
psf/6000 psf/aix pcl2afp pcl aix remote lost performance jobs missing
losing lose print lpd limitation number 999 overwrite integrity
WWQA: ITEM: RTA000157469 ITEM: RTA000157469
Dated: 07/1999 Category: XPSF6000
This HTML file was generated 2000/11/30~13:34:11
Comments or suggestions?
Contact us