[Java] CPU gebruik van javaw.exe

[Verwijderd]

Ik start een server met javaw.exe en client kunnen inloggen op de server via een applet. Nu is het cpu gebruik soms erg hoog (80%-98%) van javaw...zelfs als er niemand op de server ingelogd is...weet iemand een verklaring hiervoor?

[Alarmnummer]

Welke JRE gebruik je?

[Verwijderd]

versie 1.4.1
zit geen swing ofzo in die de boel kan vertragen

[Alarmnummer]

Hmmzz.. dat is heel vreemd. Ik gebruik zelf java ook veel en ik heb niet vaak last van idioot veel cpu gebruik. Welke applicatie loopt alles te vertragen? De server of de client? Of draait de server niet op je eigen bak?

[Verwijderd]

De server draait niet op me eigen bak nee.
Hij draait op een win2k pc, geen trage pc zover ik weet. En ik heb geen idee wat de boel vertraagt...denk de server, want zoals ik al zei: als er niemand ingelogd is dan gebruik is soms nog veel cpu. Er is ook geen trend in te ontdekken wanneer ie meer cpu gebruikt. Maar kon zijn dat het vaker voorkwam met javaw...ik weet het namelijk ook niet.

[hobbit_be]

als je veel memory gebruikt en Java gaat Garbage Collection gaat die bij mij ook zo hoog en daarna weer miniem. Ik weet bij God niet waarom GC bij Java zo 'slecht' is - daarmee wil ik zeggen ik kan hier elk uur JBuilder (Swing app) herstarten omdat ie ondertussen al men mem heeft opgegeten en dan werkt ie ineens een pak trager omdat ie dan voor elke start weer moet gaan GC... Java zou gewoon veel aggresiever moeten GC'en wanner de CPU idle is bijvoorbeeld...

[Verwijderd]

Even inhaken op Dennis
Het hele spul draait namelijk op mijn bak....

Is dit een specifiek java "probleem" of is het OS gerelateerd?
Zou het met, bijvoorbeeld een linuxbak nog steeds plaats vinden?

[wasigh]

ik denk dat het eerder aan het progamma ligt

[Verwijderd]

wasigh schreef op 24 April 2003 @ 14:55:
ik denk dat het eerder aan het progamma ligt

Verklaar je nader?

[PommeFritz]

Run je programma eens met profiling aan (-Xprof optie) en kijk waar hij zo lang in vertoeft.

[Verwijderd]

Gebruik je soms ergens een while(true); lus of iets dergelijks? Want dan wil je processor wel naar 100% toe vliegen.

[Verwijderd]

Verwijderd schreef op 24 April 2003 @ 20:51:
Gebruik je soms ergens een while(true); lus of iets dergelijks? Want dan wil je processor wel naar 100% toe vliegen.

Wel iets dergelijks ja...de server maakt voor elke client een Thread aan en daar zit een while(boolean) loop in ja...maar als er geen data transfer tussen client en server is kan de server toch niet traag worden...die heeft immers niets te doen?

[TaXaN]

Je doet dus aan busy waiting. Dat brengt je CPU gebruik naar 100% ja. Al die threads doen niets anders dan "iets te doen? nee. iets te doen? nee. iets te doen? nee. ...". De processor is dus constant bezig.

[Verwijderd]

TaXaN schreef op 25 April 2003 @ 00:10:
Je doet dus aan busy waiting. Dat brengt je CPU gebruik naar 100% ja. Al die threads doen niets anders dan "iets te doen? nee. iets te doen? nee. iets te doen? nee. ...". De processor is dus constant bezig.

En hoe voorkom je dat?

[Stubby]

Onder Unix heb je een select statement (ook nog eens onder C) Misschien dat er ook iets dergelijks voor java is?

[Glimi]

In java heb je Thread.sleep( ) en Thread.yield() om zo in de loop aan te geven dat je eerst even wilt wachten (en dan anderen een kans geeft) en daarna weer verder wilt met je loop

[PommeFritz]

Makkelijkste is om in Java blocking sockets te gebruiken. Een read op een socket die geen data oplevert blockt en neemt 0% cpu tijd. Helaas heeft Java geen select()-constructie, hoewel daar in het NIO framework in jdk 1.4+ verandering in is gekomen heb ik begrepen.

[Soultaker]

Aangezien je al een aparte thread per client gebruikt, lijkt me hierover geen discussie mogelijk: gebruik blocking socket operations, zoals PommeFritz al aangaf.

[Verwijderd]

PommeFritz schreef op 25 April 2003 @ 00:49:
Makkelijkste is om in Java blocking sockets te gebruiken. Een read op een socket die geen data oplevert blockt en neemt 0% cpu tijd. Helaas heeft Java geen select()-constructie, hoewel daar in het NIO framework in jdk 1.4+ verandering in is gekomen heb ik begrepen.

En hoe block ik dan zoiets? Dus een methode aanroepen zolang er geen data is? Ik ken geen methode die dat doet? Verklaar je eens nader...

[Verwijderd]

PommeFritz schreef op 24 April 2003 @ 20:02:
Run je programma eens met profiling aan (-Xprof optie) en kijk waar hij zo lang in vertoeft.

82% aan SocketInputStream lezen idd

[Verwijderd]

accept() methode van de serversocket en de readUTF() methode van de inputstream zijn toch al standaard geblokkeerd totdat er een connectie/data binnenkomt?

[Soultaker]

Verwijderd schreef op 25 April 2003 @ 13:01:
accept() methode van de serversocket en de readUTF() methode van de inputstream zijn toch al standaard geblokkeerd totdat er een connectie/data binnenkomt?

