2.1.2 - 100% cpu load

Subscribe to 2.1.2 - 100% cpu load 48 post(s), 19 voice(s)

← Previous 1
 
Avatar fiveten 14 post(s)

Using JBidwatcher 2.1.2 (bidding on ebay.co.uk) with Java 1.6.0_18 under Linux:

JBidwatcher runs status updates for auctions that are already over – including those that are not on Ebay’s servers anymore. This marks my buy/sell history with heaps of red warning triangles and creates 100% cpu load together with heavy network activity.

The network activity stops after all past auctions were pulled once (unsuccessfully) from Ebay’s servers. However, JBidwatcher’s auction update activity still continues (bottom status line changes and the respective auction lines are highlighted).

This goes on indefinitely and creates 100% cpu load generating some sort of slow motion responsiveness.

Is it JBidwatcher’s Linux version only again exhibiting these effects?

I’ve restored my .jbidwatcher directory and went back to the smooth running 2.1pre8.

 
Avatar io 24 post(s)

Same for me with Windows XP.
100% and it seems to use much more RAM and virtual RAM than before.

 
Avatar io 24 post(s)

In fact, I was wrong for the RAM.

The 100% CPU load appears while JBidWatcher is updating auctions.

 
Avatar fiveten 14 post(s)

Thanks for your report – looks like this is platform independent.

Surprisingly, there haven’t been reports of system slow downs due to 100% CPU load. Probably the owners of multi-core CPUs won’t even notice when a single process runs amok and locks up one core.

Now, I’ve upgraded my Java installation from OpenJDK to the latest Sun/Oracle Java:

Java™ SE Runtime Environment (build 1.6.0_21-b06)
Java HotSpot™ Client VM (build 17.0-b16, mixed mode)

No change in behavior, still 100% CPU load. I’ll file two bug reports.

 
Avatar tidris 49 post(s)

I am not seeing this problem on ubuntu 9.10 + latest Oracle java. At jbw startup there is high cpu use while importing the hundreds of finished auctions I keep in the ‘complete’ and ‘selling’ tabs, but after that it settles to low single digit cpu use. I only have a couple dozen auctions in the ‘current’ tab right now. The older auctions in the ‘complete’ and ‘selling’ tabs have “deleted item” red triangles but that doesn’t seem to be causing any trouble for me.

 
Avatar fiveten 14 post(s)

Another test: Started up 2.1.2 with a freshly restored .jbidwatcher directory that was last used with 2.1pre8. Once all auctions in the ‘complete’ tab were grabbed once from Ebay, network activity stops but the status line indicates ongoing auction updates and CPU load stays at 100%. Then quit JBW and restarted 2.1.2: no activity at all, low CPU usage.

So, in first place this looks like a migration issue vanishing when starting 2.1.2 a second time. I didn’t check if 2.1.2 will begin grabbing terminated auctions again some time after a restart.

CPU usage of an idling JBidwatcher 2.1.2 is between 6.0% and 13 , 2.1pre8 uses from 0.7 to 1.0%.

 
Avatar io 24 post(s)

I have updated to the latest JavaRE.
I have deleted all .xml files in the .jbidwatcher folder (I can’t delete everything or I will lose all my auctions), but I still have the same problem.

It will be nice if JBidwatcher had a export/import or save/load auctions feature. We could export or save, delete everything and then update to the lastest JBidwatcher and import or load previously saved auctions.

 
Avatar JoVo 4 post(s)

Running JBidwatcher 2.1.2 on PPC Java 1.5.0_24 fresh installation – same here.
JBidwatcher runs between 40 – 88 % load. But if I switch from main view (current) to other view (completed),
cpu load goes down to 6 – 6 %.

 
Avatar io 24 post(s)

I have deleted everything in .JBidWatcher and now it seems to work fine.
I’ll see after a while if it’s still ok.

 
Avatar io 24 post(s)

In fact, still the same. Maybe 250+ auctions is too much for this new version. There wasn’t any problem with the previous one, even with more auctions.

 
Avatar io 24 post(s)

