After two weeks after installing the Content Service service on our main file server (dual processor HP ML350 G6), I'd like to compare some numbers...
We have more than 25 thousand files to index and the first days the service managed to index less than 4% per day, not very much indeed. We foreseen almost a month to finish the indexing.
Today I checked the progress and found the service hung. I cannot connect to the service through the console and when I tried to restart the service, the service wouldn't. I had to kill the process manually.
After the service restart I could connect again through the console and discovered the indexing is at 48%, as expected after two weeks.
The Connect.Service.ContentService task is consuming between 225MB and 350MB of RAM, the Content Service folder is now 4.58GB with 114000+ folders and 56800+ files.
I'm waiting the indexing end to discover its real functionality and to see how long it takes to index files on a dayly use, hoping it won't stop too often.
Just a share.
Do you have the Content Service HF1 installed? That hotfix addressed handling problematic dwg files so that the service could move on and continue indexing other files. Perhaps this is the cause for the hang?
As for the indexing performance there are a few things to keep in mind. The service is configured to be a low priority so that it remains in the background when your machine/server is busy doing other work. Each of the files in your watch folder(s) are being opened and various object (File properties, blocks, attributes, layers, text, etc) are being extracted and added to the index.
The Content Explorer team appreciates that you are posting your experience and we look forward to hearing your final findings and thoughts. Hopefully others can share their experiences and results as well.
Again, thank you for sharing your experience. I hope that other newsgroup participants follow your lead and share their statistics as well.
As you can imagine, it's difficult to say how long the indexing process will or should take. Our background service is designed to run as a low priority so that it does not interfere with other processes running on the server. Therefore, it will theoretically run faster when the server is inactive and take a backseat when the server is more active. Similarly, as Craig mentioned, the complexity of the files plays a part. Larger and more complicated files take longer to open/extract than smaller files.
Per your last comment, please note that this initial indexing process is intended to be a one-time event. Our expectation is that, once the initial index is built, incremental changes will occur quickly and require fewer CPU cycles. I'm very interested to hear your feedback once the process is complete and you start using it for daily activities. Please let us know how we might support your efforts, and feel free to ask any questions.
Thanks for your time and feedback!
I have exactly the same symptoms as mcicognani. Our file server runs on Windows XP SP3. Content Service (with HF1) plant systematically after a random period. I finally quit because after a week it had indexed only 17% of the files and I had to watch her constantly to restart after a crash.
Yes, the HF1 is installed.
Our file server is oversized respect its real usage and has lot of processors time to spare. It has 16 cores and content service is using just one and not even at full speed.
Doing a simple math, I'm not sure however that it will be fast enough for a daily use... Rigth now is doing a little more than 50 drawing per hour. That's not very much. During peek hours the server will easily lag behind, while maybe recover overnight.
That means we cannot completely trust the search on recently saved files.
While waiting for the indexing to end, I already have a couple of suggestion:
- let user choose Content DB folder!!! Our folder is already 5GB and will probably reach 10GB size And I don't like having it on our boot volume.
- let user choose service priority and/or number of threads to use. I could increase or reduce threads based on our workload or just during the first indexing phase. After all we are a small firm, and we are indexing only the working projects. How long would it take on bigger firms or if we decide to index the archived projects too? It's gonna take months!
Anyway, I believe the Content Service is a GREAT idea, I think it just need to be adjusted for a company wide usage and non only for a local and personal browsing.
Watt01 - I am sorry to hear that you were having trouble with the service. I would like to give you a hand to try and figure out why you were experiencing a crash. You should not have to restart the service as it is configured to restart if it encounters any issues. If you could zip up and then email me the Windows Event Viewer log, CE log file, and the Database file(.sdf) from the service folder I can have the team try and figure out what's causing your issue. For XP they are located "C:\docandsettings\all users\app data\Autodesk\ContentService"
mcicognani - Once the initial index is complete I believe everyday changes will be indexed quickly. As for your suggestions I believe both are valid and I will pass them along to the development team. Selecting the location of the index is something we agree is a useful option to provide. Would you expect to select the location on install? Have the ability to change the location later after indexing has already taken place? Both? Shoot me an email and we can discuss the topics in more detail.
My email is Craig.Godfrey@autodesk (add .com to the end) Trying to avoid automated emails
The indexing has finished, a little earlier than expected, it took three weeks instead of four...
These the final numbers for a total of 25800 dwgs indexed:
- Overall folder size: 7.94GB
- Number of files: 88132
- Number of folders: 174385
- Metadata file size: 20MB
- Service memory usage: 300MB
Problem is, the service is continuously restarting after some NET exception, and currently is not usable. The explorer find the server, but cannot perform any search in it.
I already sent our logs to Craig, hoping he will sort things right.
Back again after a few months...
The problem we got a few months ago turned out to be volume C: without enough free space to perform some index optimization.
Since it was a production server it took us a while before we could plan a partition resize on it, but finally we did it.
So we started again the service after a complete cleanup and were waiting for the indexing phase to complete.
This time we got a different problem, the service encountered some 'usual' exceptions but after a few service restart, the last time the service refused to start saying that 'the same key was already added'.
I'm gonna clean up the database once again and I will try another indexing, but this thing is getting frustrating. I'd like to use this service, but I begin to think it's still too raw for a real usage scenario.
sorry to hear that you are running into issues with the Content Service.
The 'the same key was already added' error you referenced - we had a couple reports of this error, but haven't been able to reproduce it reliably in-house, which is very frustrating.
What types of "'usual' exceptions" did you see?
Can you send me the following files?
oleg.dimerman at autodesk
Access a broad range of knowledge to help get the most out of your products and services.