Question

TextProvider64.exe taking 100% of the CPU

Version 9 Laserfiche

Updated April 25, 2016

asked on December 10, 2014

Hi All,

Had a strange one at my customer's earlier. There were 4 instances of the TextProvider64.exe running and between them flat-lined the CPU to 100%. I assume they are something to do with indexing but there was only 13 documents in the queue to be indexed which is strange.

I've since re-started the LFFTS service and the CPU has gone down to around 50% (about normal).

Anyone got any idea's what might of caused this? I'm going to do a re-index over the weekend, but has anyone else seen this before?

Lf Version - LF 9.1.1 SP1.

Cheers!

0 0

Answer

SELECTED ANSWER

replied on December 11, 2014 • Show version history

I'm not sure what the problem is, but you might try enabling TextProvider logging and see if that helps pinpoint which document is giving TextProvider trouble. Logging is enabled by setting values in the Windows registry, as detailed below:

For 32-bit Windows: HKEY_LOCAL_MACHINE\SOFTWARE\Laserfiche\TextProvider
For 64-bit Windows:
- 64-bit application: HKEY_LOCAL_MACHINE\SOFTWARE\Laserfiche\TextProvider
- 32-bit application: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Laserfiche\TextProvider

Create the TextProvider registry key first if it doesn't exist.

Key	Type	Default Value	Unit	Range	Remark
LogLevel	DWORD	0	n/a	n/a	Levels of logging. When it's non-zero, enable logging.
LogDirectory	REG_SZ	null	n/a	n/a	Which directory to put the log files.
PermittedExtensions	REG_SZ	null	n/a	n/a	Which file extensions are permitted by TextProvider to extract text from. Multiple extensions are separated by semicolons. For example: doc;txt;pdf
BlockedExtensions	REG_SZ	null	n/a	n/a	Which file extensions are blocked by TextProvider to extract text from. Multiple extensions are separated by semicolons. If the same extension both appears in PermittedExtensions and BlockedExtensions, it will be blocked.
OnlyExtractFromPermitted	DWORD	0	n/a	n/a	If set to non-zero, TextProvider will only extract text from PermittedExtensions. Otherwise all extensions are permitted.
WaitTime	DWORD	10	second	n/a	Set the value to the number of seconds TextProvider will wait while processing an electronic document before automatically skipping the document and proceeding to the next document.
TotalWaitTime	DWORD	3000	second	n/a	Set the value to the number of seconds TextProvider will wait before timing out while processing an electronic document.

Note: In 64-bit windows, 32-bit TextProvider will use configurations under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Laserfiche\TextProvider in preference, but if the registry key doesn't exist, it will use the same configurations under HKEY_LOCAL_MACHINE\SOFTWARE\Laserfiche\TextProvider as 64-bit TextProvider. WaitTime and TotalWaitTime are special exceptions. 32-bit TextProvider will always use the values under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Laserfiche\TextProvider.

To see the current configurations of 32-bit and 64-bit TextProvider, you can run:

"C:\Program Files\Common Files\Laserfiche\Text Provider\TextProvider64.exe -cmd -printconfig"

and

"C:\Program Files (x86)\Common Files\Laserfiche\Text Provider\TextProvider.exe -cmd -printconfig"

0 0

Replies

replied on December 10, 2014

Text Provider is used by LFFTS to do Search Engine Text Extraction. This is where it generates text at index-time from electronic documents that didn't otherwise have text enabled. This can actually be the most time-consuming part of the indexing process, generating text by some documents in this manner can take a very long time relative to indexing other documents. It's not a big deal if you only ever index a document once, but you're taking that time every time you do a reindex. One recommendation would be to ensure that electronic documents are text extracted client side - that way they will already have text affiliated with them and LFFTS won't try to generate it.

That's a more general recommendation for indexing performance, not necessarily why you'd be getting this specific issue though. Could you check for what documents were created (and therefore indexed) around the time that you saw this issue, and see if they are a particular filetype? It might be that LFFTS thinks it can index them but there's an issue with the iFilter on that machine. We've occasionally seen some issues with new versions of the PDF iFilter.

0 0

replied on April 25, 2016

Hi All,

Has anyone found a cause/resolution for this issue? We are experiencing the same problem at one of our customer sites. I'll advise turning on the textprovider.exe logging to see if that yields any results.

Cheers! Dan

0 0

You are not allowed to follow up in this post.

Question

Question

TextProvider64.exe taking 100% of the CPU

Answer

Replies

Sign in to reply to this post.