just_vladimir,

А ссылку можно, где написано про 2560Мб ? Не должно быть, по идее, такого ограничения для Java x64.
Вообще нужно включать verboseGC и анализировать потребление памяти инстансом, после чего принимать решение о изменении размеров Heap.

Отдавать все 45 ГБ одному инстансу я бы не стал без очень особых на то причин, т.к. в зависимости от приложений эта память может быть не задействована вообще. Приложения в этом плане весьма индивидуальны, поэтому нужно смотреть на потребности приложения.
Как вариант можно сделать ND-кластер из нескольких инстансов на этой машине, выделив каждому инстансу определенный процент памяти. Начать например с 4ГБ и анализировать логи GC. Несколько инстансов должны быть более эффективны, если не будет конкуренции по другим ресурсам (процессор, IO, и т.п.).

just_vladimir,

Тезисно:
1. Если память на сервере не задействована - это по сути прямой "убыток", т.е. серверные мощности недогружены.
2. 64-битный JDK полезен для случаев, когда приложениям нужен большой (более 2ГБ) объем памяти.
Но, 64-битность не бесплатна. Приложение в 64-битном JDK может работать медленнее, чем в 32-битном и для него будет больший расход ОЗУ, т.к. в режиме 64-бит указатели и служебные структуры занимают больший объем. Поэтому нужно обязательно тестировать работу приложения (нагрузочное тестирование) и в 32-бит и в 64-бит режиме, чтобы понять есть ли в конкретном случае выйгрыш от 64-битного режима. Понятно, что если приложению просто нужен большой объем памяти для нормальной работы, то 64-битный режим обязателен.
Подробнее по ссылкам (что нашлось и вспомнилось):
64-bit versus 32-bit JVM: Understanding performance implications for WebSphere Commerce sites
WAS V7 64-bit performance : Introducing WebSphere Compressed Reference Technology
32 bit versus 64 bit Java Runtimes

3. Вертикальный кластер для WAS рекомендуется для более полной утилизации процессоров/памяти на многопроцессорных серверах. Каждый отдельный сервер внутри кластера - это отдельная JVM. Т.е. даже на 32-битной JDK можно "скушать" доступное количество ОЗУ и более равномерно нагрузить имеющиеся процессоры. Плюс появляется избыточность, т.е. если один из серверов "умрет" или "повиснет", это не скажется на доступности приложений для конечных пользователей. Плюс не будет пауз при работе GC внутри JVM, вернее паузы то будут, но т.к. у нас много процессов, то работа GC будет менее заметна, чем в случае одиночного сервера.

just_vladimir,

Если куплен "WebSphere Application Server" в варианте "Network Deployment", или продукт, в состав которого он входит как интегральная часть, то лицензия должна быть на определенное количество PVU, т.е. на процессорную мощность. В этом случае организация кластера на той же серверной мощности не должна менять стоимость. Но, лучше конечно уточнить этот момент.