worker process exited on signal 11

Ср Авг 5 15:31:34 UTC 2015

Коллеги,

поставил новый сертификат SSL на nginx от WoSIGN (бесплатный). Предыдущий
стоял StartSSL.
процессы nginx worker стали падать в Seg fault (11) на некоторых запросах,
которых не поймать.

После падения процесса в статистике stub_status висят соединения от этих
клиентов, последующие соединения при настроенном "limit_conn addr 10"
получают 503, то есть nginx думает что есть установленные соединения. По
netstat таких соединений нет вовсе (штук 20 висят живых).

В логах веселее:
2015/08/05 16:38:18 [alert] 17131#17131: worker process 18807 exited on
signal 11 (core dumped)
2015/08/05 16:41:16 [alert] 17131#17131: worker process 19852 exited on
signal 11 (core dumped)
2015/08/05 16:44:12 [alert] 17131#17131: worker process 20566 exited on
signal 11 (core dumped)
2015/08/05 16:47:12 [alert] 17131#17131: worker process 20812 exited on
signal 11 (core dumped)
2015/08/05 16:50:15 [alert] 17131#17131: worker process 19592 exited on
signal 11 (core dumped)
2015/08/05 16:53:15 [alert] 17131#17131: worker process 22300 exited on
signal 11 (core dumped)

2015/08/05 17:53:16 [alert] 17131#17131: worker process 680 exited on signal
11 (core dumped)
2015/08/05 17:56:16 [alert] 17131#17131: worker process 32332 exited on
signal 11 (core dumped)
2015/08/05 17:59:13 [alert] 17131#17131: worker process 870 exited on signal
11 (core dumped)
2015/08/05 18:02:13 [alert] 17131#17131: worker process 1658 exited on
signal 11 (core dumped)
2015/08/05 18:05:13 [alert] 17131#17131: worker process 1865 exited on
signal 11 (core dumped)
2015/08/05 18:08:14 [alert] 17131#17131: worker process 2641 exited on
signal 11 (core dumped)

2015/08/05 18:20:13 [alert] 17131#17131: worker process 4580 exited on
signal 11 (core dumped)

Есть два сервера для опытов.
Первый:
nginx version: nginx/1.6.2
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)
TLS SNI support enabled

Второй:
nginx version: nginx/1.9.3
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC)
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled

У сервера нагрузка до 200 запросов в минуту.
Вот два графика:
1. Обычная нагрузка на старом сертификате:
https://yadi.sk/i/hL74eSUwiHf2b

2. После смены сертификата:
https://yadi.sk/i/BURXJSwqiHf6P

Грешил на стабильную ветку, перевел посетителей на второй сервер с
mainline-версией. Ситуация аналогичная. Вот график:
https://yadi.sk/i/a4VrM7sKiHfNs

Падения на графиках - рестрат nginx руками. На первом worker_connections 
1024, на втором уже 5096 поставил. Проблема не решается.
Проверить опять на старом сертификате не получится - он истёк.

Вот текущий stub_status:
Active connections: 2436 
server accepts handled requests
 9513 9513 19672 
Reading: 0 Writing: 674 Waiting: 1719 

Статистика в Apache совсем детская:
Total accesses: 20550 - Total Traffic: 31.6 MB
CPU Usage: u283.26 s32.49 cu.88 cs0 - 1.23% CPU load
.801 requests/sec - 1292 B/second - 1613 B/request
1 requests currently being processed, 9 idle workers

Нагрузка на сервере LA 0.10.
Есть push-соединения на обычном http, они не проблемные, их 20-30,
проксируются на dklab_realplexor. Если их отключить, ситуация не
исправлялась вовсе.

Для временного решения проблемы пришлось всех клиентов принудительно
перенаправлять на с https на http, но соединения всё-равно висят и копятся.

Подобные сертификаты стоят и на других серверах (получены месяц назад),
таких проблем нет. Свежий, видимо, выносит мозг.
Есть возможность поковырять первый сервер. Подскажите, каким образом можно
локализовать проблему?

spdy не влияет, включили уже с этой проблемой.

Конфиг простой:
server {
    listen 443 spdy;
    limit_conn addr 20;

    server_name  site.ru www.site.ru;

	ssl on;
	ssl_certificate         /etc/nginx/ssl_2015/ssl2.crt;
	ssl_certificate_key /etc/nginx/ssl_2015/ssl2.key;
	ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
	ssl_ciphers 'HIGH:!aNULL:!MD5:!kEDH';

	ssl_session_timeout 28h;
	ssl_prefer_server_ciphers on;
	ssl_stapling on;
	ssl_stapling_verify on;
	ssl_trusted_certificate "/etc/nginx/ssl_2015/ssl2.crt";
	resolver 8.8.8.8 8.8.4.4 valid=300s;
	resolver_timeout 5s;

    error_page   500 502 503 504  /503.html;
    location = /503.html {
        root   /home/site/public_html;
    }

    if ( $ipban ) {
         return 403;
    }

	location ~* /static {
		root        /home/site/public_html;
		expires     30d;
		access_log off;
		limit_req zone=one burst=50 nodelay;
		limit_conn addr 30;
	}

	location / {
		limit_req zone=one burst=20 nodelay;
		proxy_pass   http://127.0.0.1:8080;
		proxy_redirect off;
		proxy_set_header    Host    $host;
		proxy_set_header    X-SSL    "yes";
		proxy_set_header    X-Real-IP       $remote_addr;
		proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header Range "";
		proxy_set_header Request-Range "";
		client_max_body_size        24m;
		client_body_buffer_size     128k;
		proxy_connect_timeout       90;
		proxy_send_timeout  90;
		proxy_read_timeout  90;
		proxy_buffer_size   4k;
		proxy_buffers       4 32k;
		proxy_busy_buffers_size     64k;
		proxy_temp_file_write_size  64k;
	}

}

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,260795,260795#msg-260795