I do have a proxy in front of SKS, but it impacts queries from GPG as well
during the timeout. I guess the hope is that the sum of the outages
under the higher timeout is less than the sum of the outages under the lower
timeout with the alarm.
I wonder if we have a situation where there are
Jason John Schwarz wrote:
> I pushed my command_timeout up to 180 seconds per Kim's recommendation, but
> that seems to cause the web interface to be very sluggish
> during the period of key loads. I assume that is because the single thread
> is busy. Any thoughts the trade off of the web
Hi
On 04/02/2019 11:35, Jason John Schwarz wrote:
> I pushed my command_timeout up to 180 seconds per Kim's recommendation, but
> that seems to cause the web interface to be very sluggish
> during the period of key loads. I assume that is because the single thread
> is busy. Any thoughts the
Hi,
I've spent last week trying to optimize configuration as much as
possible. Following advise from a previous mail I've added:
command_timeout: 600
wserver_timeout: 30
max_recover: 150
to my sksconf and it seems this fixed majority of the EventLoop
failures. I've added DB_CONFIG
I pushed my command_timeout up to 180 seconds per Kim's recommendation, but
that seems to cause the web interface to be very sluggish
during the period of key loads. I assume that is because the single thread is
busy. Any thoughts the trade off of the web interface being slow
randomly versus
Hi,
Don't get me wrong, but within three days I've got 450G traffic
which can be assigned to sks by 99.9%. Estimated to 30 days this
means 4.5T (which is in good agreement of your 2+T/Key for these
two poison keys).
With this amount of traffic and the possibility to get
more of this keys (thus
