'idp.service.metadata.checkInterval' on specific time
Jim Fox
fox at washington.edu
Fri Mar 22 00:57:32 EDT 2019
Appreciate your contribution. I expect you understand this better than I do.
And, I'm thinking dynamic metadata will soon make all of this mostly academic.
Jim
On Wed, 20 Mar 2019, Ryan Larscheidt wrote:
> Date: Wed, 20 Mar 2019 18:40:46 +0000
> From: Ryan Larscheidt <larscheidt at wisc.edu>
> Reply-To: Shib Users <users at shibboleth.net>
> To: Shib Users <users at shibboleth.net>
> Subject: Re: 'idp.service.metadata.checkInterval' on specific time
>
> We found that -XX:G1ReservePercent=25 (with a 4GB heap) was effective in preventing the "to-space exhausted" events when reloading the InCommon aggregate.
>
> I added a comment with our settings to the IdP Heap Management wiki page: https://wiki.shibboleth.net/confluence/display/IDP30/IdP+Heap+Management?focusedCommentId=55804870#comment-55804870
>
> Ryan
> ________________________________________
> From: users <users-bounces at shibboleth.net> on behalf of Zico <mailzico at gmail.com>
> Sent: Tuesday, March 19, 2019 09:40
> To: Shib Users
> Subject: Re: 'idp.service.metadata.checkInterval' on specific time
>
> A quick question... anyone using initial memory allocation ( Xmx ) and MaxMetaspaceSize?
> I am planning to use "-Xms3072m -Xmx3072m -XX:MaxMetaspaceSize=256m" in production system.
>
> On Mon, Mar 18, 2019 at 12:08 PM Cantor, Scott <cantor.2 at osu.edu<mailto:cantor.2 at osu.edu>> wrote:
> On 3/18/19, 12:52 PM, "users on behalf of Jim Fox" <users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net> on behalf of fox at washington.edu<mailto:fox at washington.edu>> wrote:
>
>> We had a problem with InCOmmon metadata reloads causing memory to fill.
>> It turned out for us that we were triggering manual metadata reloads too
>> often.
>
> I'm on a 3 hour interval, but of course it mostly just no-ops due to it being unchanged outside of each afternoon. It should do that if you manually reload it also (via the actual reload trigger, vs. actually forcibly updating a local copy on disk being read).
>
> -- Scott
>
>
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>
>
>
> --
> Best,
> Zico
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>
More information about the users
mailing list