Проблемы с тайм-аутом подключения - Solaris 11 SPARC

В настоящее время мы проводим некоторые тесты производительности с использованием Solaris 11 (SPARC) на большом оборудовании. Тесты, которые состоят из отправки запросов SOAP (50 КБ на запрос), работают хорошо до тех пор, пока мы не дойдем до числа, кратного тысячам пользователей, т.е. 30 000 пользователей, где примерно через 2 минуты мы начинаем видеть ряд ошибок тайм-аута подключения. в журналах. Использование ЦП и памяти низкое, не более 15% в любое время. Мы используем WebLogic 11g и Oracle HTTP Server.

Я скорректировал следующие параметры TCP, но, похоже, они не повлияли существенно:

_conn_req_max_q  = 262144 (also tried 16384)
_conn_req_max_q0 = 16384 (also tried 4096 - increased to remove tcpListenDrop0 being above 0)
_time_wait_interval = 15000

Я также добавил в / etc / system следующее:

set ip:ipcl_conn_hash_size=16834

Бег netstat -sP tcp в конце теста (сервер был перезагружен перед запуском теста) приводит к:

TCP tcpRtoAlgorithm     =     4     tcpRtoMin           =   200
    tcpRtoMax           = 60000     tcpMaxConn          =    -1
    tcpActiveOpens      =133886     tcpPassiveOpens     =584461
    tcpAttemptFails     =102899     tcpEstabResets      =553474
    tcpCurrEstab        =   339     tcpOutSegs          =35235864
    tcpOutDataSegs      =20302930   tcpOutDataBytes     =842489656
    tcpRetransSegs      = 92070     tcpRetransBytes     =337976
    tcpOutAck           =2044606    tcpOutAckDelayed    =252534
    tcpOutUrg           =     0     tcpOutWinUpdate     =     0
    tcpOutWinProbe      =     0     tcpOutControl       =901262
    tcpOutRsts          = 29486     tcpOutFastRetrans   =     0
    tcpInSegs           =39352489
    tcpInAckSegs        =     0     tcpInAckBytes       =2742139410
    tcpInDupAck         = 32470     tcpInAckUnsent      =     0
    tcpInInorderSegs    =15010534   tcpInInorderBytes   =1321218448
    tcpInUnorderSegs    =  1515     tcpInUnorderBytes   =2008280
    tcpInDupSegs        = 47362     tcpInDupBytes       =160101
    tcpInPartDupSegs    =     0     tcpInPartDupBytes   =     0
    tcpInPastWinSegs    =     0     tcpInPastWinBytes   =     0
    tcpInWinProbe       =     0     tcpInWinUpdate      =     0
    tcpInClosed         =  1099     tcpRttNoUpdate      =   425
    tcpRttUpdate        =11258426   tcpTimRetrans       =194800
    tcpTimRetransDrop   =     4     tcpTimKeepalive     =     0
    tcpTimKeepaliveProbe=     0     tcpTimKeepaliveDrop =     0
    tcpListenDrop       =300269     tcpListenDropQ0     =     0
    tcpHalfOpenDrop     =     0     tcpOutSackRetrans   =     7

Значение tcpListenDrop все еще довольно велико, но оно увеличивается до того, как мы начнем видеть ошибки в журналах, так что это может быть не связано, я не уверен. Есть ли какие-либо другие параметры (TCP), которые стоит настроить, чтобы попытаться уменьшить количество наблюдаемых ошибок? Если нет, какой рекомендуемый способ диагностики такого рода проблемы?