NIO Selector.select() enters a 100% CPU infinite loop on interruption

This issue is only reproducible in Windows.
When a thread is calling Selector.select() and the other thread interrupts the selector thread, Selector.select() enters an infinite loop taking up CPU time.  All other JDKs I've tried including IBM 1.5 / 1.6, SUN 1.5 / 1.6 simply returned 0 when its interrupted.  I think JRockit needs to behave similarly, without 100% CPU consumption.  Here's the test code:
import java.nio.channels.Selector;
public class Main {
      public static void main(String[] args) throws Exception {
              final Thread mainThread = Thread.currentThread();
              final Selector s = Selector.open();
              new Thread() {
                      @Override
                      public void run() {
                                  try {
                                            Thread.sleep(1000);
                                  } catch (InterruptedException e) {
                                            // Ignore.
                                  System.out.println("interrupt()");
                                  mainThread.interrupt();
              }.start();
              System.out.println("select()");
              s.select(5000);
              System.out.println("success");
              s.close();
Expected result:
        select()
        interrupt()
        success
Actual result:
        select()
        interrupt()
        <stuck with 100% CPU consumption>
Version:
        JRMC-3.0.3-1.5.0 - build R27.6.0-50_o-100423-1.5.0_15-20080626-2105-windows-ia32, compiled mode
        JRMC-3.0.3-1.6.0 - build R27.6.0-50_o-100423-1.6.0_05-20080626-2105-windows-ia32, compiled mode

Hi,
This looks like a bug. Please open a support ticket and request a patch if you need a fix asap. If you can wait we will fix this in an upcoming release. Thank you for your help

Similar Messages

  • Tab selection property causing 100% CPU usage

    Hi,
    I've having some trouble with using property nodes to tab selection. After 1-2 hours the CPU usage is 100%. The VI is attached. I'm using LV 6.0.2 on win2000. Does anyone have a clue of what's happening?
    Attachments:
    tab_selector_property.vi ‏22 KB

    Every time the while loop executes, you open *new* pages reference array. Whitout closing them, you quickly fill the memory and hog the computer usage. As in the modified VI attached, get the references only once outside the while loop and reuse them. Close any reference after use. As much as possible, you shoud use the control terminal to read its value instead of reading the value property.
    LabVIEW, C'est LabVIEW
    Attachments:
    tab_selector_property.vi ‏25 KB

  • 100% cpu usage due to nio selector.open

    Hello guys,
    I am developing a multiplayer game using nio.In the begging i read all document related to nio.I have never heared about this api uses 100% cpu at server side as well as client side.
    When i start my server which is non blocking the cpu usage is dierctly raise to 100%.Working on Operating System windows 2000.Here is my code of server side.
    public void initializeOperations() throws IOException,UnknownHostException
              System.out.println("Inside initialization");
              sel = Selector.open(); //THIS FUNCTION RAISES CPU PERFORMANCE TO 100%....
              server = ServerSocketChannel.open();
              server.configureBlocking(false);
              InetAddress ia = InetAddress.getLocalHost();
              //InetSocketAddress isa = new InetSocketAddress(ia,port);
              InetSocketAddress isa = new InetSocketAddress(ia,port);
              server.socket().bind(isa);
         public void run() //startServer() throws Exception
              try
                   System.out.println("Inside startserver run()");
         initializeOperations();
                   SelectionKey acceptKey = server.register(sel, SelectionKey.OP_ACCEPT );
                   while (acceptKey.selector().select() > 0 )
              Set readyKeys = sel.selectedKeys();
              Iterator it = readyKeys.iterator();
              while (it.hasNext()) {
              SelectionKey key = (SelectionKey)it.next();
              it.remove();
              if (key.isAcceptable())
              System.out.println("Key is Acceptable");
    ServerSocketChannel ssc = (ServerSocketChannel) key.channel();
         socket = (SocketChannel) ssc.accept();
         socket.configureBlocking(false);
    SelectionKey another = socket.register(sel,SelectionKey.OP_READ|SelectionKey.OP_WRITE);
              if (key.isReadable())
                                  System.out.println("Key is readable");
                                  String ret = readMessage(key);
                                  System.out.println("Frm clinet:"+ret);
                                  socket = (SocketChannel)key.channel();
              catch(Exception e)
                   System.out.println("Exception in ServerConnection:run()");
                   e.printStackTrace();
    Please see the code where i mentioned comment at that time cpu usage goes upto 100%.
    i searched the forum and find that OP_WRITE is creating problem but in my case even client is not comming than also server side cpu usage raises.
    please suggest proper solution
    thank you

    thank you for your suggestion...
    so u r telling to compile my application in new version of jdk and run from there..m i right???ok...
    i have tried this also in latest version jdk1.5.0_04 than also my cpu usage raise to 100%..
    Now i m trying using 1.4.2_08 hope it will work....
    is there any other idea to solve my problem please help me out...
    thank you

  • Audio Bin - Select unused - Delete - Hangs on 100% CPU for long time

    Hi
    I am running Logic Studio 9.0.2 on OS X 10.5.8 on a Mac Pro. Logic was upgraded from version 7.
    In Audio Bin and "Select Unused" and then "Delete", the application might hang on 100% CPU for hours on large projects.
    Anyone with an idea of what the problem might be? This was not a problem i Logic Pro 7.
    Thanks!
    GD

    I have this same problem, though I'm on 10.5.7. I was hoping maybe updating the OS would help but apparently not. I also get very slow file-selection windows sometimes, like when I go to bounce a file. Navigating to a specific folder is painfully slow. Would like to hear if any Snow Leopard users are experiencing this.
    Bull

  • SQL stored procedure Staging.GroomDwStagingData stuck in infinite loop, consuming excessive CPU

    Hello
    I'm hoping that someone here might be able to help or point me in the right direction. Apologies for the long post.
    Just to set the scene, I am a SQL Server DBA and have very limited experience with System Centre so please go easy on me.
    At the company I am currently working they are complaining about very poor performance when running reports (any).
    Quick look at the database server and CPU utilisation being a constant 90-95%, meant that you dont have to be Sherlock Holmes to realise there is a problem. The instance consuming the majority of the CPU is the instance hosting the datawarehouse and in particular
    a stored procedure in the DWStagingAndConfig database called Staging.GroomDwStagingData.
    This stored procedure executes continually for 2 hours performing 500,000,000 reads per execution before "timing out". It is then executed again for another 2 hours etc etc.
    After a bit of diagnosis it seems that the issue is either a bug or that there is something wrong with our data in that a stored procedure is stuck in an infinite loop
    System Center 2012 SP1 CU2 (5.0.7804.1300)
    Diagnosis details
    SQL connection details
    program name = SC DAL--GroomingWriteModule
    set quoted_identifier on
    set arithabort off
    set numeric_roundabort off
    set ansi_warnings on
    set ansi_padding on
    set ansi_nulls on
    set concat_null_yields_null on
    set cursor_close_on_commit off
    set implicit_transactions off
    set language us_english
    set dateformat mdy
    set datefirst 7
    set transaction isolation level read committed
    Store procedures executed
    1. dbo.p_GetDwStagingGroomingConfig (executes immediately)
    2. Staging.GroomDwStagingData (this is the procedure that executes in 2 hours before being cancelled)
    The 1st stored procedure seems to return a table with the "xml" / required parameters to execute Staging.GroomDwStagingData
    Sample xml below (cut right down)
    <Config>
    <Target>
    <ModuleName>TransformActivityDim</ModuleName>
    <WarehouseEntityName>ActivityDim</WarehouseEntityName>
    <RequiredWarehouseEntityName>MTV_System$WorkItem$Activity</RequiredWarehouseEntityName>
    <Watermark>2015-01-30T08:59:14.397</Watermark>
    </Target>
    <Target>
    <ModuleName>TransformActivityDim</ModuleName>
    <WarehouseEntityName>ActivityDim</WarehouseEntityName>
    <RequiredWarehouseEntityName>MTV_System$WorkItem$Activity</RequiredWarehouseEntityName>
    <ManagedTypeViewName>MTV_Microsoft$SystemCenter$Orchestrator$RunbookAutomationActivity</ManagedTypeViewName>
    <Watermark>2015-01-30T08:59:14.397</Watermark>
    </Target>
    </Config>
    If you look carefully you will see that the 1st <target> is missing the ManagedTypeViewName, which when "shredded" by the Staging.GroomDwStagingData returns the following result set
    Example
    DECLARE @Config xml
    DECLARE @GroomingCriteria NVARCHAR(MAX)
    SET @GroomingCriteria = '<Config><Target><ModuleName>TransformActivityDim</ModuleName><WarehouseEntityName>ActivityDim</WarehouseEntityName><RequiredWarehouseEntityName>MTV_System$WorkItem$Activity</RequiredWarehouseEntityName><Watermark>2015-01-30T08:59:14.397</Watermark></Target><Target><ModuleName>TransformActivityDim</ModuleName><WarehouseEntityName>ActivityDim</WarehouseEntityName><RequiredWarehouseEntityName>MTV_System$WorkItem$Activity</RequiredWarehouseEntityName><ManagedTypeViewName>MTV_Microsoft$SystemCenter$Orchestrator$RunbookAutomationActivity</ManagedTypeViewName><Watermark>2015-01-30T08:59:14.397</Watermark></Target></Config>'
    SET @Config = CONVERT(xml, @GroomingCriteria)
    SELECT
    ModuleName = p.value(N'child::ModuleName[1]', N'nvarchar(255)')
    ,WarehouseEntityName = p.value(N'child::WarehouseEntityName[1]', N'nvarchar(255)')
    ,RequiredWarehouseEntityName =p.value(N'child::RequiredWarehouseEntityName[1]', N'nvarchar(255)')
    ,ManagedTypeViewName = p.value(N'child::ManagedTypeViewName[1]', N'nvarchar(255)')
    ,Watermark = p.value(N'child::Watermark[1]', N'datetime')
    FROM @Config.nodes(N'/Config/*') Elem(p)
    /* RESULTS - NOTE THE NULL VALUE FOR ManagedTypeViewName
    ModuleName WarehouseEntityName RequiredWarehouseEntityName ManagedTypeViewName Watermark
    TransformActivityDim ActivityDim MTV_System$WorkItem$Activity NULL 2015-01-30 08:59:14.397
    TransformActivityDim ActivityDim MTV_System$WorkItem$Activity MTV_Microsoft$SystemCenter$Orchestrator$RunbookAutomationActivity 2015-01-30 08:59:14.397
    When the procedure enters the loop to build its dynamic SQL to delete relevant rows from the inbound schema tables it concatenates various options / variables into an executable string. However when adding a NULL value to a string the entire string becomes
    NULL which then gets executed.
    Whilst executing "EXEC(NULL)" would cause SQL to throw an error and be caught, executing the following doesnt
    DECLARE @null_string VARCHAR(100)
    SET @null_string = 'hello world ' + NULL
    EXEC(@null_string)
    SELECT @null_string
    So as it hasnt caused an error the next part of the procedure is to move to the next record and this is why its caught in an infinite loop
    DELETE @items WHERE ManagedTypeViewName = @View
    The value for the variable @View is the ManagedTypeViewName which is NULL, as ANSI_NULLS are set to ON in the connection and not overridded in the procedure then the above statement wont delete anything as it needs to handle NULL values differently (IS NULL),
    so we are now stuck in an infinite loop executing NULL for 2 hours until cancelled.
    I amended the stored procedure and added the following line before the loop statement which had the desired effect and "fixed" the performance issue for the time being
    DELETE @items WHERE ManagedTypeViewName IS NULL
    I also noticed that the following line in dbo.p_GetDwStagingGroomingConfig is commented out (no idea why as no notes in the procedure)
    --AND COALESCE(i.ManagedTypeViewName, j.RelationshipTypeViewName) IS NOT NULL
    There are obviously other ways to mitigate the dynamic SQL string being NULL, there's more than one way to skin a cat and thats not why I am asking this question, but what I am concerned about is that is there a reason that the xml / @GroomingCriteria is incomplete
    and / or that the procedures dont handle potential NULL values.
    I cant find any documentation, KBs, forum posts of anyone else having this issue which somewhat surprises me.
    Would be grateful of any help / advice that anyone can provide or if someone can look at their 2 stored procedures on a later version to see if it has already been fixed. Or is it simply that we have orphaned data, this is the bit that concerns most as I dont
    really want to be deleting / updating data when I have no idea what the knock on effect might be
    Many many thanks
    Andy

    First thing I would do is upgrade to 2012 R2 UR5. If you are running non-US dates you need the UR5 hotfix also.
    Rob Ford scsmnz.net
    Cireson www.cireson.com
    For a free SCSM 2012 Notify Analyst app click
    here

  • Mdnsresponder will not quit.  Consumes above 100% CPU and kills my battery.  Also causes my fan to run constantly and my computer to get extremely hot.  Force quitting doesn't work.  It just comes back.

    The mdnsresponder will not quit.  Consumes above 100% CPU and kills my battery.  Also causes my fan to run constantly and my computer to get extremely hot.  Force quitting doesn't work.  It just comes back.   I posted about this earlier and never got an answer.  Somebody, please help. 
    Thanks.

    mDNSResponder is a background process that runs all the time. If you kill it, it's relaunched automatically.
    Please launch the Console application and select "system.log" from the file list. Enter "mDNSResponder" (without the quotes) in the search field. Post a sample of the log messages in the Console window -- only one example of each repeated message, please.

  • HP2740p expansion battery problem - slow, 100% cpu

    Posting this problem because it took us months to figure out root cause.  When expansion battery for 2740p gets old and tablet tries to charge it the computer slows to a crawl - seriously slow and unworkable.  It's tough to troubleshoot the machine in this state.  CPU shows at or near 100% and task manager doesn't show processes consuming all the resources.  Mouse movement and clicks are slow - everything slow. 
    Occurs most often to people who have lot of meetings when they dock.  Seems to only happen when tablet is ON when it gets plugged in.  If tablet is OFF, then docked, and then turned ON problem doesn't occur.  We have dozens of this model and it's totally reproducable with different tablets and batteries.  Downloaded HP Battery Check app and it shows all batteries that cause this problem with status Replace.
    We run Win7 enterprise and downloaded all latest drivers on HP support.  Obvious fix is remove or replace expansion battery.
    Cheers,
    John

    Nevermind!
    Sorry for the trouble. The problem was that last time I compiled the code, it reverted back to and older version of a class I had compiled days ago. Why it did this is totally beyond me... but it did, and it just so happens that the old version of that class combined with the new version of my program were the perfect recipe for an infinite loop.
    Seriously, if you are in inveterate debugger, you might get a good laugh out of this. I've spent the last week and a half trying to find a way to set the Windows console into cbreak mode (single character processing rather than line-at-a-time processing), and I finally managed to do it by writing some c code and putting it into a DLL with the JNI. So now my program (which runs from the console) can process each character as it is entered rather than waiting for a line return. The older version of the class that got reverted was one that used System.in rather than the input stream generated by the socket. I had set it to System.in for testing purposes, and apparently that testing version is the one it got reverted back to. So combine the two, and you have a console that is feeding System.in each character as it is pressed and a socket wrapper that is listening infinitely. It was a mess... but an uncannily serindipitous mess...
    Ahh... debugging... good time...

  • Client process (uniengd) on the Calendar server is consuming 100% CPU usage

    The Calendar client bits in the Communicator 4.5 release (Calendar Build 981008)
    are suspect of hanging the Calendar server when the end user uses the off-line
    feature. The behavior seen will be that a cpu will start climbing and could
    reach 80-100% of usage, which will cause the response time for all other end
    users to be extremely slow and may not even accept any new logins.
    <P>
    The patch for these bits is available via the Smart Update (Windows and Mac) web
    site:
    <P>
    http://home.netscape.com/smartupdate/su1_40.html
    <P> Or you can download the complete version from
    http://home.netscape.com/download/selectplatform_1_361.html
    <P>
    For Unix platforms, you will need to download the compressed tar file
    (available from http://help/filelib.html#nscal)
    and reinstall it.
    <p>NOTE: To verify that you are executing a patched version, in the
    Calendar client:
    <b>Windows platform</b>
    <br>Help menu pulldown, About Netscape Calendar, make sure it has <b>Build
    981104</b> or higher.
    <br><b>Mac platform</b>
    <br>Select the file from your desktop
    <br>File menu pulldown, Get Info. Make sure has a <b>date of 121698, version
    4.51</b> or later.
    <br><b>Unix platform</b>
    <br>Help menu pulldown, About Netscape Calendar, make sure it has is <b>Version
    4.51</b> or higher
    <P>
    The procedure for determining which user of Calendar is causing the server's cpu
    hang is as follows:
    <OL>
    <LI>Using your favorite monitoring tool on the server, note the PID
         (process ID) of the uniengd process that is consuming
    80 - 100% cpu activity.
    <LI>Change directory to /users/unision/db/tmp/PID#
    <LI>Execute the command "strings" on all the files in the directory
         (there are usually not very many):
    <P>
              # strings *
    <P>
         Near the end of the output, you will see the user's name.
    <LI>You can now kill the uniengd process on the server:
    <P>
              # kill PID# (note: do not use the kill -9 unless absolutely
              necessary!)
    <P>
    <LI>Contact the name of the user whose process you looked up and determine
         what version of Calendar client they are using. Immediately inform
         them of your procedure on upgrading to the correct version.
    </OL>

    Hi TrondWH,
    Thanks for contacting Microsoft.
    Currently, would you please try cleaning boot the server and test how the issue goes. Cleaning boot can exclude some third-party application affect. Following are the detailed steps about clean boot:
    Log on to the computer by using an account that has administrator rights.
    Click Start, type msconfig.exe in the Start Search box, and then press ENTER to start the
         System Configuration Utility.
    On the General tab, click Selective Startup, and then click to clear the Load startup items check box. (The Use Original Boot.ini check box is unavailable.)
    On the Services tab, click to select the Hide all Microsoft services check box, and then click Disable all.
    Click OK, Choose Don’t show this message again and then click Restart.
    Please check if the issue is still the same.
    Please let me know the result.
    Best regards,
    Sophia Sun
    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

  • Opening VI and consuming 100% CPU power

    I am trying to debug my VI. The first few times the VI ran well but suddenly the VI hang up. I have no choice but to end the LabView process using the Task Manager. When I try to restart this VI again, it fails to open and the Task Manager indicates that the LabView program is now consuming 100% of the CPU time but still fail to open this VI. Looks like it is entering into an infinite loop. I cannot fix anything for I cannot go into my VI to change anything. LabView just consumes all the CPU power and do nothing. What went wrong?
    Regards,
    Larry

    Okay.  That is very strange.  I am seeing the same behavior.  (I have LV 8.2)
    When I first downloaded the VI, it opened just fine.  If I did a saveas, closed the VI, and reopened the copy, I got 99% CPU usage.  I reopened the one from the message, no problem.  I left that one open and tried opening the one I had saved.  It said I already had one in memory by that name do I want to view the one in memory or replace?  I said replace.  When it opened to the block diagram, everything was okay.  But when I clicked on the window to view the front panel, that is when the CPU usage jumped up again.
    So somehow the problem is associated with the FP.   Nothing looks particular wrong about your code.  The question is how did you manage to get a copy of the file that isn't causing problems when you open it?
    I think you will want to recreate the VI from scratch.  You are able to view a copy to see whay you have which is good.  And it doesn't look too complicated.
    What is interesting is that if I delete everything from the VI's block diagram (leaving nothing apparent on the FP), save, close, reopen, I still get the extreme CPU Usage.  It seems confined to LV, as I am still able to switch over and working within the browser to answer this message.
    Message Edited by Ravens Fan on 04-16-2007 02:30 PM

  • 100% CPU usage... does anyone else get this?

    Here is my code. I would have simplidied it for you... but I honestly have no idea where it went wrong.
    One second it is running fine, the next it starts taking up 100% of my CPU cycles. I can't figure out what I did to it to make it do this... nothing I added creates an infinite loop or infinite threads. It's just... weird.
    The code is probably too big for anyone to look at and tell me what's wrong, but can someone else download it and tell me if you also get 100% CPU usage? It needs to be run on Windows... it uses a couple JNI calls that are Windows-specific. Those calls were the first place I looked when trying to find the problem, but I have not changed that part of the code for a long time, and it has never been a problem before.
    Don't run the bat file... just navigate to the Watchdog2 directory and do 'java Watchdog'.
    Are there any tools that can help me figure out where the program is getting hung up? It's not freezing at any specific spot... just moving super slow and taking up 100% of my CPU. I'm so confused...
    Message was edited by:
    L4E_WakaMol-King

    Nevermind!
    Sorry for the trouble. The problem was that last time I compiled the code, it reverted back to and older version of a class I had compiled days ago. Why it did this is totally beyond me... but it did, and it just so happens that the old version of that class combined with the new version of my program were the perfect recipe for an infinite loop.
    Seriously, if you are in inveterate debugger, you might get a good laugh out of this. I've spent the last week and a half trying to find a way to set the Windows console into cbreak mode (single character processing rather than line-at-a-time processing), and I finally managed to do it by writing some c code and putting it into a DLL with the JNI. So now my program (which runs from the console) can process each character as it is entered rather than waiting for a line return. The older version of the class that got reverted was one that used System.in rather than the input stream generated by the socket. I had set it to System.in for testing purposes, and apparently that testing version is the one it got reverted back to. So combine the two, and you have a console that is feeding System.in each character as it is pressed and a socket wrapper that is listening infinitely. It was a mess... but an uncannily serindipitous mess...
    Ahh... debugging... good time...

  • Server 2012 R2 100% cpu usage when using search

    Hi all!
    We are experiencing issues with the built in search in WS 2012R2 (Win+Q). Upon starting to type, the explorer.exe process peaks and stays at 100% until typing is done and the search is complete. It also can't keep up with typing and hangs after
    a few keystrokes. We have done tests on 2012 R2, 2012 and 2008 R2 running as VMs with 1 cpu. The tests performed have been run on a host running only the test VM with underlying 2x8 core cpus, SSD, SAN storage and 256GB RAM. Also, we have tested
    both Hyper-V and VMware ESXi 5.0. We see that if we add another CPU to the guest it alleviates the keystroke lagging, but the explorer.exe still consumes 100% cpu.
    When the same tests are run on a physical machine (approx. same specs as the virtualization hosts) the cpu usage reaches 15-20% on one of the physical sockets (numa node). Totally negligible, but still a high number.
    We are afraid of service impact and are keen to know if anyone else is experiencing the same? Maybe someone has a fix?

    Hi TrondWH,
    Thanks for contacting Microsoft.
    Currently, would you please try cleaning boot the server and test how the issue goes. Cleaning boot can exclude some third-party application affect. Following are the detailed steps about clean boot:
    Log on to the computer by using an account that has administrator rights.
    Click Start, type msconfig.exe in the Start Search box, and then press ENTER to start the
         System Configuration Utility.
    On the General tab, click Selective Startup, and then click to clear the Load startup items check box. (The Use Original Boot.ini check box is unavailable.)
    On the Services tab, click to select the Hide all Microsoft services check box, and then click Disable all.
    Click OK, Choose Don’t show this message again and then click Restart.
    Please check if the issue is still the same.
    Please let me know the result.
    Best regards,
    Sophia Sun
    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

  • Elements 10 Playback uses 100% CPU 0% GPU

    When I play back a video clip in the Elements 10 environment the video is choppy and my system is using 100% CPU and 0% GPU.  When I play back the same files in Sony PMB the CPU runs at about 15% and the GPU runs at about 50%.
    Is there a way to get Elements 10 to use the GPU?
    System Specs:
    Windows Vista SP2
    AMD Athlon 64 X2 Dual Core 5600+ 2.8GHz
    3 GB RAM
    ATI Radeon HD 2600 XT
    Video Files are 1080i 5.1 m2ts.
    I am using the trail software now and will buy if I can get it working.
    Thanks!

    Certainly when rendering PRE uses as much of the processor capacity as possible (somewhere in these forums I posted a screen shot showing all my four cores at 100%).
    But in normal use I don't notice it hogging all processor power. I wonder if you have selected the right project setting for your video.
    What Sony camera are you using?
    What format did you record the video in?
    How did you get the clips onto your PC?
    What project setting did you use when you created your project?
    Do you see red lines across the top of the timeline when you first add your video to the timeline?
    As you edit your clips the timeline will show red lines - to perform a render press [Enter] and wait for the lines to go green.
    Are you using still images in the project? What pixel dimensions are they?
    You might find these articles helpful:
    PrE Hanging, or Crashing - Some Tips
    PrE Hanging, or Crashing - Some TipsClean, Lean & Mean Editing Machine - One Workflow
    Cheers,
    Neale
    Insanity is hereditary, you get it from your children

  • Lightroom is very slow, utilizes 100% CPU, then freezes or closes program.  How do I fix it?

    I am having a problem with Lightroom 5 being very slow, utilizing 100% CPU, then freezing or closing the program.  How do I fix it?
    I just upgraded to LR5 from LR3 on Sunday as well as CS6 from CS5 (which I have not tried out yet).  I spent several hours talking with Vamil, from LR Support Staff yesterday.  He was extremely helpful and kind and tried everything he could think of while remote-handling my PC and talking with me on the phone.  He deleted preferences, cache, temp files, updated graphics with a new replacement file from AMD site, then re-downloaded and reinstalled LR5. 
    It is still very slow and then freezes and closes down with a message of utilizing 100% CPU.  Within several seconds of using the brush in Develop, I started having lots of problems.  I could not even move the picture around.  The side screens would not disappear like they should.  And I could not move to another picture.  The day before I spent several hours trying to work on just 1 picture.  After all the changes yesterday, I tried to move from picture number 1 to about 130 after having not touched it for 10 minutes, and a half hour later, it still said, "Processing" with no picture coming up, just a blank prieview pane.
    LR Support suggested I get a new CPU though he thought according to specs mine should be ok and other programs were running fine.
    My PC is only 2 years old.
    I talked to HP briefly about CPU updates for my HP PC.  He said I probably do not have a problem but suggested I run self-diagnostics and maybe buy a new CPU anyway. 
    I ran diagnostics listed through the HP Support Assistant connection on my PC.  All was ok. 
    I still researched if I could buy a compatible CPU upgrade.  I cannot even find any CPUs still selling that are listed for my PC.  Best Buy Store said they could not even order a compatible CPU.  They said my Bus speed may not be big enough, so they suggest I get a new PC.  What Bus speed do I need?
    I have the following PC Setup:
         AMD Phenom II X6 1045T Processor 2.70 GHz with 6 Cores
              with 2700 MHz Base, 3200 MHz Boost, and 4000 System Bus Speed, and 95 watts;
         HP Pavilion Elite, HPE-500y, 900 GB Free, new in 2011;
         Windows 7, 64 Bit;
         RAM 16 GB, DDR3;
         Graphics AMD Radeon HD 6450;
         Nikon, D200, with Raw Files;
         External Hard Drive for Original Photos, 600 GB Free;
         LR Catalog and Library are on Main Hard Drive;
         Monitor, Sony CPD-200ES, new in 2004.
    I am thinking of buying a new monitor tonight mostly so I can do better photo work while enlarging the pictures to do it.  I am concerned that while it will help my viewing, it will take more power away, and make my usage of LR5 even worse.  Will a new monitor affect my performance?  I am looking at HP Monitors with IPS.  Is this the best recommended choice for LR and Photoshop CS6?
    I think I would like to stay with a 6 core processor since I need to have several items open for other non-Photoshop functions.  When running LR5, I had everything else closed.  With LR3, I was able to have other things open.
    I do not really want to buy a new computer and know that those I have talked with at this point are only guessing after looking for what they thought should fix it.  4 People from Lightroom Support have all thought I should not be having problems with my setup. 
    I bought one of the best computers 2 years ago.  Is it really obsolete already so that I cannot use LR5?  Is everyone else buying a new PC every 2 years?  I used to go 5-7 years. 
    Even though I have figured out some of what my PC has, I really do not know technically what I am talking about so am at the mercy of other's help.  Are there any solutions that might work short of buying a new computer?
    I also have taken 40th anniversary photos for some people and am waiting to give them as a free gift since I am not a professional at all.  I am hoping to get through this problem soon so that I can provide some nice memories for them.
    I have not gotten any further than trying to adjust 1 picture.  I have no comments on uploading speed, since I did that while still in LR3.
    Thank you for your time and help.

    I'm running LR with no speed issues on an Intel 17-860 quad core with about the same performance as your AMD Phenom II X6 1045T Processor. My system is also an HP, which originally had a single 1TB 7200 HDD. I've since added a second 2TB Black Caviar HDD, which provided no significant difference in LR's performance.
    AMD processors do not implement hyper-threading and don't need it. I'd start debug by process of elimination:
    1) Disconnect all externally attached USB, FireWire, or other externally connected devices except keyboard, mouse, and your single 1280 x1024 display. This includes all externally attached memory card readers, phones, ipads, etc.
    2) Reboot and logon as Administrator.
    3) Remove your Internet connection and turn off all Antivirus and firewall programs.
    4) Open LR and under Catalog Settings set 'Standard Preview Size' to 1440 (slightly larger than your display width). Under the Metadata tab here make sure 'Automatically Write changes into XMP is NOT checked.
    4) Create a 'New Catalog,' Create a new folder and add about 10 raw image file copies to it for testing, and Import it into the new catalog. In the Import module make sure under File Handling 'Render Previews' has 1:1 selected. Wait until all Preview building has completed in the Library module.
    Try editing these image files inside the new catalog as you were previously.

  • 100% CPU Usage Overhead running EM DBConsole 11g on OEL-5.2

    After upgrading to OEL-5.2 and relinking all Oracle binaries, my old Oracle 11g installation, installed several months before on OEL-5.1, has been working well, including Enterprise Manager Database Console working nicely as always with respectful performance. Unfortunatelly, it lasted just several days.
    Yesterday I decided to uninstall the 11g completely and perform new clean installation (software and database) with the same configuration options and settings as before, including EM dbconsole, all configured using dbca. After completing the installation (EM was started automatically by dbca), oracle continued to suck 80-85% CPU time. In further few minutes CPU utilization raised up to 99% due to only one (always the same PID) client process - "oracleorcl (LOCAL=NO)". For first ten minutes I didn't care too much since I always enable Automatic Management in dbca. But after two hours, I started to worry. The process was still running, consuming sustained 99% of CPU power. No other system activity, no database activity, no disks activity at all!
    I was really puzzled since I installed and reinstalled the 11g at least 20 times on OEL-5.0 and 5.1, experimenting with ASM, raw devices, loopback devices and various combinations of installation options, but never experienced such a behaviour. It took me 3 minutes to log in to EM dbconsole as it was almost unusable performing too slow. After three hours CPU temperature was nearly 60 degrees celsius. I decided to shutdown EM and after that everything became quiet. Oracle was running normally. Started EM again, the problem was back again. Tracing enabled, it filled a 350 MB trace file in just 20 minutes. Reinstalling the software and database once again didn't help. Whenever EM is up, the CPU usage overhead of 99% persists.
    Here is a cca 23 minutes session summary report taken from EM dbconsole's Performance page. The trace file is too big to list it here, but it shows the same.
            Host CPU:  100%
    Active Sessions:  100%The details for the Selected 5 Minute Interval (the last 5 min interval) are shown as follow:
        TOP SESSIONS:  SYSMAN, Program: OMS
            Activity:  100%  
         TOP MODULES:  OEM.CacheModeWaitPool, Service: orcl
            Activity:  100%          
          TOP CLIENT:  Unnamed
            Activity:  99.1%
         TOP ACTIONS:  Unnamed (OEM.CacheModeWaitPool) (orcl)
            Activity:  100%
         TOP OBJECTS: SYSMAN.MGMT_JOB_EXEC_SUMMARY (Table)
            Activity:  100%
          TOP PL/SQL:  SYSMAN.MGMT_JOB_ENGINE.INSERT_EXECUTION
       PL/SQL Source:  SYSMAN.MGMT_JOB_ENGINE
         Line Number:  7135
            Activity:  100%
             TOP SQL:  SELECT EXECUTION_ID, STATUS, STATUS_DETAIL FROM MGMT_JOB_EXEC_SUMMARY
    WHERE JOB_ID = :B3 AND TARGET_LIST_INDEX = :B2 AND EXPECTED_START_TIME = :B1;
            Activity:  100%
                                  STATISTICS SUMMARY
                                cca 23 minutes session
                            with no other system activity
                                            Per 
                           Total      Execution         Per Row
    Executions           105,103                 1       10,510.30
    Elapsed Time (sec)  1,358.95              0.01        135.90
    CPU Time (sec)      1,070.42             0.01        107.04
    Buffer Gets       85,585,518 814.30 8,558,551.80
    Disk Reads                 2            <0.01          0.20
    Direct Writes              0              0.00          0.00
    Rows                      10            <0.01             1
    Fetches              105,103             1.00     10,510.30
                       ----------------------------------------Wow!!! Note: no disk, no database activity !
    Has anyone experienced this or similar behaviour after clean 11g installation on OEL-5.2? If not, anyone has a clue what the hell is going on?
    Thanks in advance.

    Hi Tommy,
    I didn't want to experiment further with already working OEL-5.2, oracle and dbconsole on this machine, specially not after googling the problem and finding out that I am not alone in this world. There are another two threads on OTN forums (Database General) showing the same problem even on 2GB machines:
    DBConsole easting a CPU
    11g stuck. 50-100% CPU after fresh install
    So, I took another, a smaller free machine I've got at home (1GB RAM, 2.2MHz Pentium4, three 80GB disks), on which I used to experiment with new releases of software (this is the machine on which I installed 11g for the first time when it was released on OEL-5.0, and I can recall that everything was OK with EM). This is what I did:
    1. I installed OEL-5.0 on the machine, adjusted linux and kernel parameters, and performed full 11g installation. Database and EM dbconsole worked nice with acceptable performance. Without activity in the database, %CPU = zero !!! The whole system was perfectly quiet.
    2. Since everything was OK, I shutdown EM and oracle, and performed the full upgrade to OEL-5.2. When the upgrade finished, restarted the system, relinked all oracle binaries, and started oracle and EM dbconsole. Both worked perfectly again, just as before the upgrade. I repeated restarting the database and dbconsole several times, always with the same result - it really rocks. Without database activity, %CPU = zero%.
    3. Using dbca, I dropped the database and created the new one with the same configuration options. Wow! I'm again in trouble. A half an hour after the creation of the database, %CPU raised up to 99%. That's it.
    The crucial question here is: what is that in OEL-5.2, not existing in the 5.0, that causes dbca/em scripts to be embarrassed at the time of EM agent configuration?
    Here are the outputs you required picked 30 minutes after starting the database and EM dbconsole (sustained 99% CPU utilization). Note that this is just a 1GB machine.
    Kernel command line: ro root=LABEL=/ elevator=deadline rhgb quiet
    [root@localhost ~]# cat /proc/meminfo
    MemTotal:      1034576 kB
    MemFree:         27356 kB
    Buffers:          8388 kB
    Cached:         609660 kB
    SwapCached:      18628 kB
    Active:         675376 kB
    Inactive:       287072 kB
    HighTotal:      130304 kB
    HighFree:          260 kB
    LowTotal:       904272 kB
    LowFree:         27096 kB
    SwapTotal:     3148700 kB
    SwapFree:      2940636 kB
    Dirty:              72 kB
    Writeback:           0 kB
    AnonPages:      328700 kB
    Mapped:         271316 kB
    Slab:            21136 kB
    PageTables:      14196 kB
    NFS_Unstable:        0 kB
    Bounce:              0 kB
    CommitLimit:   3665988 kB
    Committed_AS:  1187464 kB
    VmallocTotal:   114680 kB
    VmallocUsed:      5860 kB
    VmallocChunk:   108476 kB
    HugePages_Total:     0
    HugePages_Free:      0
    HugePages_Rsvd:      0
    Hugepagesize:     4096 kB
    [root@localhost ~]# cat /proc/slabinfo
    slabinfo - version: 2.1
    # name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
    rpc_buffers            8      8   2048    2    1 : tunables   24   12    8 : slabdata      4      4      0
    rpc_tasks              8     15    256   15    1 : tunables  120   60    8 : slabdata      1      1      0
    rpc_inode_cache        6      7    512    7    1 : tunables   54   27    8 : slabdata      1      1      0
    ip_conntrack_expect    0      0     96   40    1 : tunables  120   60    8 : slabdata      0      0      0
    ip_conntrack          68     68    228   17    1 : tunables  120   60    8 : slabdata      4      4      0
    ip_fib_alias           7    113     32  113    1 : tunables  120   60    8 : slabdata      1      1      0
    ip_fib_hash            7    113     32  113    1 : tunables  120   60    8 : slabdata      1      1      0
    fib6_nodes            22    113     32  113    1 : tunables  120   60    8 : slabdata      1      1      0
    ip6_dst_cache         13     15    256   15    1 : tunables  120   60    8 : slabdata      1      1      0
    ndisc_cache            1     15    256   15    1 : tunables  120   60    8 : slabdata      1      1      0
    RAWv6                  4      5    768    5    1 : tunables   54   27    8 : slabdata      1      1      0
    UDPv6                  9     12    640    6    1 : tunables   54   27    8 : slabdata      2      2      0
    tw_sock_TCPv6          0      0    128   30    1 : tunables  120   60    8 : slabdata      0      0      0
    request_sock_TCPv6     0      0    128   30    1 : tunables  120   60    8 : slabdata      0      0      0
    TCPv6                  1      3   1280    3    1 : tunables   24   12    8 : slabdata      1      1      0
    jbd_1k                 0      0   1024    4    1 : tunables   54   27    8 : slabdata      0      0      0
    dm_mpath               0      0     28  127    1 : tunables  120   60    8 : slabdata      0      0      0
    dm_uevent              0      0   2460    3    2 : tunables   24   12    8 : slabdata      0      0      0
    dm_tio                 0      0     16  203    1 : tunables  120   60    8 : slabdata      0      0      0
    dm_io                  0      0     20  169    1 : tunables  120   60    8 : slabdata      0      0      0
    jbd_4k                 1      1   4096    1    1 : tunables   24   12    8 : slabdata      1      1      0
    scsi_cmd_cache        10     10    384   10    1 : tunables   54   27    8 : slabdata      1      1      0
    sgpool-128            36     36   2048    2    1 : tunables   24   12    8 : slabdata     18     18      0
    sgpool-64             33     36   1024    4    1 : tunables   54   27    8 : slabdata      9      9      0
    sgpool-32             34     40    512    8    1 : tunables   54   27    8 : slabdata      5      5      0
    sgpool-16             35     45    256   15    1 : tunables  120   60    8 : slabdata      3      3      0
    sgpool-8              60     60    128   30    1 : tunables  120   60    8 : slabdata      2      2      0
    scsi_io_context        0      0    104   37    1 : tunables  120   60    8 : slabdata      0      0      0
    ext3_inode_cache    4376   8216    492    8    1 : tunables   54   27    8 : slabdata   1027   1027      0
    ext3_xattr           165    234     48   78    1 : tunables  120   60    8 : slabdata      3      3      0
    journal_handle         8    169     20  169    1 : tunables  120   60    8 : slabdata      1      1      0
    journal_head         684   1008     52   72    1 : tunables  120   60    8 : slabdata     14     14      0
    revoke_table          18    254     12  254    1 : tunables  120   60    8 : slabdata      1      1      0
    revoke_record          0      0     16  203    1 : tunables  120   60    8 : slabdata      0      0      0
    uhci_urb_priv          0      0     28  127    1 : tunables  120   60    8 : slabdata      0      0      0
    UNIX                  56    112    512    7    1 : tunables   54   27    8 : slabdata     16     16      0
    flow_cache             0      0    128   30    1 : tunables  120   60    8 : slabdata      0      0      0
    cfq_ioc_pool           0      0     92   42    1 : tunables  120   60    8 : slabdata      0      0      0
    cfq_pool               0      0     96   40    1 : tunables  120   60    8 : slabdata      0      0      0
    crq_pool               0      0     44   84    1 : tunables  120   60    8 : slabdata      0      0      0
    deadline_drq         140    252     44   84    1 : tunables  120   60    8 : slabdata      3      3      0
    as_arq                 0      0     56   67    1 : tunables  120   60    8 : slabdata      0      0      0
    mqueue_inode_cache     1      6    640    6    1 : tunables   54   27    8 : slabdata      1      1      0
    isofs_inode_cache      0      0    368   10    1 : tunables   54   27    8 : slabdata      0      0      0
    hugetlbfs_inode_cache  1     11    340   11    1 : tunables   54   27    8 : slabdata      1      1      0
    ext2_inode_cache       0      0    476    8    1 : tunables   54   27    8 : slabdata      0      0      0
    ext2_xattr             0      0     48   78    1 : tunables  120   60    8 : slabdata      0      0      0
    dnotify_cache          2    169     20  169    1 : tunables  120   60    8 : slabdata      1      1      0
    dquot                  0      0    128   30    1 : tunables  120   60    8 : slabdata      0      0      0
    eventpoll_pwq          1    101     36  101    1 : tunables  120   60    8 : slabdata      1      1      0
    eventpoll_epi          1     30    128   30    1 : tunables  120   60    8 : slabdata      1      1      0
    inotify_event_cache    1    127     28  127    1 : tunables  120   60    8 : slabdata      1      1      0
    inotify_watch_cache   23     92     40   92    1 : tunables  120   60    8 : slabdata      1      1      0
    kioctx               135    135    256   15    1 : tunables  120   60    8 : slabdata      9      9      0
    kiocb                  0      0    128   30    1 : tunables  120   60    8 : slabdata      0      0      0
    fasync_cache           0      0     16  203    1 : tunables  120   60    8 : slabdata      0      0      0
    shmem_inode_cache    553    585    436    9    1 : tunables   54   27    8 : slabdata     65     65      0
    posix_timers_cache     0      0     88   44    1 : tunables  120   60    8 : slabdata      0      0      0
    uid_cache              5     59     64   59    1 : tunables  120   60    8 : slabdata      1      1      0
    ip_mrt_cache           0      0    128   30    1 : tunables  120   60    8 : slabdata      0      0      0
    tcp_bind_bucket       32    203     16  203    1 : tunables  120   60    8 : slabdata      1      1      0
    inet_peer_cache        1     59     64   59    1 : tunables  120   60    8 : slabdata      1      1      0
    secpath_cache          0      0     32  113    1 : tunables  120   60    8 : slabdata      0      0      0
    xfrm_dst_cache         0      0    384   10    1 : tunables   54   27    8 : slabdata      0      0      0
    ip_dst_cache           6     15    256   15    1 : tunables  120   60    8 : slabdata      1      1      0
    arp_cache              2     15    256   15    1 : tunables  120   60    8 : slabdata      1      1      0
    RAW                    2      7    512    7    1 : tunables   54   27    8 : slabdata      1      1      0
    UDP                    3      7    512    7    1 : tunables   54   27    8 : slabdata      1      1      0
    tw_sock_TCP            3     30    128   30    1 : tunables  120   60    8 : slabdata      1      1      0
    request_sock_TCP       4     30    128   30    1 : tunables  120   60    8 : slabdata      1      1      0
    TCP                   43     49   1152    7    2 : tunables   24   12    8 : slabdata      7      7      0
    blkdev_ioc             3    127     28  127    1 : tunables  120   60    8 : slabdata      1      1      0
    blkdev_queue          23     24    956    4    1 : tunables   54   27    8 : slabdata      6      6      0
    blkdev_requests      137    161    172   23    1 : tunables  120   60    8 : slabdata      7      7      0
    biovec-256             7      8   3072    2    2 : tunables   24   12    8 : slabdata      4      4      0
    biovec-128             7     10   1536    5    2 : tunables   24   12    8 : slabdata      2      2      0
    biovec-64              7     10    768    5    1 : tunables   54   27    8 : slabdata      2      2      0
    biovec-16              7     15    256   15    1 : tunables  120   60    8 : slabdata      1      1      0
    biovec-4               8     59     64   59    1 : tunables  120   60    8 : slabdata      1      1      0
    biovec-1             406    406     16  203    1 : tunables  120   60    8 : slabdata      2      2    300
    bio                  564    660    128   30    1 : tunables  120   60    8 : slabdata     21     22    204
    utrace_engine_cache    0      0     32  113    1 : tunables  120   60    8 : slabdata      0      0      0
    utrace_cache           0      0     32  113    1 : tunables  120   60    8 : slabdata      0      0      0
    sock_inode_cache     149    230    384   10    1 : tunables   54   27    8 : slabdata     23     23      0
    skbuff_fclone_cache   20     20    384   10    1 : tunables   54   27    8 : slabdata      2      2      0
    skbuff_head_cache     86    210    256   15    1 : tunables  120   60    8 : slabdata     14     14      0
    file_lock_cache       22     40     96   40    1 : tunables  120   60    8 : slabdata      1      1      0
    Acpi-Operand        1147   1196     40   92    1 : tunables  120   60    8 : slabdata     13     13      0
    Acpi-ParseExt          0      0     44   84    1 : tunables  120   60    8 : slabdata      0      0      0
    Acpi-Parse             0      0     28  127    1 : tunables  120   60    8 : slabdata      0      0      0
    Acpi-State             0      0     44   84    1 : tunables  120   60    8 : slabdata      0      0      0
    Acpi-Namespace       615    676     20  169    1 : tunables  120   60    8 : slabdata      4      4      0
    delayacct_cache      233    312     48   78    1 : tunables  120   60    8 : slabdata      4      4      0
    taskstats_cache       12     53     72   53    1 : tunables  120   60    8 : slabdata      1      1      0
    proc_inode_cache     622    693    356   11    1 : tunables   54   27    8 : slabdata     63     63      0
    sigqueue               8     27    144   27    1 : tunables  120   60    8 : slabdata      1      1      0
    radix_tree_node     6220   8134    276   14    1 : tunables   54   27    8 : slabdata    581    581      0
    bdev_cache            37     42    512    7    1 : tunables   54   27    8 : slabdata      6      6      0
    sysfs_dir_cache     4980   4992     48   78    1 : tunables  120   60    8 : slabdata     64     64      0
    mnt_cache             36     60    128   30    1 : tunables  120   60    8 : slabdata      2      2      0
    inode_cache         1113   1254    340   11    1 : tunables   54   27    8 : slabdata    114    114     81
    dentry_cache       11442  18560    136   29    1 : tunables  120   60    8 : slabdata    640    640    180
    filp                7607  10000    192   20    1 : tunables  120   60    8 : slabdata    500    500    120
    names_cache           19     19   4096    1    1 : tunables   24   12    8 : slabdata     19     19      0
    avc_node              14     72     52   72    1 : tunables  120   60    8 : slabdata      1      1      0
    selinux_inode_security 814   1170     48   78    1 : tunables  120   60    8 : slabdata     15     15      0
    key_jar               14     30    128   30    1 : tunables  120   60    8 : slabdata      1      1      0
    idr_layer_cache      170    203    136   29    1 : tunables  120   60    8 : slabdata      7      7      0
    buffer_head        38892  39024     52   72    1 : tunables  120   60    8 : slabdata    542    542      0
    mm_struct            108    135    448    9    1 : tunables   54   27    8 : slabdata     15     15      0
    vm_area_struct     11169  14904     84   46    1 : tunables  120   60    8 : slabdata    324    324    144
    fs_cache              82    177     64   59    1 : tunables  120   60    8 : slabdata      3      3      0
    files_cache          108    140    384   10    1 : tunables   54   27    8 : slabdata     14     14      0
    signal_cache         142    171    448    9    1 : tunables   54   27    8 : slabdata     19     19      0
    sighand_cache        127    135   1344    3    1 : tunables   24   12    8 : slabdata     45     45      0
    task_struct          184    246   1360    3    1 : tunables   24   12    8 : slabdata     82     82      0
    anon_vma            3313   5842     12  254    1 : tunables  120   60    8 : slabdata     23     23      0
    pgd                   84     84   4096    1    1 : tunables   24   12    8 : slabdata     84     84      0
    pid                  237    303     36  101    1 : tunables  120   60    8 : slabdata      3      3      0
    size-131072(DMA)       0      0 131072    1   32 : tunables    8    4    0 : slabdata      0      0      0
    size-131072            0      0 131072    1   32 : tunables    8    4    0 : slabdata      0      0      0
    size-65536(DMA)        0      0  65536    1   16 : tunables    8    4    0 : slabdata      0      0      0
    size-65536             2      2  65536    1   16 : tunables    8    4    0 : slabdata      2      2      0
    size-32768(DMA)        0      0  32768    1    8 : tunables    8    4    0 : slabdata      0      0      0
    size-32768             9      9  32768    1    8 : tunables    8    4    0 : slabdata      9      9      0
    size-16384(DMA)        0      0  16384    1    4 : tunables    8    4    0 : slabdata      0      0      0
    size-16384             6      6  16384    1    4 : tunables    8    4    0 : slabdata      6      6      0
    size-8192(DMA)         0      0   8192    1    2 : tunables    8    4    0 : slabdata      0      0      0
    size-8192              5      5   8192    1    2 : tunables    8    4    0 : slabdata      5      5      0
    size-4096(DMA)         0      0   4096    1    1 : tunables   24   12    8 : slabdata      0      0      0
    size-4096            205    205   4096    1    1 : tunables   24   12    8 : slabdata    205    205      0
    size-2048(DMA)         0      0   2048    2    1 : tunables   24   12    8 : slabdata      0      0      0
    size-2048            260    270   2048    2    1 : tunables   24   12    8 : slabdata    135    135      0
    size-1024(DMA)         0      0   1024    4    1 : tunables   54   27    8 : slabdata      0      0      0
    size-1024            204    204   1024    4    1 : tunables   54   27    8 : slabdata     51     51      0
    size-512(DMA)          0      0    512    8    1 : tunables   54   27    8 : slabdata      0      0      0
    size-512             367    464    512    8    1 : tunables   54   27    8 : slabdata     58     58      0
    size-256(DMA)          0      0    256   15    1 : tunables  120   60    8 : slabdata      0      0      0
    size-256             487    495    256   15    1 : tunables  120   60    8 : slabdata     33     33      0
    size-128(DMA)          0      0    128   30    1 : tunables  120   60    8 : slabdata      0      0      0
    size-128            2242   2490    128   30    1 : tunables  120   60    8 : slabdata     83     83      0
    size-64(DMA)           0      0     64   59    1 : tunables  120   60    8 : slabdata      0      0      0
    size-32(DMA)           0      0     32  113    1 : tunables  120   60    8 : slabdata      0      0      0
    size-64             1409   2950     64   59    1 : tunables  120   60    8 : slabdata     50     50      0
    size-32             3596   3842     32  113    1 : tunables  120   60    8 : slabdata     34     34      0
    kmem_cache           145    150    256   15    1 : tunables  120   60    8 : slabdata     10     10      0
    [root@localhost ~]# slabtop -d 5
    Active / Total Objects (% used)    : 97257 / 113249 (85.9%)
    Active / Total Slabs (% used)      : 4488 / 4488 (100.0%)
    Active / Total Caches (% used)     : 101 / 146 (69.2%)
    Active / Total Size (% used)       : 15076.34K / 17587.55K (85.7%)
    Minimum / Average / Maximum Object : 0.01K / 0.16K / 128.00K
      OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
    25776  25764  99%    0.05K    358       72      1432K buffer_head
    16146  15351  95%    0.08K    351       46      1404K vm_area_struct
    15138   7779  51%    0.13K    522       29      2088K dentry_cache
      9720   9106  93%    0.19K    486       20      1944K filp
      7714   7032  91%    0.27K    551       14      2204K radix_tree_node
      5070   5018  98%    0.05K     65       78       260K sysfs_dir_cache
      4826   4766  98%    0.01K     19      254        76K anon_vma
      4824   3406  70%    0.48K    603        8      2412K ext3_inode_cache
      3842   3691  96%    0.03K     34      113       136K size-32
      2190   2174  99%    0.12K     73       30       292K size-128
      1711   1364  79%    0.06K     29       59       116K size-64
      1210   1053  87%    0.33K    110       11       440K inode_cache
      1196   1147  95%    0.04K     13       92        52K Acpi-Operand
      1170    814  69%    0.05K     15       78        60K selinux_inode_security
       936    414  44%    0.05K     13       72        52K journal_head
       747    738  98%    0.43K     83        9       332K shmem_inode_cache
       693    617  89%    0.35K     63       11       252K proc_inode_cache
       676    615  90%    0.02K      4      169        16K Acpi-Namespace
       609    136  22%    0.02K      3      203        12K biovec-1
       495    493  99%    0.25K     33       15       132K size-256
       480    384  80%    0.12K     16       30        64K bio
       440    399  90%    0.50K     55        8       220K size-512
       312    206  66%    0.05K      4       78        16K delayacct_cache
       303    209  68%    0.04K      3      101        12K pid
       290    290 100%    0.38K     29       10       116K sock_inode_cache
    [root@localhost ~]# cat /etc/sysctl.conf
    # Kernel sysctl configuration file for Red Hat Linux
    # Controls IP packet forwarding
    net.ipv4.ip_forward=0
    # Controls source route verification
    net.ipv4.conf.default.rp_filter=1
    # Do not accept source routing
    net.ipv4.conf.default.accept_source_route=0
    # Oracle
    net.ipv4.ip_local_port_range=1024 65000
    net.core.rmem_default=4194304
    net.core.rmem_max=4194304
    net.core.wmem_default=262144
    net.core.wmem_max=262144
    net.ipv4.tcp_rmem=4096 65536 4194304
    net.ipv4.tcp_wmem=4096 65536 4194304
    # Keepalive Oracle
    net.ipv4.tcp_keepalive_time=3000
    net.ipv4.tcp_keepalive_intvl=30
    net.ipv4.tcp_keepalive_probes=15
    net.ipv4.tcp_retries2=3
    net.ipv4.tcp_syn_retries=2
    net.ipv4.tcp_sack=0
    net.ipv4.tcp_timestamps=0
    net.ipv4.tcp_window_scaling=0
    # Oracle
    fs.file-max = 6553600
    fs.aio-max-nr=3145728
    kernel.shmmni=4096
    kernel.sem=250 32000 100 142
    kernel.shmmax=2147483648
    kernel.shmall=3279547
    kernel.msgmnb=65536
    kernel.msgmni=2878
    kernel.msgmax=8192
    kernel.exec-shield=0
    # Controls the System Request debugging functionality of the kernel
    kernel.sysrq=1
    kernel.panic=60
    kernel.core_uses_pid=1
    [root@localhost ~]# free | grep Swap
    Swap:      3148700     319916    2828784
    [root@localhost ~]# cat /etc/fstab | grep "/dev/shm"
    tmpfs                   /dev/shm                tmpfs   size=1024M      0 0
    [root@localhost ~]# df | grep "/dev/shm"
    tmpfs                  1048576    452128    596448  44% /dev/shm
    NON-DEFAULT DB PARAMETERS:
    db_block_size        8192
    memory_target          633339904  /* automatic memory management */
    open_cursors         300
    processes            256
    disk_async_io        TRUE
    filesystemio_options SETALL

  • [Solved (partially)] 100% CPU for Reader

    Here is a detailed description why Reader ends up using 100% CPU (output taken from strace, unimportant lines removed):
    socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 12
    connect(12, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.150.8.100")}, 16) = -1 EINPROGRESS (Operation now in progress)
    poll([{fd=3, events=POLLIN}, {fd=12, events=POLLOUT}], 2, 0) = 0 (Timeout)
    poll([{fd=3, events=POLLIN}, {fd=12, events=POLLOUT}], 2, 15) = 0 (Timeout)
    until here, everything is fine. Reader polls for events on the socket descriptors with a timeout of 15ms.
    I our case, Reader is running on a Kiosk system, so connection to most hosts are forbidden, including pmupsw.adobe.com ("192.150.8.100"). So after some time the connection fails.
    poll([{fd=3, events=POLLIN}, {fd=12, events=POLLOUT}], 2, 13) = 1 ([{fd=12, revents=POLLERR|POLLHUP}])
    Unfortunately, now the poll() returns immediately. Reader does not handle the POLLERR, so it ends up polling the socket in a tight loop.

    Running Ubuntu 10.04 LTS on HP6715 notebook. I had the 100% cpu utilization issue. I changed the adobe proxy setting from direct connect to manual. I entered the proxy settings at my company. This fixed the issue. It would be nice if adobe could use the system proxy settings.
    This issue was documented here
    http://blogs.adobe.com/acroread/2008/04/100_cpu_utilization_problem.html

Maybe you are looking for