100% CPU utilized (found due to (LOCAL=NO) )

Hi Friends,
OS: SunOS 5.10
I got an alert like CUP is utilizied 100% and oracle consumed 82%
At 7:00 AM
NPROC USERNAME SWAP RSS MEMORY TIME CPU
190 oracle 25G 24G 38% 234:35:05 82%
When I check at 7:30AM
NPROC USERNAME SWAP RSS MEMORY TIME CPU
161 oracle 22G 22G 35% 230:40:43 13%
How to check what happened at 7:00AM.
OS logs gives some idea?
Suggestions appreciated.
Thanks
KSG
Edited by: KSG on Aug 17, 2012 11:33 AM

The following are the process followed ..
To find the CPU consumption
prstat -s cpu -a -n 8
To find the list of process running on the server
ps -eo pcpu,pid,user,args | sort -k 1 -r | head -40
To get the SID from PID
select sid,serial#
from v$session
where paddr in (select addr from v$process
where background is null
and spid=&Server_process_id)
To get query from SID
select sql.sql_text
from v$session ses, v$sqltext sql
where sql.address=ses.sql_address
and sql.hash_value=ses.sql_hash_value
and sid=&session_id
order by piece
To find the connectivity details
select SID,Serial#,status ,program,module,terminal,to_char(LOGON_TIME,'dd-mm-yyyy hh24:mi:ss') from v$session where sid=62;
Check the connectivity accordingly and analyze.
Now to experts,
How to restrict the number of incoming connectivity so that we can always stay under the CPU threshold?
Any idea?
Regards
KSG
Edited by: KSG on Aug 17, 2012 11:30 AM

