Heh..funny..our site does the same thing. Worse, we seem to use about 300MB
of ram for a query that only yields about 60 records! Its a joke. We have
our own home-brewn persistence layer..which I am quite sure is the culprit.
I am hoping that soon we will move to EJB entity beans and what not. I wish
I could figure that out as well.


> -----Original Message-----
> From: Gareth White [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 23, 2000 10:11 AM
> To: Orion-Interest
> Subject: Massive CPU useage
> 
> 
> Hi, I hope someone here can help me.
> I'm recently taken over development of a site that's got a 
> database of about
> 10,000 records, but when I perform a search on them I find my 
> CPU useage
> rockets to 98% and maintains that level for approximately 
> 30-40 seconds.
> This will return about 200 records to me matching my search 
> requirements.
> The search isn't very complex, neither is the data so I'm at 
> a loss as to
> where my CPU cycles are going.
> 
> This is my command line for coercing debuging data from Orion:
> 
> $JAVA -jar -Xms64m -Xmx256m -Dnjava.library.path=$ORION_DIR 
> -Dhttp.session.d
> ebug=true -Ddatasource.verbose=true -Djdbc.debug=true 
> -Dtransaction.log="con
> sole" -Drmi.debug=true -Drmi.verbose=true 
> -Dnnative.user=orion -Xdebug -Xnoa
> gent -Djava.compiler=NONE $ORION_DIR/orion.jar -config
> $ORION_DIR/config/server.xml -console2 >> $ORION_DIR/orion.log 2>&1 &
> 
> The orion.log file seems to consist mostly of pages like this:
> 
> Mon Oct 23 16:24:53 GMT+00:00 2000: 
> 40:1:0:0:0:0:0:0:0:e2:0:e2:62:af:bc:4e:
> started
> Mon Oct 23 16:24:53 GMT+00:00 2000: 
> 40:1:0:0:0:0:0:0:0:e2:0:e2:62:af:bc:4e:
> registered bean GBP
> Mon Oct 23 16:24:53 GMT+00:00 2000: 
> 40:1:0:0:0:0:0:0:0:e2:0:e2:62:af:bc:4e:
> commit attempt
> Mon Oct 23 16:24:53 GMT+00:00 2000: 
> 40:1:0:0:0:0:0:0:0:e2:0:e2:62:af:bc:4e:
> commit succeeded
> Mon Oct 23 16:24:53 GMT+00:00 2000: 
> 41:1:0:0:0:0:0:0:0:e2:0:e2:62:af:bc:5e:
> started
> Mon Oct 23 16:24:53 GMT+00:00 2000: 
> 41:1:0:0:0:0:0:0:0:e2:0:e2:62:af:bc:5e:
> registered bean GBP
> Mon Oct 23 16:24:53 GMT+00:00 2000: 
> 41:1:0:0:0:0:0:0:0:e2:0:e2:62:af:bc:5e:
> commit attempt
> Mon Oct 23 16:24:53 GMT+00:00 2000: 
> 41:1:0:0:0:0:0:0:0:e2:0:e2:62:af:bc:5e:
> commit succeeded
> new DebugResultSet()
> new DebugResultSet()
> new DebugResultSet()
> new DebugResultSet()
> 
> To get an idea of the size of this log, I stopped the server 
> and browser
> connected to it, destroyed the log, started the server up 
> again, connected
> and performed one search.  This resulted in a 303883 byte 
> file, which was
> 5600 lines long.  Most of this output was like the block above.
> 
> To me this looks like Orion's allocating and freeing massive 
> amounts of
> memory and dynamically created loads of instances of the GBP 
> bean (GBP =
> Great Britain Pounds, Sterling currency).  Part of the search will be
> converting from the records native currency to Sterling, so 
> possibly Orion's
> creating a new GBP bean for each and every record returned from the
> database.
> 
> Opinions, suggestions, hints or guesses greatly appreciated.
> Gareth White.
> 

Reply via email to