Klopt inderdaad, voor zover ik weet. Kun je anders een minimaal voorbeeld (1 scherm code max.) maken wat het probleem illustreert? Dan kunnen wij het hier ook een beetje testen.

Er bestaat een kans dat er een foutje in de JVM zit, waardoor er iets mis gaat met socket I/O of de thread management van de JVM, maar dat is zo moeilijk vast te stellen. De kans is natuurlijk groter dat je zelf een fout gemaakt hebt, maar om dat te kunnen beoordelen hebben we een stukje voorbeeldcode nodig.

[Verwijderd]

De Server.java:

Java:

import java.io.*;
import java.net.*;

//De hoofdserver
public class Server
{
    public static void main(String[] args) throws IOException
    {
        try
        {
              //nieuw object van de ClientHandler
              ClientHandler ch = new ClientHandler();
            
              //Server luistert op poort 25000
               ServerSocket serversocket = new ServerSocket(25000);
               System.out.println("Server is listening on port 25000");
            
               while(true)
               {
                   //Accepteer alle inkomende verbindingen
                   Socket clientsocket = serversocket.accept();
            
                   //Voeg de client toe 
                  ch.addNewClient(clientsocket);            
                }           
        }
        catch(IOException e)
        {           
            System.exit(0);
        }
}

De ClientHandler voegt de client toe (en andere dingen, niet belangrijk nu)

Java:

//Methode om een nieuwe client toe te voegen 
public synchronized void addNewClient(Socket socket)
{
    Client client = new Client(socket, this);
}

En de Client.java maakt een Thread aan voor elke client..hij worden ook de binnenkomende data verwerkt...enkele methodes:

Java:

public class Client implements Runnable
{
    //**CONSTRUCTOR**
    public Client(Socket socket, ClientHandler ch)
    {
        this.socket = socket;
        this.ch = ch;
    
        try
        {
             //maak de input en output streams aan
            streamIn = new DataInputStream(socket.getInputStream());
            streamOut = new DataOutputStream(new BufferedOutputStream(socket.getOutputStream()));
        }
        catch(IOException e) 
        {
             System.out.println("Fout tijdens aanmaken van de in- en output streams" + e.toString());
        }
        
        //hier enkele andere initialisaties
        
        //start de thread
          runner = new Thread(this);
          runner.start();
}

public void run()
{
     while(isRunning)
     {          
          try
          {
                 //lees een binnengekomen message
                   String text = streamIn.readUTF();
                //Voer juiste commando uit, na message-check
                 chatCommand(text); //commando of data wordt verwerkt
          }
          catch(IOException e) 
          {//wordt wel afgevallen, boeit ff niet wat ie doet
          }
     }
}

[Verwijderd]

Wat kan hier mis aan zijn dan?

[ Voor 8% gewijzigd door Verwijderd op 25-04-2003 18:13 ]

[Soultaker]

Kun je niet een volledig representatief voorbeeld geven; gewoon één file dus, die direct werkt, zonder dat ik 'm hoef aan te passen?

[Verwijderd]

Ik zie geen rare dingen in bovenstaande code die de boel erg kunnen vertragen. Nu bevat 1 klasse wel veel synchronized methoden. Weet iemand in hoeverre synchronized methoden de boel vertragen?

[mbravenboer]

Dennis26: Weet iemand in hoeverre synchronized methoden de boel vertragen?

Zie dit artikel: Urban performance legends (IBM developerWorks)

[Verwijderd]

Hmm thnx mbravenboer
Dan weet ik ook niet waardoor de server af en toe veel cpu gebruikt

[mbravenboer]

Kan het zijn dat er in een bepaalde toestand van de Client steeds opnieuw een exception optreedt bij het lezen van de stream? Als deze exceptions niet worden gerapporteerd is het niet te zien dat dit gebeurt. Deze situatie zou voor kunnen komen als je de 'lees-thread' niet sluit nadat de client de connectie heeft gesloten. Dit zou verklaren waarom er busy-wait achtige verschijnselen optreden, terwijl je duidelijk niet busy-wait.

Ik zou dus eens goed debuggen en even kijken welke server-side Clients ((zogenaamd?) open connecties) er voortdurend zijn op de server. Dit is sowieso wel nuttige informatie, ook voor een systeem dat al wel goed werkt .

[ Voor 11% gewijzigd door mbravenboer op 29-04-2003 12:22 ]

[Cow_tipping]

Als leek op het gebied van java wilde ik toch iets toevoegen.
Er zijn distributed computerprogrammas die gebruik maken van jawaw.exe. De clienten van TSC en D2OL van het bedrijf Sengent geven 100% processorbelasting. Ik weet alleen niet meer zeker of die ook allemaal ten goede komen aan javaw.exe of een ander proces.

[Verwijderd]

mbravenboer schreef op 29 april 2003 @ 12:20:
Kan het zijn dat er in een bepaalde toestand van de Client steeds opnieuw een exception optreedt bij het lezen van de stream? Als deze exceptions niet worden gerapporteerd is het niet te zien dat dit gebeurt. Deze situatie zou voor kunnen komen als je de 'lees-thread' niet sluit nadat de client de connectie heeft gesloten. Dit zou verklaren waarom er busy-wait achtige verschijnselen optreden, terwijl je duidelijk niet busy-wait.

Alle exceptions worden keurig gerapporteerd Wat de 'lees-thread' betreft:

Java:

while(isRunning)
{
    //lees data
}

Als de client disconnect of zijn browser sluit, dan worden de Thread en de client zelf uiteraard verwijderd. Bovendien wordt 'isRunning' false. Er blijven geen threads achter nadat de client weg is. Dat weet ik zeker

[ Voor 3% gewijzigd door Verwijderd op 29-04-2003 13:10 ]