50 auctions and same result with a freshinstall.
Where can I find the previous version for Windows, I did not backup ? :(

Thanks.

 
Avatar Junks 10 post(s)

I have this too with Win 7 Ultimate – I’ve had to uninstall it :(

I found the previous JBidwatcher version which was working ok before & installed but that’s doing it too now!!! It starts with a blank screen too until you click all over it with the mouse then gradually the graphics appear :(

 
Avatar io 24 post(s)

Ok, I got back to the 2.1.1 version… and guess what, I still have the same problem with 71 auctions.

The 71 auctions are in the “current” tab. When JBidwatcher starts to update the auction the CPU load goes 100%, but if I switch to “complete” or “selling” tab, then JBidwatcher continues to update auctions (yes, it’s normal) but the CPU load stays below 6%.

After all auctions update done, I went back to the ‘current’ tab and CPU load reached again 100% for around 20 seconds, then it stayed between 15-60%.

For the next test, I will add a tab and move some auctions. To see if it’s related to the management of the “current” tab or if it’s a display management issue not matter the tab.

 
Avatar Hauke Fath 14 post(s)

I observed a very sluggish UI response after upgrading to 2.1.2 – reactions to mouse clicks, screen updates, drag&drop are generally > 1 sec, after a context switch it takes JBidwatcher up to 15 sec to react (paging? JBidwatcher VM consumption is ~1000 MB). CPU consumption is between 40% (background) and 90% (foreground).

I have ~25 auctions under current, 10 under complete, and maybe 30 under bought.

MacOS X ppc 10.4.11, 1 GB RAM

[2010-11-08] Fixed by 2.1.3pre2 — thanks, Morgan!
[2010-11-11] I’ll take that back. After a while, 2.1.3pre2 is as sluggish as 2.1.2.

 
Avatar herbie 3 post(s)

Exactly the same behaviour here as Hauke Fath describes, even though I have got much more completed auctions.

JBidwatcher 2.1.2-
Sun Microsystems Inc. Java, version 1.6.0_21 on Linux

 
Avatar io 24 post(s)

Now, I’m running the Java version (.jar) of JBidwatcher 2.1.2.
I have put all auctions in a “Temp” tab, but the behaviour remains the same as when “Current” tab is filled with the auctions.
CPU stays low when an empty tab is displayed (no matter if JBidwatcher has the focus or not) and it goes from 25 to 100% if a tab with auctions is displayed, even if JBidwatcher doesn’t have the focus.
Maybe it’s a display rendering issue.

 
Avatar Junks 10 post(s)

No further forward with this?

 
Avatar gchester 7 post(s)

See my posting on same topic a few days before you original (subject: “memory hog”). Instead, in my case I have complained of being a memory hog, not cpu.
I’ve seen this with the past few versions of jbw, so it’s not unique to newest version. FYI, with MANY (> several hundred) completed auctions, the cpu load also spikes to high % when trying to browse the “completed” tab for the first time in a new session and takes ages (> 5 mins) to display correctly. Once this has settled, then it is only the high (>=40%) memory use that slows down my system and cpu drops back to more normal 5-15% use.
So, are you sure it’s cpu and not ram memory being cheweed up on your system?
Either way, makes using jbw a problem, but am open to thinking that it could also be newer java jre at fault instead of jbw.
Gavin

 
Avatar bassdart 5 post(s)

I think gchester is right, imo it’s an issue with newer java versions.
At least Jbidwatcher runs a a lot faster here again when I use -Dsun.java2d.opengl=true as startup parameter.
Maybe one of the other parameters listed on http://download.oracle.com/javase/1.5.0/docs/guide/2d/flags.html could be also helpful as additional parameter.

Argl, and now after Jbidwatcher runs for 10 minutes or so it’s a bit slow again (but faster than with opengl=false) :-(
Nonetheless I think it’s (also?) a bug in Java as JDownloader also runs extremely slow since yesterday ( I don’t use JDownloader that often but it wasn’t that slow in the last years).
Some more performance tips:
http://performance.netbeans.org/howto/jvmswitches/index.html

I’m using Jbidwatcher 2.1.2 with
$ java -version
java version “1.6.0_20”
Java™ SE Runtime Environment (build 1.6.0_20-b02)

 
Avatar io 24 post(s)

Indeed, it can be a Java issue. It looks much better with JavaRE 1.6.0_22, I had 1.6.0_21 before.
Please update too and give your feedback. Thanks.

 
Avatar Hauke Fath 14 post(s)

Going back from 2.1.2 to 2.1.1, I see a huge improvement in responsiveness. So, the issue has been introduced quite recently. Memory load is still at ~ 1 GB, though, leaving room for improvement. ;)

 
Avatar io 24 post(s)

My solution while waiting for the problem to be identify is to create multiple tabs and put few auctions in each (around 15-20 in my case).
I think it’s a display/“list rendering” problem. I’m gonna try a JavaRE 1.5 (if I find one and if I can downgrade), to see if it comes from there.

[Edit 1]
Wow, it’s back to normal with Java RE 1.5.0_22.
Maybe I’ll try some earlier 1.6.0_xx by curiosity.

[Edit 2]
That was fast. As 1.6.0_21 and 22 gave slow results, I started to test from Java RE 1.6.0_20 to the first one that will be as fast as 1.5.0_22.
Java RE 1.6.0_20 works very fine.

 
Avatar Ivanovich 36 post(s)

I was having these problems too.

I’m running Win 7 64-bit but I’m using both 32- and 64-bit browsers and the problem disappeared totally when I made sure that I had both 32- and 64-bit versions of JavaRE 1.6.0_22.

Now JBidwatcher runs just fine with no problems with rendering or delays.

Java downloads might be fooled to install the wrong version depending on which browser you use to do the download. I had to manually select and download the correct versions.

Yours
Ivan

 
Avatar zappram 287 post(s)

I didn’t have any of the slowness problem UNTIL I updated the Java a few days back based on what Apple Software Update suggested. :( now it’s showing memory leak also and I had to quite the program and restart once or twice a day… or whenever I click the tab and it takes a few seconds to respond…. :(

I am on Mac OS X 10.5.8 Java Version 1.5.0_26 from Apple Inc.

 
Avatar io 24 post(s)

Back after some testing.
I would go for rendering problem, I guess as stated before by someone else it’s a Java issue and I hope that a future version will resolve this.
I was testing with few items in a tab and all was working fine, then I added more auctions, around 80+, and the response time was awful again (bid, snipe, update, everything…).
Then I reduced the JBidwatcher’s window until I just saw 7 auctions and response time was not perfect but good enough.

← Previous 1