A máquina com 32GB de RAM, se é para rodar exclusivamente o Elasticsearch, eu começaria configurarando o heap dele para 15G. Esta página do manual dele discute em mais detalhes algumas reocmendações sobre heap: https://www.elastic.co/guide/en/elasticsearch/reference/5.6/heap-size.html
A máquina do JBoss tem bastante memória. A princípio eu colocaria o heap em 26G (que seria o máximo evitando que o JVM não possa usar Zero-Based Compressed Ordinary Object Pointers).
Então deve ficar alguns dias, durante uso normal (ou simulando o consumo normal ou estressando em caso de servidor de teste), monitorando o consumo de heap e tempo gasto em limpeza de GC (para isso pode usar o Java Melody incluído no Lumis Portal ou seu software de monitoramento preferido). Se os fundos pós limpeza estiverem a uma distância saudável do topo e tempo gasto em limpeza satisfatório, manteria isso. Se o topo do heap fica sempre muito abaixo... poderia baixar o máximo do heap... talvez para o dobro do topo usado. Talvez nesse caso a máquina poderia ter menos memória RAM, a não ser que o sistema operacional esteja conseguindo usar o resto em algum cache (e.g.: de disco). Se estiver consumindo muito heap, mesmo após limpezas completas do GC, ou o tempo gasto em GC for considerável, aí precisa reavaliar. No caso de tempo gasto em GC não estar bom, pode também tentar usar o G1 GC (assumindo que vc está usando Java 8) ou fazer outros tunnings de GC ou tentar reduzir o heap se estiver espaço livre grande.
Se a solução possui épocas de pico no uso... é importante monitorar até ocorrer o pico de uso antes de reduzir a capacidade para não ser surpreendido com um uso diferente do que estava vendo. O mesmo vale se há uma previsão de aumento grande no consumo, deve-se deixar margem apropriada.
O -Xms eu recomendo sempre configurar igual ao -Xmx para o JVM não ficar fazendo realocação de memória. Único caso que vejo vantagem em não fazer isso é se o servidor roda várias coisas e possui pouca memória livre e então se deseja que o consumo do java fique variando para liberar para outras coisas. Não que seja algo ideal do ponto de vista de performance, mas pode fazer parte de uma estratégia na decisão de alocação de hardware.
-XX:+AlwaysPreTouch vc pode colocar independentemente do tamanho usado. É só uma indicação para o JVM já tocar no heap para o sistema operacional já alocar, pois alguns sistemas só de fato marcam a memória como ocupada quando ela é tocada, não quando é requisitada. Isso reduz a confusão quando vc analisa detahes dos consumos de memória, porque senão o Java pode estar indicando que usa uma memória que o sistema operacional está indicando que está livre quando normalmente se imaginaria que estaria marcado como alocado nele. Aí de repente o consumo no sistema operacional aumenta mas do Java não... isso ocorreria quando o Java de fato usasse essa memória que o sistema ainda indicava como livre, mas que do ponto de vista do Java já estava alocada. Isso acaba complicando certas análises/entendimentos.
