[Archivesspace_Users_Group] Indexed - but still some issues

Peter Heiner ph448 at cam.ac.uk
Thu Mar 25 17:41:04 EDT 2021


Indeed, -Xss is the stack size, this amount gets allocated for each thread
created. I believe the default is 1MB. A general rule of thumb is to increase
it conservatively if you get a stack overflow error in the app.

p

Trevor Thornton wrote on 2021-03-25 16:59:00:
> I may not be understanding it completely, but from what I've read 256k is
> typical for a 64-bit JVM. Given that, 2m is comparatively big. 1g is 500
> times the default, which seems excessively big.
> 
> On Wed, Mar 24, 2021 at 3:06 PM Tom Hanstra <hanstra at nd.edu> wrote:
> 
> > My understand/reading regarding this setting is that it is the thread size
> > for Java, and has to be big enough to handle the work but cannot be too big
> > either. The default of 2m seems very low. I have been working with the 1g
> > size lately but am not sure that is optimal either. I'd be curious to know
> > if there are optimal numbers that people have found useful.
> >
> > Tom
> >
> > On Wed, Mar 24, 2021 at 12:55 PM Trevor Thornton <trthorn2 at ncsu.edu>
> > wrote:
> >
> >> I'm doing this exact thing right now and I wanted to confirm that the 'g'
> >> here shouldn't be an 'm':
> >> ASPACE_JAVA_XSS="-Xss1g"
> >>
> >> The default looks to be:
> >> ASPACE_JAVA_XSS="-Xss2m"
> >>
> >> https://github.com/archivesspace/archivesspace/blob/master/launcher/archivesspace.sh#L105
> >>
> >> On Wed, Mar 24, 2021 at 11:43 AM Tom Hanstra <hanstra at nd.edu> wrote:
> >>
> >>> Hmmm. So I finally tracked the issue down to my Java settings. For some
> >>> reason, before/during indexing, Java settings of:
> >>>
> >>>     ASPACE_JAVA_XMX="-Xmx8192m"
> >>>     ASPACE_JAVA_XSS="-Xss4g"
> >>>
> >>> worked fine. But, once indexing was complete, those settings were
> >>> somehow unusable. Staff connection would not work, searches failed, etc.
> >>>
> >>> But when I crank down the thread size to:
> >>>
> >>>    ASPACE_JAVA_XMX="-Xmx8192m"
> >>>    ASPACE_JAVA_XSS="-Xss1g"
> >>>
> >>> everything goes back to working. There was a server reboot in there as
> >>> well as numerous restarts with config.rb changes and that was the only
> >>> change that I found could address the issues. Through a number of restarts,
> >>> there was nothing in the logs to indicate the issue. Finally got an error
> >>> that suggested Java space issues and tried the lower value and things now
> >>> work (as far as I've tested at least).
> >>>
> >>> Quite a journey so far...
> >>>
> >>> Tom
> >>>
> >>>
> >>> On Wed, Mar 24, 2021 at 9:54 AM Peter Heiner <ph448 at cam.ac.uk> wrote:
> >>>
> >>>> Tom Hanstra wrote on 2021-03-24 09:25:24:
> >>>> > So, I am now further than I've been yet, at least based upon the
> >>>> logs. But
> >>>> > I still have something not working properly, because when I do a
> >>>> search and
> >>>> > find output, nothing is coming up when I try to look at the found
> >>>> record. I
> >>>> > get the error:
> >>>> >
> >>>> > *We're sorry, but something went wrong.*
> >>>> >
> >>>> > When I've seen that in other applications, it has been a rails issue.
> >>>> Not
> >>>> > sure if that is what is happening here as well.
> >>>>
> >>>> This error should have a corresponding event with at least WARNING
> >>>> level in
> >>>> the frontend/public log (depending on which gave you the error) that
> >>>> you can
> >>>> correlate by event time.
> >>>>
> >>>> > Also, the "Found In" links for the records come back with:
> >>>> >
> >>>> > *The record you've tried to access does not exist or may have been
> >>>> > removed.The record you've tried to access does not exist or may have
> >>>> been
> >>>> > removed.*
> >>>>
> >>>> This would point to the fact that your database and index are not in
> >>>> sync.
> >>>> Given your struggles with indexing I'm starting to wonder if you're
> >>>> reading
> >>>> from the Solr instance you're writing to.
> >>>>
> >>>> p
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>>
> >>
> >>
> >> --
> >> Trevor Thornton
> >> Applications Developer, Digital Library Initiatives
> >> North Carolina State University Libraries
> >> _______________________________________________
> >> 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
> >
> 
> 
> -- 
> Trevor Thornton
> Applications Developer, Digital Library Initiatives
> North Carolina State University Libraries

> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group



More information about the Archivesspace_Users_Group mailing list