Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors.
It appears your application is generating a lot of errors for some
reason. Never tried it myself, but you probably can't disable this lock
with multiple threads running. You should take a look at the error log
to identify the cause of the errors. Then resolve the issue, whatever
it may be.
On 04/30/2015 06:52 PM, Bryan Call wrote:
> This is for Apache Traffic Server and we have no knobs for turning
> on/off FIPS. I am thinking about always disabling FIPS right now and
> that would happen before we create the threads.
>
> I was able to get rid of all the FIPS lock connection with the changes
> you recommend (Big Thanks!). The big one now is type 1. I am
> printing out the log every time the contention total is mod 1M. Are
> there any tricks I can do for type 1 locks?
>
> [Apr 30 22:46:49.549] Server {0x7f1e4531d700} ERROR: contention for
> lock - total contention: 4000000 waiting: 1 file: pmeth_lib.c line:
> 185 type: 10
> [Apr 30 22:46:49.688] Server {0x7f1e45822700} ERROR: contention for
> lock - total contention: 11000000 waiting: 2 file: err.c line: 469 type: 1
> [Apr 30 22:46:50.406] Server {0x7f1e45c26700} ERROR: contention for
> lock - total contention: 4000000 waiting: 0 file: ex_data.c line: 304
> type: 2
> *[Apr 30 22:46:50.932] Server {0x7f1e45b25700} ERROR: contention for
> lock - total contention: 12000000 waiting: 5 file: err.c line: 446
> type: 1*
> [Apr 30 22:46:52.001] Server {0x7f1e45721700} ERROR: contention for
> lock - total contention: 1000000 waiting: 0 file: rand_lib.c line: 212
> type: 19
>
> -Bryan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150501/b31afdec/attachment.html>
