A

Anonymous

Question

PE/Local composer performance with large PDFs

Forum|Forum|13 years ago
October 31, 2012
21 replies
3956 views

Hello all,

I'm using Editor and PE 5.4 M100, and I'm having difficulty publishing a large doc to PDF.

Ok, so the document itself is XML, ATA-style markup, and uses FOSI. It's roughly 2.2MB in size, contains references to about 200 bi-level TIFF graphic ents, and also contains several hundred instances of ID/IDREF pairs.

By turning off graphic display and gentext, I was able to get the document to load pretty quickly into the Editor (about 15 seconds). No completeness errors or anything.

Either sending this to PE or by using the local Print Composer (using distiller for PDF), I cannot get this document to render. I had my maxBusyInterval set to 30 minutes, and it considered the subprocess for this composition hung and restarted it. Other than that, I can get no indication of errors or issues that I can address. My PC for local composition is XP, with a dual-core Intel and 3Gb RAM.

The development server I'm using for PE has 4 quad-core CPUs and 48Gb of RAM.

Anyone have any ideas? I tried searching the adepters a few times, but for some reason the filtering isn't working on the site (selecting just Adepters for searching pulls in results for Windchill, ProE, ect).

Thanks,

-Jason

P

ptc-1787870

1-Visitor

Hi there name-bruthah,

Divide and conquer.

If you can, try the first half of the doc separately and see if you get
the error. If yes, divide again until you can isolate the specific
graphic or piece of data triggering the problem.

Regards,

Jason

1380 Forest Park Circle, Suite 100

Lafayette, CO 80027

C

ClayHelberg

18-Opal

Hi Jason--

Here are some troubleshooting ideas off the top of my head:

When you try to publish locally, what happens when it fails? Does Editor
crash? Does it give an error in the log window? Do you end up killing
the process after some long length of time assuming it's hung?

Have you tried setting the maxbusyinterval higher on PE and republishing
there? I've seen cases of large documents that require longer than 30
mins to publish, but once you bump up the limit to avoid timeouts they
eventually get there.

Have you tried removing/commenting different portions of the document to
see if there's something specific in the content that is causing the
trouble, e.g. a corrupted image file or an unusual XML structure that
triggers something erroneous in the stylesheet?

--Clay

Clay Helberg

Senior Consultant

TerraXML

J

jsillari

1-Visitor

Jason:

Can you try to publish directly from the server using PE Interactive? If so,
monitor the process activity via Task Manager to see which process is hanging
(editor.exe, pubtex.exe, pubview.exe, et al.). If you can, turn on full logging
in PE, run the job, and inspect the PE logs in the Apache Tomcat directory to
see how the job was handled. You may find some clues buried in the intermediate
files which PE normally deletes once the job completes. Examine the javavmmemory
setting and bump it up if it's low. We set the heap size to 900K before java
started crapping out; you may have more luck with your larger physical memory
pool. If you have an Acrobat distiller available on your server, try Print
Composed... -> PDF from PE Interactive (make sure Adobe PDF is set as your
default printer first!). We're running XML files in the 60 - 80 MB range (plus
loads of CGM graphics) without issues on our PE 5.4 M140 Windows 2008 R2 server.

John

B

BobSpangenburg

1-Visitor

Jason,

It sounds like your subprocesses are simply shutting down due to time. I say this since I've got one document that takes about 32 HOURS to publish. It's an index that uses psuedo tables that are built on the fly.

Anyway, what I would do is turn up your time on PE's configuraiton to a couple of hours. If you still get the indication that your subprocess just died, double the time until you get a finished document.

As for the server and your CPU/RAM status, if it's not running on a 64-bit server, the extra RAM is not really being used. If it is a 64-bit server, you should be good there.

At any rate, give the configuration boost a try and see what happens.

Hope this Helps,

Bob

G

GarethOakes

16-Pearl

We have seen examples of this sort of really slow publishing too, particularly when Styler stylesheets are involved (as opposed to native FOSI or native APP). As an additional anecdote, one job we were testing recently peaked at almost 14GB of RAM usage. That was a Styler stylesheet.

-G

N

naglists

1-Visitor

We've had TIFFs fail PE runs before. Give it a shot without graphics.

After that (and trying other suggestions) it's time to start halving the
document and seeing what happens.

C

ClayHelberg

18-Opal

Hi Bob--

Wow! 32 hours? I think that's a record of some kind.

--C

Clay Helberg

Senior Consultant

TerraXML

E

ebenton

1-Visitor

Another thing that has worked for me using Print Composer in the past is to run Print Preview. This is much, much faster than making PDF because I think it is the creating of PostScript for sending to Distiller that takes up the most time in Print Composer. When print/PDF jobs fail, often Print Preview will produce a DVI file that is viewable right up to the page where the problem occurs.
Another thing to try is, if you use the filename method for referencing illustrations and use an APTGRPATH environment variable, just set this variable to some local path where there are no graphics. This will speed up your processing, since no graphics will be found.

S

SusanFort

1-Visitor

Hi,

This following is information I used to provide my military customers with really big documents. Also, per the PE documentation, set the maxBusyInterval to 0 if you don't want any timeouts, or because you seem to have a general idea, set it to like 48 hours. Hope this helps!

