[Archivesspace_Users_Group] PUI indexing issues

[Tom Hanstra]

Thanks, Blake.

In your testing, how big was the repository that you were testing against.
Mine has "763368 archival_object records" and I consistently get into the
670K range for staff and 575 range for PUI before things really slow down.
I'm now trying to really increase the Java settings to see if that will
help. So far, the problem is similar: real slow downs after zipping through
the first records. I'll also try some of the settings you have there to see
if fewer but larger threads work better than multiple smaller threads.

Tom

On Mon, Mar 22, 2021 at 10:52 AM Blake Carver <blake.carver at lyrasis.org>
wrote:

> I did some experimenting this weekend, messing around with indexer speeds,
> and found I could get it to succeed with the right indexer settings. I
> think the answer is going to be "it depends" and you'll need to experiment
> with what works on your set up with your data. I started with the defaults,
> then dropped it to reallllly slow (1 thread 1 per), then just tried to dial
> it up and down. The last one I tried worked fine, it was fast enough to
> finish in a reasonable amount of time and didn't slow down or crash. Your
> settings may not look like this, but here's something to try.
>
> AppConfig[:pui_indexer_records_per_thread] = 50
> AppConfig[:pui_indexer_thread_count] = 1
>
>
> So some extra detail for the mailing list archives... if your site keeps
> crashing before the indexers finish and you're not seeing any particular
> errors in the logs that make you think you have a problem with your data,
> try turning the knobs on your indexer speed and see if that helps.
>
> It looks like maybe the indexer just eats up too much memory on BIG
> records and having too many (too many being 15ish) threads running causes
> it to crash. I know BIG is pretty subjective, if you have a bunch of
> resources (maybe a few thousand) AND those resources all have ALLOTA (maybe
> a few thousand) children with ALLOTA subjects/agents/notes/stuff, then you
> might hit this problem. Seems like it's not the total number of resources,
> it's probably because those resources are big/complex/deep.
>
> ------------------------------
> *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:* Thursday, March 18, 2021 11:24 AM
> *To:* Archivesspace Users Group <
> archivesspace_users_group at lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] PUI indexing issues
>
> Dave,
>
> Thanks for the suggestion, but unless there is some direct limitation
> within Solr, that should not be an issue. My disk is at only about 50% of
> capacity and Solr should be able to expand as needed. In my case, I don't
> think there has been much addition to Solr because I'm reindexing records
> which have been indexed already. So the deleted records are growing, but
> not the overall number of records. My index is currently at about 6GB.
>
> Any other thoughts out there?
>
> Thanks,
> Tom
>
> On Thu, Mar 18, 2021 at 10:51 AM Mayo, Dave <dave_mayo at harvard.edu> wrote:
>
> This is a little bit of a shot in the dark, but have you looked at disk
> space on whatever host Solr is resident on? (the ASpace server if you’re
> not running an external one)?
>
> A thing we’ve hit a couple times is that Solr, at least in some
> configurations, needs substantial headroom on disk to perform well – I
> think it’s related to how it builds and maintains the index?  So it might
> be worth looking to see if Solr is filling up the disk enough that it can’t
> efficiently handle itself.
>
>
>
> --
>
> Dave Mayo (he/him)
>
> Senior Digital Library Software Engineer
> Harvard University > HUIT > LTS
>
>
>
> *From: *<archivesspace_users_group-bounces at lyralists.lyrasis.org> on
> behalf of Tom Hanstra <hanstra at nd.edu>
> *Reply-To: *Archivesspace Users Group <
> archivesspace_users_group at lyralists.lyrasis.org>
> *Date: *Wednesday, March 17, 2021 at 11:43 AM
> *To: *Archivesspace Users Group <
> archivesspace_users_group at lyralists.lyrasis.org>
> *Subject: *Re: [Archivesspace_Users_Group] PUI indexing issues
>
>
>
>
>
>
>
> - 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?
>
>
>
>
>
> Just to follow up on my earlier post, I did get even lower numbers from
> Blake to try based upon what he used for our hosted account. But I'm seeing
> the same pattern in terms of slowdowns regarding the number of records that
> get processed/hour. Is this typical?  Is it just hitting records that have
> more work to be done? Or do I still have a resource issue.
>
>
>
> I note that the number of docs in Solr has not changed at all throughout
> the last couple of attempts, which again leads me to believe it has already
> handled these records (at least once) before and thus there is no more
> indexing to really be done with the records which it is running through
> the PUI indexer again. Which leads back to the "why does PUI indexing
> restart each time from 0" question. How does one add an enhancement request
> to have this reviewed and (perhaps) changed?
>
>
>
> Thanks,
>
> Tom
>
>
>
> --
>
> *Tom Hanstra*
>
> *Sr. Systems Administrator*
>
> hanstra at nd.edu
>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> 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
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20210322/e14e9b75/attachment.html>