1. We had planned to upgrade Windchill from 9.0 to 9.1 March 6/7, but delayed for 2 weeks, specifically at the request of my manager to see if we could get indexing working and stable.
2. I posted on this forum requesting info on the experiences of others. I got a HUGE response. There is what seems to be universal frustration with FAST ESP and many notes about it not being able to complete bulk indexing and/or not being stable in production. Most requested a summary if we found out any more. I forwarded all of your comments to PTC, and we in fact got some very good attention from Tech Support recently.
3. We've now gone through one complete upgrade rehearsal with full bulk indexing (appr 750,000 documents, 1.8 TB total vaulted files), and since then have done indexing of many new documents. All is relatively successful, fast and stable at this time. We plan to upgrade this weekend, and to do the bulk indexing for real.
Note: During our latest bulk indexing run, the entire process took < 72 hours (compared to 2 full weeks before), but it required re-booting the FAST machine every few hours. We've sent tech support all relevant log files, etc. and are hoping to have a fix for the reboot work-around.
4. The most important finding is the following. We don't know if this affects only us with our current OS, etc., or whether it's tied to 9.1 or what.
The BMS requires enough memory to function for bulk indexing. The "normal" method of allocating a max heap size to a method server is by specifying as a separate property then using this property in a later statement. We found that when doing so, the max heap size property was ignored by the system and the default was used. Specifying heap size directly in the BMS property did the trick. We found this out with tech support on a web session - major surprise to them as well. Note: We're using Windows Server 2003, 64 bit, FAST on a separate machine, 2 foreground and 2 background method servers.
We also ran the latest bulk indexing with the property set to ignore doc's over 30MB of indexable content. We find that thereis currently no way to find which have been skipped due to this property - tech support is working on a way to find these.
5. Once the bulk indexing had finished, we challenged the system with many types of searches, using various keywords and combinations. The change from FAST InStream to ESP that now considers a dash, an underscore and a period seems to work very well. It allows us to correctly search for "smart" Part Numbers with those characters.
6. We've also run a variety of queries at tech support's direction following indexing - trying to find some way of doing some type of accounting / checksum. There are a relatively large number of documents supposedly missing from the vault in one report that are reported as being ok on another report. Some object-based reports do not align with results from directly querying the INDEXSTATUS table. More to find out here...
So, We're absolutely not out of the woods, but much further than a few weeks ago. Your comments about FAST were very valuable to convince PTC that this product as provided and documented is not "prime-time" by any stretch of the imagination - and we got very good assistance to nudge it toward the needed condition. Thank you
I'll post again we're thru this upgrade and have things stablized (hopefully).
