Este problema foi resolvido com a atualização para o JBoss 7.1.4-SNAPSHOT. Veja este tópico: link
Estou com o desempenho lento no JBoss 7.1.1 Final. Eu escrevi um programa simples que demonstra este comportamento. Eu gero um array de 100.000 números inteiros aleatórios e executo o bubble sort nele.
@Model
public class PerformanceTest {
public void proceed() {
long now = System.currentTimeMillis();
int[] arr = new int[100000];
for(int i = 0; i < arr.length; i++) {
arr[i] = (int) (Math.random() * 200000);
}
long now2 = System.currentTimeMillis();
System.out.println((now2 - now) + "ms took to generate array");
now = System.currentTimeMillis();
bubbleSort(arr);
now2 = System.currentTimeMillis();
System.out.println((now2 - now) + "ms took to bubblesort array");
}
public void bubbleSort(int[] arr) {
boolean swapped = true;
int j = 0;
int tmp;
while (swapped) {
swapped = false;
j++;
for (int i = 0; i < arr.length - j; i++) {
if (arr[i] > arr[i + 1]) {
tmp = arr[i];
arr[i] = arr[i + 1];
arr[i + 1] = tmp;
swapped = true;
}
}
}
}
}
Logo depois de iniciar o servidor, leva aproximadamente 22 segundos para executar esse código. Após alguns dias do JBoss 7.1.1. Em execução, são necessários 330 seg para executar este código. Em ambos os casos, inicio o código quando a utilização da CPU é muito baixa (digamos, 1%). Alguma idéia por quê? Eu corro o servidor com os seguintes argumentos:
-Xms1280m -Xmx2048m -XX:MaxPermSize=2048m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Duser.timezone=UTC -Djboss.server.default.config=standalone-full.xml -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n
Estou rodando no Linux 2.6.32-279.11.1.el6.x86_64 com a versão java "1.7.0_07".
Está dentro do aplicativo J2EE. Eu uso o CDI, portanto, tenho um botão na página JSF que chama o método "proceed" no componente @RequestScoped PerformanceTest. Eu implanto isso como um arquivo de guerra separado e, mesmo que eu desplique outros aplicativos, isso não altera o desempenho.
É uma máquina virtual que compartilha CPUs com outra máquina, mas que não consome nada.
Aqui está outra observação: quando o servidor está após o início e eu executo o tipo bolha, ele utiliza 100% do núcleo de um processador. Nunca muda para outro núcleo ou reduz a utilização abaixo de 95%. No entanto, depois de algum tempo o servidor está rodando e estou tendo problemas de desempenho, o método acima está utilizando o núcleo do processador normalmente 100%, mas acabei de descobrir que essa tarefa está sendo trocada com frequência para outros núcleos. Isto é, no começo ele está rodando no núcleo # 1, depois digamos 2 segundos ele está rodando no # 5 e depois digamos 2 segundos # 8 etc. Além disso, a utilização não é mantida em 100% no núcleo mas às vezes cai para 80% ou ainda mais baixo.
Para o servidor após a reinicialização, embora eu simule um carregamento, ele nunca alterna a tarefa para outro núcleo.
Este problema foi resolvido com a atualização para o JBoss 7.1.4-SNAPSHOT. Veja este tópico: link
Pode estar relacionado ao seguinte erro do Java 7 CodeCache: link .
Tivemos um problema similar de "desaceleração" com o JBoss 7.1.1 e o Java 7 após vários dias de execução. Aumentar ReservedCodeCacheSize
para 256m
e definir UseCodeCacheFlushing
para true
resolveu o problema.
Você pode usar o JConsole para monitorar a utilização do CodeCache.
Eu acredito que o método que você usa 100.000 vezes para um teste (Math.random ()) não produz o mesmo conjunto de números em testes diferentes, então os reordenamentos tomam diferentes tempos. Você deve usar java.util.Random para criar um novo gerador pseudo-aleatório no início de cada teste (que começará com a mesma semente) e usar nextDouble () para obter um novo número; Você pode tentar diferentes testes com diferentes sementes (setSeed (...)).
Tags performance java jboss linux