Самое главное на этом этапе - определить профиль нагрузки, т.е. какие сервера насколько загружены, как часто и насколько долго там GC происходит, сколько памяти съедается. Иначе любое решение будет наугад.

PS: такой огромный хип (26G) правда нужен? Настолько много данных в память загружается?

Mandarin , 1тыщ/сек - это больше чем я когда-либо обрабатывал, поэтому на мои советы можно не особо полагаться. Это вместе со статикой или это все доходит прям до апп сервера и БД?

Парочка комментариев:
MandarinПри установки объёма памяти исходили из того что много памяти это всегда хорошо.Хм.. как-то нелогично. Чем больше хипа, тем длинней будут full GC задержки. Я бы выделял памяти столько сколько надо, не накидывая сверху просто так.
MandarinВсе сервера нагружены примерно одинаково, zabbix, в среднем, показывает 50% загрузки. Среднее - это медиана? Звучит многовато.. Получается во время пиковой загрузки мы уходим под 100%?
И подобные цифры на БД серверах тоже?
Mandarinчасто клиенты приложений получают ошибку connection timeout.Т.к. это connection timeout, то значит клиент не смог даже подключиться. Т.е. в очередь на соединение (Socket acceptCount) он попал, и ждет когда же до него дойдет обработка. И может это не GC, а просто потоки успевают? Если так то я бы уменьшил maxConnections. Чтоб Томкат не принимал соединения если он не справляется. Счас они видимо приняты и просто ждут своей очереди. Если же уменьшить их, то все connection timeout должны уйти и вместо них появятся connection reset/refused. Но они будут сразу случаться, а не ждать еще таймаута. И не будут лишние ресурсы удерживать.

Но опять же - это все наугад. Надо все-таки замерить и точно узнать GC это или нет. И если GC, то первое что приходит в голову - уменьшать хип.