LabVIEW pegs CPU usage after running VIs

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

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

Similar Messages

  • Google Earth Plugin and LabVIEW: High CPU usage when adding placemarks

    Hi,
    I posted this question on stackoverflow earlier this week but feel it might be better suited to the LabVIEW community specifically so I'm reposting here:
    I'm writing an application which uses the Google Earth Plugin to display events on the globe. Each event is a single point kml placemark with an icon which is a 3kb png file. Placemarks are uploaded to the plugin as they are received by the software. I am experiencing increasing CPU usage with the number of placemarks that are added.
    I have tested displaying a new placemark every second and running until the software running the plugin completely froze (graph attached). The GEPlugin (green trace) stopped responding (i.e. the globe did not respond to the mouse) at around 1200 placemarks added and CPU usage was at ~30%. When the software itself (red trace) froze the plugin was using around 50% CPU and ~3700 placemarks had been added). After the freeze, no new placemarks were added which caused the software to respond (but not the plugin) so I could clear all the placemarks. After the placemarks were cleared from the globe, the CPU usage of the plugin returned to around 5% CPU.
    So what I've seen is that GEPlugin CPU usage increases linearly with each kml placemark added. Is this the expected behaviour/ a normal limitation of the plugin? If not is there a more efficient way of adding many placemarks to the globe?
    I am using GEPlugin version 7.1.1.1580 (API version 1.010) and LabVIEW 12.0f3
    Please see the test results attached. Any input greatly appreciated!
    Original stackoverflow post:
    http://stackoverflow.com/questions/20994323/google-earth-plugin-with-labview-high-cpu-usage-when-add...
    Attachments:
    Performance Log 020114_095115.png ‏82 KB

    Hello,
    I have had a look at your graphs and understood what you are trying to do. To me it seems that as the image gets more complex it gets harde to render which wold likely cause increase in CPU usage resulting in the freeze. I would suggest you try running the program on anoher computer to check on the RAM front of things. If this is a limitation of the GE Plugin then unfortunately I can not do much to help, but if you think this is a problem coming from your LabVIEW code then you can post your code here and I can take a look.

  • Dock process has high CPU usage after Mountain Lion upgrade

    Dock process has high CPU usage after Mountain Lion upgrade and possibly after installing XCode as well.
    When I run "sudo opensnoop -n Dock" I see the following being constantly repeated.
    501    263 Dock          28 /Applications/Xcode.app
      501    263 Dock          28 /Applications/Xcode.app/Contents
      501    263 Dock          28 /Applications/Xcode.app/Contents/Info.plist
      501    263 Dock          28 /Applications/Xcode.app/Contents/Info.plist
      501    263 Dock          28 /Applications/Xcode.app/Contents/Resources
      501    263 Dock          28 /Applications/Xcode.app/Contents/Resources
      501    263 Dock          28 /Applications/Xcode.app/Contents/Resources/English.lproj
      501    263 Dock          -1 /Applications/Xcode.app/Contents/Resources/Base.lproj
      501    263 Dock          28 /Applications/Xcode.app/Contents/PkgInfo
      501    263 Dock          28 /Applications/Xcode.app/Contents/MacOS/Xcode
      501    263 Dock          28 /.vol/16777218/92542858
      501    263 Dock          29 /Applications/Xcode.app/Contents/Library/Spotlight/uuid.mdimporter/Contents/Inf o.plist
      501    263 Dock          28 /Applications/Adobe Dreamweaver CS5/Configuration/Shared/ICE/Templates
      501    263 Dock          28 /Applications/Adobe Dreamweaver CS5/Configuration/Shared/MM
      501    263 Dock          28 /Applications/Adobe Dreamweaver CS5/Configuration/Shared/MM/Cache
      501    263 Dock          28 /Applications/Xcode.app/Contents/Resources
      501    263 Dock          28 /Applications/Xcode.app/Contents/Resources
      501    263 Dock          28 /Applications/Xcode.app/Contents/Resources/English.lproj
      501    263 Dock          -1 /Applications/Xcode.app/Contents/Resources/Base.lproj
      501    263 Dock          28 /Applications/Xcode.app/Contents/PkgInfo
      501    263 Dock          28 /Applications/Xcode.app/Contents/MacOS/Xcode
      501    263 Dock          28 /.vol/16777218/92542858
      501    263 Dock          29 /Applications/Xcode.app/Contents/Library/Spotlight/uuid.mdimporter/Contents/Inf o.plist
      501    263 Dock          28 /Applications/Adobe Dreamweaver CS5/Configuration/Shared/MM/Images
    When I run "killall Dock" it resolves it for awhile and then comes back.

    Welcome to Apple Communities
    https://discussions.apple.com/message/18825564#18825564

  • Laptop fan runs all the time, broker runtime cpu usage after Windows 10 final upgrade

    ENVY 17t-J100 Leap Motion, 16 GB RAM, i7, SSD primary, HDD secondary drives. Avast antivirus free. Windows Firewall. The laptop had Windows 8.1 and everything was great. I did the Windows 10 Home free upgrade on Day 1. Everything seemed fine. Fingerprinter reader and everything works. Great. But then I noticed that the fan was always running and the left side of the metal casing gets hot. In task manager heat map sorted by CPU usage, Broker Runtime is at the top. Not much ram, about 10 MB. But the CPU usage is always 20% and higher. Doesn't seem like much. But it makes the fan run all the time and the laptop heats up with it running all the time. Anyone else seen this? General internet searching shows this has been an issue with Broker Runtime since Windows 8 and not unique to any brand of computer. But it wasn't like this when I was using WIndows 8.1 One forum said it was the P2P Windows update feature and my laptop was sharing updates. So I disabled that and rebooted. No change. Now I see some people saying it is the Live Tiles features in the Start Menu. But I had live tiles with the WIndows 8 menu and no issues. The only way to disable Live Tiles globally is to edit the registry, and I shouldn't have to do that for this. And I like Live Tiles. So not sure that really is the issue either.

    hockeycanuckjc wrote:
    Have all Windows Updates on Windows 10 been applied since installing it? I know there are people weary to update Windows 10 since there have been a few news reports with some people having the infinite reboot loop after installing a particular update  For me, yes. All updates applied and automatic updates enabled. This Runtime Broker issue has been there since the upgrade and all updates to this point.

  • UserEventAgent 100% CPU Usage after update to 10.6.2

    After a software update to my new Macbook pro, it is unusable with cpu usage pegged at 99.5% in the activity monitor. This goes down when I disconnect my Kinesis USB keyboard from the mac. Before the update, everything was fine.
    What's the way around this problem? I have an ergonomic keyboard.
    Processes: 47 total, 3 running, 44 sleeping, 193 threads 12:17:15
    Load Avg: 1.00, 0.75, 0.39 CPU usage: 1.46% user, 51.70% sys, 46.82% idle
    SharedLibs: 9128K resident, 8192K data, 0B linkedit.
    MemRegions: 5453 total, 252M resident, 13M private, 145M shared.
    PhysMem: 783M wired, 384M active, 176M inactive, 1342M used, 2753M free.
    VM: 110G vsize, 1041M framework vsize, 40023(0) pageins, 0(0) pageouts.
    Networks: packets: 25511/5152K in, 4726/1598K out.
    Disks: 20435/824M read, 7482/171M written.
    PID COMMAND %CPU TIME #TH #WQ #POR #MRE RPRVT RSHRD RSIZE VPRVT
    376 top 2.6 00:00.32 1/1 0 24 33 1076K 244K 1652K 17M
    373 bash 0.0 00:00.00 1 0 17 24 364K 244K 1036K 17M
    372 login 0.0 00:00.01 1 0 22 53 460K 244K 1568K 18M
    370 ssh-agent 0.0 00:00.03 2 1 33 56 1080K 368K 2400K 39M
    364 Terminal 1.8 00:02.13 5 1 112- 159 7656K 27M 19M 30M
    135 AppleSpell 0.0 00:00.26 2 1 35 54 3248K 14M 6676K 29M
    131 Safari 0.0 00:23.37 9 2 149 486 61M 31M 96M 213M
    127 System Profi 0.0 00:00.34 2 1 96 105 4124K 22M 9460K 32M
    125 mdworker 0.0 00:00.52 3 1 50 73 4432K 12M 12M 37M
    124 activitymoni 0.0 00:05.08 1 0 23 37 596K 244K 1120K 28M
    121 Activity Mon 0.0 00:06.66 2 1 112 271 4928K+ 37M- 18M 25M-
    104- My Day 0.2 00:03.23 7 2 135 252 12M 22M 22M 47M
    103- Microsoft Da 0.0 00:00.48 3 1 78 169 3064K 18M 8964K 32M
    100 AirPort Base 0.0 00:00.01 3 1 32 50 672K 244K 1640K 30M
    94 UserEventAge 99.9 06:01.31 3/1 1 174 104 2456K 2412K 5784K 41M
    90 fontd 0.0 00:00.31 2 1 81 113 3220K 728K 4316K 30M
    8

    I now have 10.6.3 and the problem has become worse. I found a similar thread where multiple people had a problem with the kinesis usb keyboard:
    http://discussions.apple.com/thread.jspa?threadID=1197549&start=0&tstart=0
    Will try removing the AppleHIDMouseAgent plugin.

  • High cpu usage after a while

    Sometimes, after a while, firefox (36.0.4) uses up 1 core of my CPU (is a quad core due to hypertreading). The way it happens is really strange. Many tabs without a problem until suddenly ff decides to floor it. This is alway in the run, not on startup or close. All add-ons need to ask my permissions to be activated, this includes flash.
    On close, I ordered ff to clear all history and cookies.
    Notes that could be important (The behavior encountered while using it. This varies from time to time):
    opening new tabs (a lot or a few) => "heavy" load during site loading, then idling
    ==> The above makes sense
    - same as above but load continues to be heavy. => could be some badly written javascript on the site, however, sometimes this occurs with sites I know have no stressful javascript
    ==> The above seems odd
    - Browser is idle in the background (not actively using it). Then all of the sudden "lets floor it until closed".
    ==> The above seems pretty odd
    - When confronted with high CPU usage, closing ff doesn't close it (the ff process remains active. Not a ff process, THE ff process). => High CPU usage remains
    ==> The above looks like that there is definitely something wrong here
    This last one has some other things to keep in mind
    - When it happens and I close ff, upon restarting it it will ALWAYS ask to close ff. After confirming to close it, it will start and behave normally.
    - When killing ff via the task-manager, or other means like powershell commands, restarting it will result in an idle ff even after every tab is loaded again.
    I hope this isn't a heisenbug and there is a solution to this, a reboot ff button would be a nice workaround though. I personally think that it must be some routine in the code that decides to go nuts for no reason.
    If you need further details, feel free to ask.
    Thanks in advance

    Tried those before and tried them again. Unfortunately, the problem keeps repeating itself at random times. As said, sometimes it doesn't occur and sometimes suddenly it does. Keep the following things in mind about this, what seems like a heisenbug, behavior.
    - opening new tabs (a lot or a few) => "heavy" load during site loading, then idling
    ==> The above makes sense
    - same as above but load continues to be heavy. => could be some badly written javascript on the site, however, sometimes this occurs with sites I know have no stressful javascript
    ==> The above seems odd
    - Browser is idle in the background (not actively using it). Then all of the sudden "lets floor it until closed".
    ==> The above seems pretty odd
    - When confronted with high CPU usage, closing ff doesn't close it (the ff process remains active. Not a ff process, THE ff process). => High CPU usage remains
    ==> The above looks like that there is definitely something wrong here
    As stated, a reboot ff button would be a nice workaround. I personally think that something like a tread must get stuck in some sort of infinite loop. Browsing in ff works just fine though. I just don't like the fact that I turns into a "gasoline guzzler".
    Again, thanks in advance

  • 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

  • High CPU usage while running a java program

    Hi All,
    Need some input regarding one issue I am facing.
    I have written a simple JAVA program that lists down all the files and directories under one root directory and then copies/replicates them to another location. I am using java.nio package for copying the files. When I am running the program, everything is working fine. But the process is eating up all the memories and the CPU usage is reaching upto 95-100%. So the whole system is getting slowed down.
    Is there any way I can control the CPU usage? I want this program to run silently without affecting the system or its performance.

    Hi,
    Below is the code snippets I am using,
    For listing down files/directories:
            static void Process(File aFile, File aFile2) {
              spc_count++;
              String spcs = "";
              for (int i = 0; i < spc_count; i++)
              spcs += "-";
              if(aFile.isFile()) {
                   System.out.println(spcs + "[FILE] " + aFile2.toURI().relativize(aFile.toURI()).getPath());
                   String newFile = dest + aFile2.toURI().relativize(aFile.toURI()).getPath();
                   File nf = new File(newFile);
                   try {
                        FileCopy.copyFile(aFile ,nf);
                   } catch (IOException ex) {
                        Logger.getLogger(ContentList.class.getName()).log(Level.SEVERE, null, ex);
              } else if (aFile.isDirectory()) {
                   //System.out.println(spcs + "[DIR] " + aFile2.toURI().relativize(aFile.toURI()).getPath());
                   String newDir = dest + aFile2.toURI().relativize(aFile.toURI()).getPath();
                   File nd = new File(newDir);
                   nd.mkdir();
                   File[] listOfFiles = aFile.listFiles();
                   if(listOfFiles!=null) {
                        for (int i = 0; i < listOfFiles.length; i++)
                             Process(listOfFiles, aFile2);
                   } else {
                        System.out.println(spcs + " [ACCESS DENIED]");
              spc_count--;
    for copying files/directories:public static void copyFile(File in, File out)
    throws IOException {
    FileChannel inChannel = new
    FileInputStream(in).getChannel();
    FileChannel outChannel = new
    FileOutputStream(out).getChannel();
    try {
    inChannel.transferTo(0, inChannel.size(),
    outChannel);
    catch (IOException e) {
    throw e;
    finally {
    if (inChannel != null) inChannel.close();
    if (outChannel != null) outChannel.close();
    Please let me know if any better approach is there. But as I already said, currently it's eating up the whole memory.
    Thanks in advance.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

  • CPU usage while running Bex report

    Hello,
    Sometimes, when I run a Bex report with many lines the computer CPU Usage is 100% (=full ) for a long time. In some cases i need to do restart again for the computer.
    In the WAD  it doesn’t happened...
    Did anybody have the same problem? Is there a way to reduce the CPU usage?
    Please Advice,
    Amir

    Amir,
    This is "normal" behaviour in Bex with query's which return very long lists. The client computer already received all data, but is formatting the layout.
    Solutions:
    1) a faster pc with enough memory (512 mb) and win200 or >.
    2) a query with less return rows.
    The reason that in wad (web reporting) this is not experienced is because the formatting (rendering html) from the result table is done within the WAS (application server, which is hopefully faster then your PC...). Your browser only receives the html page..no exotic hardware needed for that..
    Any questions left: please ask; if you're satisfied please grant with rewards.
    Kind regards Patrick Rieken.
    Message was edited by: Patrick Rieken

  • High CPU usage after closing a program.

    Okay, this is annoying. Doesn't happen on all programs, but too many.
    When I close an application, in normal way, alt+f4/press x/file->quit the program quits, BUT, "ghost" application starts, which raises to 100% CPU usage. Then I have to close it via sigterm/sigkill. This has happened (atleast) with mplayer, nvidia-settings (which doesn't even start, but cpu usage raises to 100% anyway, and ghost application starts) and WoW thru Wine. Now, I have absolutely no idea what is going on, and I've found nothing on google.
    I think it became after I upgraded to 2.6.29 kernel, it's 2.6.30 now and still the same.
    A little help please

    The nvidia-settings starts, as it shows on system monitor (htop, etc) but I am not getting the window, and cpu usage raises to 100% instantly. Terminal output:
    dfizzle@ohai ~$ nvidia-settings
    The valid values for 'XVideoTextureContrast' are in the range -1000 - 1000
    (inclusive).
    'XVideoTextureContrast' can use the following target types: X Screen.
    The valid values for 'XVideoTextureSaturation' are in the range -1000 -
    1000 (inclusive).
    'XVideoTextureSaturation' can use the following target types: X Screen.

  • Labview hangs on exit after running VI with ActiveX

    I have a vi with an ActiveX container which generates many events (30-50/sec). The events are serviced in queued mode. Among other things the ActiveX object polls internally for snapshot data from DSC Tags (rarely - only once per minute).
    After the vi terminates there are two types of errors:
    1. Labview can't close even though it is asked to from its main UI - it still resides as a process and is present in the task bar but there is no UI to it - something must be preventing it from closing.
    2. After restarting, the VI hangs on the first call to the ActiveX object (create event queue)
    Does anyone have an idea what can be happening? Can a large number of ActiveX events cause a problem resulting in Labview ins
    tability? Are there any tools to find out what is causing it?
    Thanks

    One possibility is that it there is a very large number of unprocessed events in the queue when you stop the application, and it takes LV time to deallocate all the memory. I had this happen one due to control references that weren't geting closed. After running over night it could literally take LV over an hour to deallocate all the thousands of unclosed references left in memory.
    Might be the same sort of thing going on. Watch LV's memory allocation in the Task Manager when you attempt to shut down and see if it is very large and then starts going down very slowly...
    Mike...
    Certified Professional Instructor
    Certified LabVIEW Architect
    LabVIEW Champion
    "... after all, He's not a tame lion..."
    Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

  • Labview consuming cpu with no running vi

    I'm running Labview 2012 12.0f3  64 bit Professional.
    When my laptop comes out of standby, Labview starts consuming 13% CPU with no running vi's.
    There are several VI's open but not running.
    This is very annoying.
    Is this expected behaviour or a known problem?

    Could be related to this
    LabVIEW Champion . Do more with less code and in less time .

  • Yoga - Thinkpad message receiver for shortcut hot keys and 30 % CPU usage after lock screen or sleep

    Hi! After returning from sleep or lock screen a process called "Thinkpad message receiver for shortcut hot keys" starts using about 30% of the CPU. Temps go upo to 60-70 degrees battery is being depleted quite fast. This process doesn't stop until I end it using task manager. Once ended that way, it doesn't start again even if I use sleep or lock screen. Need help with this!
    I didn't use to have this problem like a month ago or so. Probably came into existence after some updates.
    Solved!
    Go to Solution.

    ChrisL_US wrote:
    Do any of you have Kaspersky Anti-Virus or Internet Security? Seems like few T540 owners also got the same problem and one of them discovered it is Kaspersky causing the problem. I can comform it too.
    I am using Kaspersky Internet Secuirty 2015, when I resume my TPY from sleep, the message receiver for shortcut hot keys will show up and use 20-35% processing power which cause the laptop to heat up.
    I hope a Thinkpad rep can come in to report the bug.
    The T540p post link: https://forums.lenovo.com/t5/T400-T500-and-newer-T​-series/t540p-high-cpu-usage-by-shtctky-exe-ThinkP​...
    Thanks ChrisL_US! I do have kaspersky anti-virus 2015 installed.

  • 100% CPU usage after games are run

    Hi All
    Having a Strange problem with iTunes. All works fine unless I play a Steam based game e.g. Counterstrike:source. If I try and launch iTunes after closing a steam game sometimes (but not always) itunes.exe will launch, there is some HD activity, nothing else happens. If I check taskmanager itunes.exe is using 100% of the CPU.
    I have tried quitting and closing all possible tasks but iTunes will always launch in the same manner. A log out will not fix it, the only way to get iTunes to work again it restarting the machine.
    I have had this problem since the first windows release of itunes. Is it an issue within steam? Is anyone else getting this happen?
    Thanks
    Dan

    Tell the scanning software not to scan the entire iTunes folder. iTunes makes temp XML files every time you play a song. It does this to keep track of times & last date played.
    http://discussions.apple.com/thread.jspa?threadID=165247&tstart=0
    Or open up a ticket with the antivirus vendor.

  • 100% CPU usage after starting/joining a call

    This problem has been persisting for a few months now, and I haven't found a fix. Sometimes when I would start or join a call, the first thread of my i7 would shoot up to 100% usage (Monitored with MSI Afterburner). I originally thought it was because I had an older version of Skype, but I updated to the latest version and still had the issue. To get the usage to go down, I either have to restart the laptop or put it into sleep mode. When I checked the task manager, Skype was only using 0%-2% of my CPU, but System and System Interrupts run at higher usage (6%-7% each). I am running Windows 8.1 on a laptop with the desktop version of Skype. Please note that this also does not happen every time, just on some occasions.
    EDIT: It eventually happens, but not always right away.

    Yes, you can use NI-DAQmx with Visual C++ and with Mesurement Studio 7 or later you also have Microsoft Visual C++ class libraries for NI-DAQmx.
    If you are now developing a application I would advice to move to DAQmx since this the Traditional libraries are nolonger activly developed, we will only be adding new features and hardware to NI-DAQmx, thus for future support of the application it's better to use NI-DAQmx then Traditional NI-DAQ.
    For more information on NI-DAQmx see:
    http://zone.ni.com/devzone/conceptd.nsf/webmain/ee47b125bb9e053686256fbc0014c384?OpenDocument
    Met vriendelijke groet / Kind regards,
    Karsten
    Applications Engineer
    National Instruments

Maybe you are looking for