Thanks

Susan Fort

Susan Fort
Product Manager, SLM Segment
T 937.743.9091 F 781.707.0602
E -

Variable settings that can reduce the time to open very large documents in Arbortext Editor:

set gentext=off

set gentextautoupdate=none

set gentextwarnings=3

set tabletags=on

set tabletagdisplay=none

set graphicdisplay=off

set tagdisplay=off

set equationdisplay=off

set bitmapdisplay=off

set fosiwarning=on

set inlineediting=off

set showentities=none

====================

Passing data to PE in chunks

set the environment variable APTPEHTTPMODE to a value of CSM.

CSM is much smaller and can be set by APTPECHUNKSIZE

FLSM is also an option, but the fixed length is 4gig.

Here are the methods for increasing available virtual memory:

______________________

Setting bigjobthreshold:

1. See this section in the help for details of the 'bigjobthreshold" option: http://www.ptc.com/ae53M30_hc/index.jspx?id=ID552467643&action=show

At the Arbortext Editor command line, enter the command "eval doc_estimate_dfs(); "

Then take the number that is shown in the panel that pops up and use it for the value for the "bigjobthreshold" set option. ie: set bigjobthreshold="n" where "n" is the number that appeared in the "eval" panel after the first command.

For example, after entering the command

eval doc_estimate_dfs();

a panel popped up with the number 352 in it. Now set "bigjobthreshold" option accordingly:

set bigjobthreshold=352

Set this on both the Arbortext Editor / Styler client machine and the Arbortext Publishing Engine server (in an .acl file placed in CUSTOMPATH/init).

_____________________

Setting javavmmemory:

On both the Arbortext Publishing Engine server and the client machine place the following lines in an ACL file in the ...\custom\init directory of the install tree,

if (!java_init(0)) {

set javavmmemory=764

set javavmargs="-Xss2m"

}

______________________

Setting 3GB parameter:

When composing very large documents to PDF on Windows, the

composition process may fail with an "Out of virtual memory space"

error message. This situation can occur when the composition process encounters

a Windows 2GB memory addressing limitation. After installing this release,

enable this fix by performing the following steps.

CAUTION

Ensure that you make the following change exactly as described. Incorrectly

modifying system files can leave your workstation in an unstable state.

The following steps update the contents of the file c:\boot.ini using the

instructions provided on Microsoft’s web site at:

http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx

Review the contents of that web page before making these changes.

1. Stop Arbortext Editor and Arbortext Publishing Engine.

2. From Windows Explorer, locate the file c:\boot.ini.

If you do not see the file boot.ini in c:\, ensure that system and hidden

files are visible using the following steps:

a. With Windows Explorer open, choose Tools->Folder Options.

b. Select the View tab.

c. In Advanced Settings, select Show hidden files and folders.

d. In Advanced Settings, remove the check mark from Hide protected

operating system files (Recommended). Answer Yes when you are

prompted whether you are sure you want to display these files.

e. Select OK to close the Folder Options dialog box. boot.ini should be

visible after the contents of c:\ are refreshed.

3. By default, boot.ini is set to be read-only. To allow changes to the file,

right-click on the file name and choose Properties. Uncheck Read-only

and select OK.

4. Open the file c:\boot.ini in an ASCII editor such as Notepad and add

the /3GB parameter as described on Microsoft’s web site. The contents of

your updated boot.ini file will be similar to the following example:

[boot loader]

timeout=30

default=multi(0)disk(0)rdisk(0)partition(2)\WINNT

[operating systems]

multi(0)disk(0)rdisk(0)partition(2)\WINNT="????" /3GB

"????" in the example can be the programmatic name of any of the following

operating system versions:

Windows XP Professional

Windows Server 2003

Windows Server 2003, Enterprise Edition

Windows Server 2003, Datacenter Edition

Windows 2000 Advanced Server

Windows 2000 Datacenter Server

Windows NT Server 4.0, Enterprise Edition

If your boot.ini file lists more than one operating system, ensure that you

append the /3GB parameter to the operating system you use when running

Arbortext Editor or the Arbortext Publishing Engine.

5. Save boot.ini.

6. Reset boot.ini to be read-only.

7. Optionally reset the states of Show hidden files and folders and Hide

protected operating system files (Recommended) in the Folder Options

dialog box.

8. Restart your workstation or server.

9. Restart Arbortext Editor and the Arbortext Publishing Engine.

B

BobSpangenburg

1-Visitor

Clay,

The book was an IPB. The tagging for IPB's is such that there are no entries, but rather the individual pieces that eventually make up a row such as <partno>...</partno><desc>...</desc>, etc. So the stylesheet (FOSI) ends up building everything in RAM. The numerical index for our planes is some 1500 pages. Think about it... 1500 pages of psuedo tables... BLAAH!

Anyway, we don't restart our services over the weekend so these are sent on Friday's. Of course we don't print them often.

Bob

Show more replies

Sign up

Please use your PTC eSupport account.

Welcome to the PTC Community

Please use your PTC eSupport account.

Scanning file for viruses.

This file cannot be downloaded