Similar Messages

  • ProcessManager service (opmn.exe -s) results 100% CPU util.

    I've just installed Oracle 10g Release 10.2.0.1.0 on Windows 2003 Server w/ SP1.
    However, I proceeded to install the Oracle HTMLDB & HTTP Server into a separate Oracle home director. The install completes successfully and I'm able to access Oracle's 10g HTMLDB from http://localhost:7777/pls/htmldb/htmldb. The server is running fine, but I took notice on the "performance" which indicates the CPU is running at 100% utilization.
    I found that if I turn the OracleOraDb10g_ProcessManager (opmn.exe -s) service off, the CPU reduces itself down to 0%. Although, I don't notice a performance hit on the server when the service is turned on. Is there a patch that can be applied? Any thoughts on this?
    Windows 2003 Server SP1
    AMD Athlon 1800+ , ~1.5Ghz
    640MB RAM

    After a bit of research, I found that someone had tried editing the "opmn.xml" configuration and changing the port to 6102. Everything worked after I restarted the process from the command line using "opmnctl startall", "opmnctl reload".

  • Egather2.exe 100% CPU Util

    For quite a long time now, every Sunday morning, my CPU is pegged at 100% with egather2.exe being the culpret. A few months ago, there was an update which seemed that it was supposed to fix the problem... but it has not. Any ideas?
    Do I need to remove the entire R&R software to get rid of this issue? 
    I end up needing to kill both the egather2 and the process which starts it (I can't recall the name) and then rebooting, every Sunday morning.
    Thanks

    After a bit of research, I found that someone had tried editing the "opmn.xml" configuration and changing the port to 6102. Everything worked after I restarted the process from the command line using "opmnctl startall", "opmnctl reload".

  • CPU utilizing 100% memory after cloning

    Hi,
    I did cloning two days before.After that the server utilizing 100% CPU.So that unable to do any work on that instance.Can any one please suggest what is the root cause of the problem ?
    oracle ebs 12.1.3
    database 11.2.0.2
    RHEL 5.8
    Thanks

    Sivamani wrote:
    Hi,
    I did cloning two days before.After that the server utilizing 100% CPU.So that unable to do any work on that instance.Can any one please suggest what is the root cause of the problem ?
    oracle ebs 12.1.3
    database 11.2.0.2
    RHEL 5.8
    ThanksStop the CM only and see if you notice any improvement in the performance.
    Also, please see https://forums.oracle.com/forums/search.jspa?threadID=&q=CPU+AND+High&objID=c3&dateRange=all&userID=&numResults=15&rankBy=10001
    Thanks,
    Hussein

  • 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

  • ESSSVR.exe utilizing 100% CPU

    Hello Everyone
    I have just finished a fresh install of Essbase 11, migrated a few applications over, and for a time everything works as it should.
    But leave the server running for a couple of days (with very little usage) and the essbase service utilizes 100% cpu, making the essbase unusable. The event reoccurs after service & server reboot
    I'm fairly new to the Essbase world :) any help would be appreciated
    Thanks
    Essbase 11.1.1
    Windows Server 2003 SP2, 4way CPU 4GB ram

    Have you looked at the Essbase.log and application logs?
    Tried to see which application (a given app will be tied to a ESSSVR.EXE process, but the only way to know is to see what databases are actively loaded -- it is a pain) is running? Any automated actions that may cause it to fire off? Again, the application log will be your guide.
    Or is it ESSBASE.EXE that's logging 100% of the CPU? It can't be CPUs as even in 11x the Essbase agent is still single threaded (I believe that to still be true).
    I'll throw out that there may be some antivirus/backup software out there conflicting with Essbase, but the behavior you describe isn't typical -- usually it's a database that can't stop/unload/calculate/etc because .PAG/.IND in BSO and .DAT files in ASO are locked -- but I suppose it's still a possibility.
    Obviously something is making Essbase throw restraint to the wind -- the logs can help you.
    Regards,
    Cameron Lackpour

  • 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

  • CF9 CPU at 100%. Moved to new CF11 server and copied files over and it's still at 100% CPU almost immediately on new server

    Our web server is stuck at 100% CPU.  Three days ago we were on CF9 and started running into this problem until the server crashed and wasn't salvageable.  Luckily we had a fresh Windows 2008 Server R2 ready to go with a fresh copy of CF11 on it.  I copied all the website files over and we were back up and running.  A day later the CPU is back to 100% on the new CF11 Windows 2008R2 server.  I also updated CF11 to the latest update 3 that was just released.
    If I turn off the CF service the CPU usage goes back to normal.  If I turn CF back on, the CPU goes back to 100% within like 5 seconds.  So it doesn't seem like some slow running page or anything that eventually eats up all the memory or whatever.  I'm not an expert at looking at the logs, but I don't see anything too out of the ordinary.  The one thing that looks strange to me is I see this line over and over.
    Dec 12, 2014 11:28:41 AM Information [ajp-bio-8014-exec-59] - Starting HTTP request {URL='http://zzen1wbudopwg.nchyt.com/encfm/en0024-ssj5iway6wvg/cbeim94a1s2kebu.php?do=194', method='get'}
    That line makes me think we got hacked somehow, but it's hard to know.
    I did up my JVM heap size and max size to 1024MB.  We have 4GB of memory.  And i changed teh JVM arguments to what's below based on a forum post.  Nothing seems to help.
    -server -XX:PermSize=192m -XX:MaxPermSize=192m -XX:+UseParallelGC -Xbatch -Dcoldfusion.home={application.home} -Dorg.eclipse.jetty.util.log.class=org.eclipse.jetty.util.log.JavaUtilLog -Duser.language=en -Dcoldfusion.rootDir={application.home} -Dcoldfusion.libPath={application.home}/lib -Dorg.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER=true -Dcoldfusion.jsafe.defaultalgo=FIPS186Random
    Any additional ideas on how to debug this or what to look at?  Thanks!

    Thanks Charlie for your insight.  I searched everywhere to find a cfhttp request that was causing the issue, but couldn't find it.  I did find some unusual files that were loaded though that I know we didn't put there.  I did a search and found this link that shows the code.  Coldfusion CFIDE bitcoin mining exploit – PHP involved… | code-complete.com and that you mention in your article too.  I don't see any of the executables running or files that were mentioned though.  I found that code in 8 different spots though and removed them.  Maybe our old server had the executables and hacked files on them.  Hard to know as it won't boot up anymore!
    I think I did possibly isolate the HTTP request {URL='http://zzen1wbudopwg.nchyt.com/encfm/en0024-ssj5iway6wvg/cbeim94a1s2kebu.php?do=218', method='get'} in the http.log file to a certain site in IIS though.  And it wasn't our main site.  I turn off this website in IIS and it appears the weird request goes away.  I turn the site back on and it starts to re-appear.  It doesn't always load constantly so it's a little hard to tell.  This site is pretty small.  I went through each file on the site and did find one file that did appear to be hacked.  It wasn't coldfusion code though.  Just some html links.  I removed it.  That's all I could find.  No cfhttp calls or anything else.
    We re-installed Coldfusion 11 on Friday as well and upgraded to Update 3.  It doesn't stay locked at 100% as much right now, but it being over the weekend we don't get much traffic.  Monday will be the real test.  I think I will leave that smaller site turned off for now and see how things perform.  I'm doing a full virus scan for the heck of it overnight too.  Don't really expect it to find anything though. I also turned on advanced logging in IIS 7.5 and don't see anything out of the ordinary.  I made sure client variables weren't in the registry either.
    Here's a part of the http.log file when I turn the IIS site on.  I turn the site off and it stops popping up in the logs.
    "Information","ajp-bio-8014-exec-57","12/13/14","22:33:14",,"Starting HTTP request {URL='http://zzen1wbudopwg.nchyt.com/encfm/en0024-ssj5iway6wvg/cbeim94a1s2kebu.php?do=233', method='get'}"
    "Information","ajp-bio-8014-exec-57","12/13/14","22:36:17",,"Starting HTTP request {URL='http://zzen1wbudopwg.nchyt.com/encfm/en0024-ssj5iway6wvg/cbeim94a1s2kebu.php?do=601', method='get'}"
    "Information","ajp-bio-8014-exec-57","12/13/14","22:38:31",,"Starting HTTP request {URL='http://zzen1wbudopwg.nchyt.com/encfm/en0024-ssj5iway6wvg/cbeim94a1s2kebu.php?do=459', method='get'}"
    "Information","ajp-bio-8014-exec-57","12/13/14","22:38:54",,"Starting HTTP request {URL='http://zzen1wbudopwg.nchyt.com/encfm/en0024-ssj5iway6wvg/cbeim94a1s2kebu.php?do=108', method='get'}"
    "Information","ajp-bio-8014-exec-57","12/13/14","22:39:55",,"Starting HTTP request {URL='http://zzen1wbudopwg.nchyt.com/encfm/en0024-ssj5iway6wvg/cbeim94a1s2kebu.php?do=218', method='get'}"
    "Information","ajp-bio-8014-exec-63","12/13/14","22:52:03",,"Starting HTTP request {URL='http://zzen1wbudopwg.nchyt.com/encfm/en0024-ssj5iway6wvg/cbeim94a1s2kebu.php?do=54', method='get'}"
    "Information","ajp-bio-8014-exec-64","12/13/14","22:57:32",,"Starting HTTP request {URL='http://zzen1wbudopwg.nchyt.com/encfm/en0024-ssj5iway6wvg/cbeim94a1s2kebu.php?do=40', method='get'}"
    "Information","ajp-bio-8014-exec-64","12/13/14","22:58:37",,"Starting HTTP request {URL='http://zzen1wbudopwg.nchyt.com/encfm/en0024-ssj5iway6wvg/cbeim94a1s2kebu.php?do=702', method='get'}"

  • Emca -deconfig dbcontrol db -repos drop, perl 100%CPU

    Hello!
    My system is: Red Hat Enterprise Linux AS release 4 x64, Oracle 10.2.0.1.0
    Few days ago I had found that 2 perl processes eat 100% CPU.
    So I decided to restart EM. But the problem remain the same.
    Then I decided to recreate EM repository:
    emca -deconfig dbcontrol db -repos drop -SID db1 -HOST HP -ORACLE_HOME /app/oracle
    STARTED EMCA at Jul 9, 2010 11:49:17 AM
    EM Configuration Assistant, Version 10.2.0.1.0 Production
    Copyright (c) 2003, 2005, Oracle. All rights reserved.
    Enter the following information:
    Listener port number: 1521
    Password for SYS user:
    Password for SYSMAN user:
    Do you wish to continue? [yes(Y)/no(N)]: y
    Jul 9, 2010 11:49:31 AM oracle.sysman.emcp.EMConfig perform
    INFO: This operation is being logged at /app/oracle/cfgtoollogs/emca/ db1 /emca_2010-07-09_11-49-17-AM.log.
    Jul 9, 2010 11:49:31 AM oracle.sysman.emcp.util.DBControlUtil stopOMS
    INFO: Stopping Database Control (this may take a while) ...
    Jul 9, 2010 11:49:33 AM oracle.sysman.emcp.EMReposConfig dropRepository
    INFO: Dropping the EM repository (this may take a while) ...
    In this point command hangs.
    Looking to the processes:
    ps aux | grep perl
    oracle 15592 101 0.0 23752 8672 pts/2 R+ 12:11 0:24 /app/oracle/perl/bin/perl /app/oracle/sysman/admin/emdrep/bin/emrepmgr.pl -connect (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=HP)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME= db1))) -repos_user SYSMAN -action drop -verbose -output_file /app/oracle/cfgtoollogs/emca/ db1 /emca_repos_drop_2010-07-09_12-11-40-PM.log
    oracle 15667 0.0 0.0 51100 688 pts/4 S+ 12:12 0:00 grep perl
    Looking to the log:
    [oracle@HP db1]$ tail -n 50 /app/oracle/cfgtoollogs/emca/ db1 /emca_repos_drop_2010-07-09_12-11-40-PM.log
    [09-07-2010 12:11:40] Enter SYS user's password :
    [09-07-2010 12:11:40]
    [09-07-2010 12:11:40] Enter repository user password :
    [09-07-2010 12:11:40]
    [09-07-2010 12:11:40] Getting temporary tablespace from database...
    Could you please help me with this?
    Why does perl hang? And how to correctly recreate repository?
    (Is it possible to recreate repository without any outages(quiescing or restart the DB))
    Thanks!

    Yesterday I've started EM, but emagent had 100%CUP again.
    And there was an active session by sysman:
    BEGIN EMD_NOTIFICATION.QUEUE_READY(:1, :2, :3); END;
    After making some research, i've done this:
    sqlplus sysman@db1
    SQL>@/app/oracle/sysman/admin/emdrep/sql/core/latest/notification/notification_pkgbodys.sql
    (changing string DBMS_AQ.LISTEN (agents, qtimeout_in, agent);
    to DBMS_AQ.LISTEN (agents, 1200, agent);
    in it
    After restarting EM this problem remain the same.
    Logs:
    cat ./emagent.log
    2010-07-12 12:28:44 Thread-4136454368 Starting Agent 10.1.0.4.1 from /app/oracle (00701)
    2010-07-12 12:29:44 Thread-4136454368 target {db1, oracle_database} is broken: cannot compute dynamic properties in time. (00155)
    2010-07-12 12:29:44 Thread-4136454368 EMAgent started successfully (00702)
    and
    [oracle@HP log]$ tail -n 5 ./emdctl.trc
    2010-07-12 12:28:32 Thread-4136453824 WARN http: snmehl_connect: connect failed to (HP:3938): Connection refused (error = 111)
    2010-07-12 12:28:34 Thread-4136453824 WARN http: snmehl_connect: connect failed to (HP:3938): Connection refused (error = 111)
    2010-07-12 12:28:37 Thread-4136453824 WARN http: snmehl_connect: connect failed to (HP:3938): Connection refused (error = 111)
    2010-07-12 12:28:40 Thread-4136453824 WARN http: snmehl_connect: connect failed to (HP:3938): Connection refused (error = 111)
    2010-07-12 12:28:43 Thread-4136453824 WARN http: snmehl_connect: connect failed to (HP:3938): Connection refused (error = 111)
    Why does "Connection refused" appear?
    How to deal with this issue?
    Yours suggestions will be VERY appreciated. Thanks!
    Edited by: dmitry_rpd on Jul 13, 2010 12:33 AM

  • Load testing and 100% CPU Utilization - Multiple JVMs?

    Hi,
    Problem:
    While stress testing the application with 20 simultaneous users, unix is 100% utilized and there is degradation in response times.
    One component of the application is invoking a unix script which is executing a java program after setting CLASSPATH, PATH etc. I guess thus each execution will be invoking a jvm. At the end of the program it will do a System.Exit(). This java program generates around 15-60 barcode images. It takes 2 secs normally.
    When, 5 and 10 concurrent users executing this unix script for a steady state time of 30 minutes is also working fine even through response time degrades to 4 secs.
    With 20 concurrent users, unix box with 4 CPUs is 100% utilized and response time degrades to 11 secs or so.
    We need to do this through unix script only because it is executed from database tier (oracle reports - rdfs) and java stored procs doesn't allow awt operations (image file creation).
    I repeated this testing using a java class which just loops for 2 secs. With 20 concurrent users, it was also degrading to 6 secs or so and fluctuating between 100% CPU utilization.
    Any pointers on what we should be analyzing more and how should we try to solve this issue.
    Thanks,
    Ayyappa

    Stupid forums made me change the ``screen name.'' Whatever...
    Anyway, it is resource intensive to invoke a new JVM per request. You can do several things but it comes down to the fact you will want to keep ONE JVM running in the background awaiting requests to do work. These requests can come from several mechanisms, such as polling a database table, sending requests over a local TCP socket, listening in on a Unix fifo file, etc, etc.
    When the shell script is exec'd, connect to your JVM (for example) by opening a socket to it, enter your request for work, and wait for the response, the JVM app will listen and accept socket requests, thread off and process and then return data. Something in this form will be substantially more scalable that what is currently being done.

  • NTP/GSP high CPU util

    Hi,
    We have 2 ASR9k (v4.2.0) routers doing "light" xconnect work, no problems so far.
    Lately, we have noticed ntpd/gsp utilizing an abnormally high amount of CPU, is this normal behavoir on the ASR9k?
    RP/0/RSP0/CPU0:asr-1#show processes cpu | utility head -n 2
    Fri Aug 10 10:52:52.285 CET
    CPU utilization for one minute: 57%; five minutes: 57%; fifteen minutes: 57%
    RP/0/RSP0/CPU0:asr-1#show processes cpu | utility egrep -e ntpd -e gsp
    Fri Aug 10 10:52:59.346 CET
    233559  23%     23%      23% gsp
    266447  27%     27%      27% ntpd
    RP/0/RSP0/CPU0:asr-2#show processes cpu | utility head -n 2
    Fri Aug 10 10:53:39.162 CET
    CPU utilization for one minute: 56%; five minutes: 56%; fifteen minutes: 56%
    RP/0/RSP0/CPU0:asr-2#show processes cpu | utility egrep -e ntpd -e gsp
    Fri Aug 10 10:54:11.032 CET
    233559  22%     22%      22% gsp
    266447  28%     28%      28% ntpd
    /Bjorn

    CSCtw87827 is a known issue in 4.2.0 causing high CPU in ntpd/gsp.
    Workaround is to enable IPv6 on the source interface used by NTP, but I'd recommend considering moving to 4.2.1 which is much more stable (unless extended validation testing was made for 4.2.0 of course)
    Here is the full release note:
    Issue:
    ======
    The NTPD process takes around 27% cpu usage after upgrade to 4.2.0 30I. We did not see this issue before and we don not see this issue on another ASR9K running on 20L also.
    Root cause:
    ens_read_nb is getting called irrespective of producer available for requested interface exists or not. So this retry is happening infinitely if the requested interface is not configured with ipv6.
    Fix:
    ====
    When ENS_CMD_NB_STATUS is received we need to check the 'status' flag which is part of 'grp_ens_nb_status_msg_st' which is passed as part of 'value' parameter to the consumer callback. If this comes as 'ETIME' then it represents producer is available, but timeout happened due to some other reasons. If status is 'ESRCH' then it represents that producer doesn't exist for the requested interface. These are the two values for 'status' as of now.
    Workaround:
    ===========
    Configure either 'ipv6 enable' or an ipv6 address under requested interface. This will avoid infinite retrying from consumer library.
    Condition which causes to hit this issue:
    ===============================
    If any one of the LAS client register for link local address without enabling ipv6 on that interface, which may be due to configure/unconfigure/rollback and all.

  • 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.

  • Queue consumer stops with 100% cpu usage

    I'm trying to use Berkeley DB queue with transactions. When I tested what happens when transactions with DB_APPEND are aborted I found that while it works and DB_CONSUME correctly skips over rolled back records, unfortunately extents that have those records are never deleted, which causes database to always grow. Next I tried DB_CONSUME with database opened using DB_INORDER flag and it seems there's a serious regression in Berkeley DB that causes it to loop indefinitely with 100% cpu usage when it encounters a rolled back record. I tested various versions and found that this bug doesn't happen with 5.1.29, but it is reproducible with 5.2.42, so this regression might have been introduced in 5.2. I have also tested 5.3 and 6.0, and both have this behavior. There may be something wrong with the way queue records are rolled back, one indication of that would be that in 5.1.29 doesn't have neither of the two problems I found with DB_QUEUE: extents are deleted after being consumed, and there are no issues when consuming with DB_INORDER either.
    You can find Python code to reproduce this issue here:
    https://gist.github.com/snaury/027a3c546f5b0a62a440
    Sorry for using Python and not e.g. C++, but it's a lot shorter that way.

    We have looked at the issues and they are valid.   We will roll the fixes out for this in our next release of BDB.   The test case was very useful and really helped to speed the process up.    If you have any questions, please contact me directly at [email protected]  Thanks again for bringing this to our attention.
    thanks
    mike

  • HP LaserJet Pro MFP M127fn - DNS issue, hundreds of UDP connections affects my router 100% CPU usage

    Hi all,
    We've bought about ten pieces (HP LaserJet Pro MFP M127fn), tested only one the other 9 are waiting for their time to be sent in our branch offices. The MFP works fine, no complains till later that day I noticed that our Mikrotik Router was struguling with high CPU usage, it took me some time to find the issue and it was the new bought MFP. Don't know why but it creates hundreds of UDP connections and almost 100% CPU usage goes to DNS service. As soon as I shutdown the MFP and delete all the connections everything goes back to normal. I've disabled almost all services (HP web service, Ipv6, SNMP, AirPrint, SLP, LPD, WS-Discovery, Bonjour), leaving only Ipv4 but without luck the issue persists. Here are some print screens confirming my saying:
    http://i.imgur.com/UiOPSiu.jpg
    http://i.imgur.com/dlgObPb.jpg
    http://i.imgur.com/4RmQhot.jpg
    http://i.imgur.com/oBuo9UO.jpg
    http://i.imgur.com/Zf77V6b.jpg
    Don't know if it is the same case but it look like, found this post that ha no answer to the issue: http://h30434.www3.hp.com/t5/Printer-Networking-and-Wireless/New-HP-LaserJet-Pro-MFP-M127fw-network-...
    Why does this happen? And how to solve my issue? Thank you in advance.

    Hi @EugenX ,
    I have brought your issue to the attention of an appropriate team within HP. They will likely request information from you in order to look up your case details or product serial number. Please look for a private message from an identified HP contact. Additionally, keep in mind not to publicly post serial numbers and case details.
    If you are unfamiliar with how the Forum's private message capability works, this Post has instructions.
    Thank You.
    Please click “Accept as Solution ” if you feel my post solved your issue, it will help others find the solution.
    Click the “Kudos Thumbs Up" on the right to say “Thanks” for helping!
    Gemini02
    I work on behalf of HP

  • This new version of FireFox is making me nutz! It is SUCKING 100% CPU time almost constantly. I could just pull my hair out. I wpdated once a month or so ag

    I tried to add this in the topic already open but it kept sending me through the unending rabbit holes!
    My question is: How do I figure out what release I was on, get rid of this one and got back to a functional firefox that moves in realtime. I already did all the reset and etc.... I just want to go back to the speed I had. This halting , hanging up misery of a browzer is Sad. I have had firefox for years and always recommended it ..... BUT NOT ANY MORE. I agree with the other poster ... there should be a rollback feature. Peoples time has value and right now FireFox is sucking the value down a rabbit hole.
    See Below Comment Feedback submitted before I finally got here:
    This new version of FireFox is making me nutz! It is SUCKING 100% CPU time almost constantly. I could just pull my hair out. I wpdated once a month or so ago and it slowed down..... but the latest update before I did the reset really slowed me down. I came here to fix it a couple of dayz ago and did the reset firefox and now it IS RUNNING SO POORLY AND SLOW I AM ABOUT TO KILL IT OFF MY MACHINE!!! Yes that is me yelling - and it happened in SSSSSSSSSSSSS LLLLLLLLL OOOOOOOO WWWWWWWWWW Motion. I have run all the security scans and cleanups ---this needs a fix ASAP!!! PS: The hang ups and slowness is EVERYWHERE I go. I only get speed doing programs not connected to ON LINE.

    Hello,
    The Reset Firefox feature can fix many issues by restoring Firefox to its factory default state while saving your essential information.
    Note: ''This will cause you to lose any Extensions, Open websites, and some Preferences.''
    To Reset Firefox do the following:
    #Go to Firefox > Help > Troubleshooting Information.
    #Click the "Reset Firefox" button.
    #Firefox will close and reset. After Firefox is done, it will show a window with the information that is imported. Click Finish.
    #Firefox will open with all factory defaults applied.
    Further information can be found in the [[Reset Firefox – easily fix most problems]] article.
    Did this fix your problems? Please report back to us!
    Thank you.

Maybe you are looking for