[Archivesspace_Users_Group] PUI indexing issues

Tue Mar 16 14:03:00 EDT 2021

I can only answer some of those.

- Staff indexing is done and has its files written. So does the number of threads given to that make a difference? Is it still taking up resources?

Not so much if it's not doing anything.

- Does there happen to be any way to stop the staff indexing and just let PUI have full access to the server for indexing?

You can disable either indexer, but that requires a restart. There's a setting in the config. The PUI is just slower than the Staff.

- Should our repositories be broken up into smaller groupings?  I'm beginning to wonder if we have things set up incorrectly, since it sounds like we have a very large data set compared to others.

It's probably not the total number of resources in a repo, just that the resources are quite large.

________________________________
From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Tom Hanstra <hanstra at nd.edu>
Sent: Tuesday, March 16, 2021 1:52 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] PUI indexing issues

Thanks for the suggestion, Blake. A couple additional questions:

- Staff indexing is done and has its files written. So does the number of threads given to that make a difference? Is it still taking up resources?

- Does there happen to be any way to stop the staff indexing and just let PUI have full access to the server for indexing?

- What really bothers me is the slowdown. That indicates to me that some resource is being lost along the way. Anyone have thoughts on what that might be?

- Should our repositories be broken up into smaller groupings?  I'm beginning to wonder if we have things set up incorrectly, since it sounds like we have a very large data set compared to others.

And a comment....

It is really frustrating to have to start over on the indexing each time. It seems that there should be some way to document progress along the way so that the indexing can pick up where it left off. Is that something that might also be looked at?

Thanks all. Appreciate your help.

Tom

On Tue, Mar 16, 2021 at 1:15 PM Blake Carver <blake.carver at lyrasis.org<mailto:blake.carver at lyrasis.org>> wrote:
> I've now left my PUI indexing threads and count at the default (which I believe is 1 thread and 25 records/thread).

Try dropping both indexer_records_per_thread and indexer_thread_count for both PUI and Staff indexers. Maybe in half or so. Sometimes with larger records it just needs to be slowed down.
________________________________
From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Tom Hanstra <hanstra at nd.edu<mailto:hanstra at nd.edu>>
Sent: Tuesday, March 16, 2021 12:51 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] PUI indexing issues

Hello again.

I'm still trying to understand some indexing issues. I've now left my PUI indexing threads and count at the default (which I believe is 1 thread and 25 records/thread). And I have given 4GB to Java processes. I've tried other values as well, but with similar results.

No matter what values I use, I cannot seem to fully index PUI. Each time, it will start well but continuously slow down. I've kept a spreadsheet of the number of records/hr I'm indexing and have several attempts which start in the 50-60K/hr range and then continuously slow down to the 1800-1500/hr speed until finally dying with a Java Heap error. I think I'm headed to that again this round.

Why might this be happening?  Could my data have been corrupted during the transfer from Lyrasis? (I'm working with a database export of our production data). Is the database too far away (our database is in an AWS RDS being accessed from our AWS EC2).

I do have one log which gave this error:

E, [2021-03-12T18:14:53.886243 #2919] ERROR -- : Thread-9472: Failed fetching archival_object id=1484623: too many connection resets (due to Net::ReadTimeout - Net::ReadTimeout) after 0 requests on 3150, last used 1615590893.870297 seconds
ago

prior to the Java Heap error. In that log, there were a number of connections for the staff indexer after the PUI indexer stopped reporting, then an 88 minute gap prior to the above connection error and then finally a Java Heap error in the archivesspace.out log.

Does the indexer reauthenticate each time it connects to get more information?  The earlier question about authentication has me wondering if my database server might be balking at the number of reconnections or something. I'm trying to index 760K records.

Bottom line is that I'm still not getting my PUI index creation to complete. Each run can take several days before it finally fails and I have to start all over again.  I'm looking for any help to track down why this slowdown is occurring and what I can do to address it.

Thanks,
Tom
--
Tom Hanstra
Sr. Systems Administrator
hanstra at nd.edu<mailto:hanstra at nd.edu>

[https://docs.google.com/uc?export=download&id=1GFX1KaaMTtQ2Kg2u8bMXt1YwBp96bvf0&revid=0B7APN9POn6xAQ244WWFYMFU3aVJwZ0lxbmVHK3FxNXlCd0RRPQ]
_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

--
Tom Hanstra
Sr. Systems Administrator
hanstra at nd.edu<mailto:hanstra at nd.edu>

[https://docs.google.com/uc?export=download&id=1GFX1KaaMTtQ2Kg2u8bMXt1YwBp96bvf0&revid=0B7APN9POn6xAQ244WWFYMFU3aVJwZ0lxbmVHK3FxNXlCd0RRPQ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20210316/080c4b97/attachment.html>