Long GC pause - grey object rescan

We observe occaisional GC pauses on our app server which seem to be caused by a "grey object rescan". In the past they ranged from 20-30s, but yesterday we had a 84s pause. That's a bit much...
[GC 1593754.769: [ParNew: 450212K->46400K(471872K), 0.1076340 secs] 1984347K->1585395K(3019584K), 0.1079070 secs]
1593757.147: [GC[YG occupancy: 339101 K (471872 K)]1593757.147: [Rescan (non-parallel) 1593757.147: [grey object rescan, 84.6104290
secs]1593841.758: [root rescan, 0.3187110 secs], 84.9293110 secs]1593842.076: [weak refs processing, 0.0100700 secs]1593842.087: [cl ass unloading, 0.1208600 secs]1593842.207: [scrub symbol & string tables, 0.0189270 secs] [1 CMS-remark: 1538995K(2547712K)] 1878096 K(3019584K), 85.1028700 secs]
My question is: what exactly causes this? Any way to avoid it?
I've found a couple bugs that might be related: 6367204, 6298694. Although I don't think there we have any huge arrays.
Or GC settings are as follows:
/usr/java/jdk1.5.0_06/bin/java -server -Xms3000m -Xmx3000m -XX:LargePageSizeInBytes=2m -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSCompactWhenClearAllSoftRefs -XX:SoftRefLRUPolicyMSPerMB=200 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:-CMSParallelRemarkEnabled -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:NewSize=512m -XX:MaxNewSize=512m -XX:SurvivorRatio=8 -XX:PermSize=156m -XX:MaxPermSize=156m -XX:CMSInitiatingOccupancyFraction=60 -Xloggc:/var/ec/gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+PrintClassHistogram -XX:+TraceClassUnloading -Duser.region=US -Dsun.rmi.dgc.client.gcInterval=86400000 -Dsun.rmi.dgc.server.gcInterval=86400000
Any help/suggestions are highly appreciated. Thanks!

When using the concurrent mark-sweep (cms) collector there is a phase where
cms is looking for all the live objects (referred to as concucrent marking of live objects)
in the heap while the application is running and likely changing objects in the heap.
In order to assure correctness cms has a phase (referred to as the remark)
where all the applications threads are stopped and it looks for
objects that have changed while it was doing the concurrent marking. The "grey object
rescan" refers to looking at the objects that have changed. This "grey object
rescan" depends on the number of objects that are changed during the
concurrent marking so the level of activity of the application can affect
this phase.
I note that you have turned off the parallel remark on the command line
(-XX:-CMSParallelRemarkEnabled). If you've had problems with the
parallel remark, then turning it on is not an option. If you have not had
problems with parallel remark, turn it on and see if it helps.
If you use the flag -XX:PrintCMSStatistics=1, you will get additional output.
In it you can look for lines such as
(re-scanned XXX dirty cards in cms gen)
If XXX is smaller in the cases where the "grey object rescan" is shorter and
XXX is larger in the cases where the "grey object rescan" is longer, then
the problem is due to lots of activity by the application during the concurrent
mark. If you're not on the 5.0 jdk and can move to it, please do. The parallel
remark will be more stable.

Similar Messages

Prevent long GC pauses

Hello,
I'm using jdk1.6.
The problem is, that sometimes I'm facing a long gc pause, specially during "concurrent mode failure".
Is there any option for jvm to set a max AppStopTime? And what could be the impact setting such a option ?
Here are the jvm settings I'm currently using:
-Xms4G -Xmx4G -XX:MaxNewSize=128M -XX:NewSize=128M -XX:MaxPermSize=256M -XX:PermSize=256M"
-server -showversion -Xbatch -XX:+UseLargePages -XX:LargePageSizeInBytes=32M
-XX:+UseParNewGC -XX:ParallelGCThreads=4 -XX:ParallelGCToSpaceAllocBufferSize=192k -XX:SurvivorRatio=6 -XX:TargetSurvivo
rRatio=75 -XX:+UseConcMarkSweepGC -XX:CMSMarkStackSize=32M -XX:CMSMarkStackSizeMax=32M -XX:+CMSParallelRemarkEnabled -XX:-CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSInitiatingOccupancyOnly -XX:+DisableExplicitGC'
Afaik there is no other chance to improve gc settings. Do you see any other possibilities ?
Thanks,
Christian

Depending on how long lived the majority of the objects in your heap are you can better adjust the sizes of the new and old generation spaces. If short lived, make your new gen space larger. You could make it as large as half your total heap using "-XX:NewRatio=1". (NewRatio would replace using MaxNewSize)
How do you know if objects are short lived or long lived? If you watch the action in your heap with VisualGC/Visual VM, and in the display you see everything get cleaned up in the eden & survivor spaces with each GC, then you probably have mostly short lived objects.
You may also see that your survivor spaces are too small. If too small, objects get promoted to the old generation space too quickly, filling up your old gen space unnecessarily, and creating long GC pauses.
The best situation is where eden and the survivior spaces are sized such that as many as possible objects get cleaned up on an ongoing basis without them moving to the old generation space as they age.

Strange Long ParNewGC Pauses During Application Startup

Recently we started seeing long ParNewGC pauses when starting up Kafka that were causing session timeouts:
[2015-04-24 13:26:23,244] INFO 0 successfully elected as leader (kafka.server.ZookeeperLeaderElector)
2.111: [GC (Allocation Failure) 2.111: [ParNew: 136320K->10236K(153344K), 0.0235777 secs] 648320K->522236K(2080128K), 0.0237092 secs] [Times: user=0.03 sys=0.01, real=0.02 secs]
2.599: [GC (Allocation Failure) 2.599: [ParNew: 146556K->3201K(153344K), 9.1514626 secs] 658556K->519191K(2080128K), 9.1515757 secs] [Times: user=18.25 sys=0.01, real=9.15 secs]
[2015-04-24 13:26:33,443] INFO New leader is 0 (kafka.server.ZookeeperLeaderElector$LeaderChangeListener)
After much investigation I found that the trigger was the allocation of a 500M static object early in the startup code. It of course makes no sense that a single large static object in Old memory would impact ParNew collections, but, it does seem to. I have created a bug report, but, it is still under investigation.
I have reproduced the problem with a simple application on several Linux platforms including an EC2 instance and the following JREs:
OpenJDK: 6, 7, and 8
Oracle: 7 and 8
Oracle 6 does not seem to have an issue. All the ParNewGC times are small.
Here is the simple program that demonstrates the issue:
import java.util.ArrayList;
public class LongParNewPause {
   static byte[] bigStaticObject;
   public static void main(String[] args) throws Exception {
   int bigObjSize = args.length > 0 ? Integer.parseInt(args[0]) : 524288000;
   int littleObjSize = args.length > 1 ? Integer.parseInt(args[1]) : 100;
   int saveFraction = args.length > 2 ? Integer.parseInt(args[2]) : 10;
   bigStaticObject = new byte[bigObjSize];
ArrayList<byte[]> holder = new ArrayList<byte[]>();
   int i = 0;
   while (true) {
   byte[] local = new byte[littleObjSize];
   if (i++ % saveFraction == 0) {
holder.add(local);
I run it with the following options:
-verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Xmx2G -Xms2G
Note that I have not seen the issue with 1G heaps. 4G heaps exhibit the issue (as do heaps as small as 1.2G)
Here is the output:
0.321: [GC (Allocation Failure) 0.321: [ParNew: 272640K->27329K(306688K), 0.0140537 secs] 784640K->539329K(2063104K), 0.0141584 secs] [Times: user=0.05 sys=0.02, real=0.02 secs]
0.368: [GC (Allocation Failure) 0.368: [ParNew: 299969K->34048K(306688K), 0.7655383 secs] 811969K->572321K(2063104K), 0.7656172 secs] [Times: user=2.89 sys=0.02, real=0.77 secs]
1.165: [GC (Allocation Failure) 1.165: [ParNew: 306688K->34048K(306688K), 13.8395969 secs] 844961K->599389K(2063104K), 13.8396650 secs] [Times: user=54.38 sys=0.05, real=13.84 secs]
15.036: [GC (Allocation Failure) 15.036: [ParNew: 306688K->34048K(306688K), 0.0287254 secs] 872029K->628028K(2063104K), 0.0287876 secs] [Times: user=0.08 sys=0.01, real=0.03 secs]
15.096: [GC (Allocation Failure) 15.096: [ParNew: 306688K->34048K(306688K), 0.0340727 secs] 900668K->657717K(2063104K), 0.0341386 secs] [Times: user=0.09 sys=0.00, real=0.03 secs]
Even stranger is the fact that the problem seems to be limited to objects in the range of about 480M to 512M. Specifically:
[503316465,536870384]
Values outside this range appear to be OK. Anyone have any thoughts? Can you reproduce the issue on your machine?

I have started a discussion on this issue on the hotspot-gc-dev list:
Strange Long ParNew GC Pauses (Sample Code Included)
One of the engineers on that list was able to reproduce the issue and there is some discussion there about what might be going on. I am a GC novice, but, am of the opinion that there is a bug to be found in the ParNew GC code introduced in Java 7.
Here is a more frightening example. The ParNew GCs keeping getting longer and longer - it never stabilized like the previous example I sent did. I killed the process once the ParNew GC times reached almost 1 minute each.
Bad Case - 500M Static Object:
java -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Xmx6G -Xms6G LongParNewPause $((500*1024*1024)) 100 100
0.309: [GC0.309: [ParNew: 272640K->3028K(306688K), 0.0287780 secs] 784640K->515028K(6257408K), 0.0288700 secs] [Times: user=0.08 sys=0.01, real=0.03 secs]
0.372: [GC0.372: [ParNew: 275668K->7062K(306688K), 0.0228070 secs] 787668K->519062K(6257408K), 0.0228580 secs] [Times: user=0.07 sys=0.00, real=0.03 secs]
0.430: [GC0.430: [ParNew: 279702K->11314K(306688K), 0.0327930 secs] 791702K->523314K(6257408K), 0.0328510 secs] [Times: user=0.08 sys=0.01, real=0.03 secs]
0.497: [GC0.497: [ParNew: 283954K->15383K(306688K), 0.0336020 secs] 795954K->527383K(6257408K), 0.0336550 secs] [Times: user=0.08 sys=0.00, real=0.03 secs]
0.565: [GC0.565: [ParNew: 288023K->21006K(306688K), 0.0282110 secs] 800023K->533006K(6257408K), 0.0282740 secs] [Times: user=0.08 sys=0.00, real=0.03 secs]
0.627: [GC0.627: [ParNew: 293646K->26805K(306688K), 0.0265270 secs] 805646K->538805K(6257408K), 0.0266220 secs] [Times: user=0.07 sys=0.01, real=0.03 secs]
0.688: [GC0.688: [ParNew: 299445K->20215K(306688K), 1.3657150 secs] 811445K->535105K(6257408K), 1.3657830 secs] [Times: user=3.97 sys=0.01, real=1.36 secs]
2.087: [GC2.087: [ParNew: 292855K->17914K(306688K), 6.6188870 secs] 807745K->535501K(6257408K), 6.6189490 secs] [Times: user=19.71 sys=0.03, real=6.61 secs]
8.741: [GC8.741: [ParNew: 290554K->17433K(306688K), 14.2495190 secs] 808141K->537744K(6257408K), 14.2495830 secs] [Times: user=42.34 sys=0.10, real=14.25 secs]
23.025: [GC23.025: [ParNew: 290073K->17315K(306688K), 21.1579920 secs] 810384K->540348K(6257408K), 21.1580510 secs] [Times: user=70.10 sys=0.08, real=21.16 secs]
44.216: [GC44.216: [ParNew: 289955K->17758K(306688K), 27.6932380 secs] 812988K->543511K(6257408K), 27.6933060 secs] [Times: user=103.91 sys=0.16, real=27.69 secs]
71.941: [GC71.941: [ParNew: 290398K->17745K(306688K), 35.1077720 secs] 816151K->546225K(6257408K), 35.1078600 secs] [Times: user=130.86 sys=0.10, real=35.11 secs]
107.081: [GC107.081: [ParNew: 290385K->21826K(306688K), 41.4425020 secs] 818865K->553022K(6257408K), 41.4425720 secs] [Times: user=158.25 sys=0.31, real=41.44 secs]
148.555: [GC148.555: [ParNew: 294466K->21834K(306688K), 45.9826660 secs] 825662K->555757K(6257408K), 45.9827260 secs] [Times: user=180.91 sys=0.14, real=45.98 secs]
194.570: [GC194.570: [ParNew: 294474K->21836K(306688K), 51.5779770 secs] 828397K->558485K(6257408K), 51.5780450 secs] [Times: user=204.05 sys=0.20, real=51.58 secs]
246.180: [GC246.180: [ParNew^C: 294476K->18454K(306688K), 58.9307800 secs] 831125K->557829K(6257408K), 58.9308660 secs] [Times: user=232.31 sys=0.23, real=58.93 secs]
Heap
par new generation   total 306688K, used 40308K [0x000000067ae00000, 0x000000068fac0000, 0x000000068fac0000)
   eden space 272640K,   8% used [0x000000067ae00000, 0x000000067c357980, 0x000000068b840000)
   from space 34048K, 54% used [0x000000068b840000, 0x000000068ca458f8, 0x000000068d980000)
   to   space 34048K,   0% used [0x000000068d980000, 0x000000068d980000, 0x000000068fac0000)
concurrent mark-sweep generation total 5950720K, used 539375K [0x000000068fac0000, 0x00000007fae00000, 0x00000007fae00000)
concurrent-mark-sweep perm gen total 21248K, used 2435K [0x00000007fae00000, 0x00000007fc2c0000, 0x0000000800000000)
Good Case - 479M Static Object:
java -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Xmx6G -Xms6G LongParNewPause $((479*1024*1024)) 100 100
0.298: [GC0.298: [ParNew: 272640K->3036K(306688K), 0.0152390 secs] 763136K->493532K(6257408K), 0.0153450 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
0.346: [GC0.346: [ParNew: 275676K->7769K(306688K), 0.0193840 secs] 766172K->498265K(6257408K), 0.0194570 secs] [Times: user=0.07 sys=0.00, real=0.02 secs]
0.398: [GC0.398: [ParNew: 280409K->11314K(306688K), 0.0203460 secs] 770905K->501810K(6257408K), 0.0204080 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
0.450: [GC0.450: [ParNew: 283954K->17306K(306688K), 0.0222390 secs] 774450K->507802K(6257408K), 0.0223070 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
0.504: [GC0.504: [ParNew: 289946K->18380K(306688K), 0.0169000 secs] 780442K->508876K(6257408K), 0.0169630 secs] [Times: user=0.07 sys=0.01, real=0.02 secs]
0.552: [GC0.552: [ParNew: 291020K->26805K(306688K), 0.0203990 secs] 781516K->517301K(6257408K), 0.0204620 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
0.604: [GC0.604: [ParNew: 299445K->21153K(306688K), 0.0230980 secs] 789941K->514539K(6257408K), 0.0231610 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
0.659: [GC0.659: [ParNew: 293793K->29415K(306688K), 0.0170240 secs] 787179K->525498K(6257408K), 0.0170970 secs] [Times: user=0.07 sys=0.01, real=0.02 secs]
0.708: [GC0.708: [ParNew: 302055K->23874K(306688K), 0.0202970 secs] 798138K->522681K(6257408K), 0.0203600 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
0.759: [GC0.760: [ParNew: 296514K->26842K(306688K), 0.0238600 secs] 795321K->528371K(6257408K), 0.0239390 secs] [Times: user=0.07 sys=0.00, real=0.03 secs]
0.815: [GC0.815: [ParNew: 299482K->25343K(306688K), 0.0237580 secs] 801011K->529592K(6257408K), 0.0238030 secs] [Times: user=0.06 sys=0.01, real=0.02 secs]
0.870: [GC0.870: [ParNew: 297983K->25767K(306688K), 0.0195800 secs] 802232K->532743K(6257408K), 0.0196290 secs] [Times: user=0.07 sys=0.00, real=0.02 secs]
0.921: [GC0.921: [ParNew: 298407K->21795K(306688K), 0.0196310 secs] 805383K->531488K(6257408K), 0.0196960 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
0.972: [GC0.972: [ParNew: 294435K->25910K(306688K), 0.0242780 secs] 804128K->538329K(6257408K), 0.0243440 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
1.028: [GC1.028: [ParNew: 298550K->21834K(306688K), 0.0235000 secs] 810969K->536979K(6257408K), 0.0235600 secs] [Times: user=0.06 sys=0.00, real=0.03 secs]
1.083: [GC1.083: [ParNew: 294474K->26625K(306688K), 0.0188330 secs] 809619K->544497K(6257408K), 0.0188950 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
1.133: [GC1.133: [ParNew: 299265K->26602K(306688K), 0.0210780 secs] 817137K->547186K(6257408K), 0.0211380 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
1.185: [GC1.185: [ParNew: 299242K->26612K(306688K), 0.0236720 secs] 819826K->549922K(6257408K), 0.0237230 secs] [Times: user=0.07 sys=0.00, real=0.03 secs]
1.240: [GC1.241: [ParNew: 299252K->26615K(306688K), 0.0188560 secs] 822562K->552651K(6257408K), 0.0189150 secs] [Times: user=0.07 sys=0.00, real=0.02 secs]
1.291: [GC1.291: [ParNew: 299255K->26615K(306688K), 0.0195090 secs] 825291K->555378K(6257408K), 0.0195870 secs] [Times: user=0.07 sys=0.00, real=0.02 secs]
1.342: [GC1.342: [ParNew: 299255K->22531K(306688K), 0.0229010 secs] 828018K->554021K(6257408K), 0.0229610 secs] [Times: user=0.07 sys=0.00, real=0.02 secs]
1.396: [GC1.396: [ParNew: 295171K->24505K(306688K), 0.0265920 secs] 826661K->560810K(6257408K), 0.0266360 secs] [Times: user=0.07 sys=0.00, real=0.03 secs]
1.453: [GC1.453: [ParNew: 297145K->24529K(306688K), 0.0296490 secs] 833450K->563560K(6257408K), 0.0297070 secs] [Times: user=0.09 sys=0.00, real=0.03 secs]
1.514: [GC1.514: [ParNew: 297169K->27700K(306688K), 0.0259820 secs] 836200K->569458K(6257408K), 0.0260310 secs] [Times: user=0.07 sys=0.00, real=0.02 secs]
1.571: [GC1.572: [ParNew: 300340K->27666K(306688K), 0.0199210 secs] 842098K->572150K(6257408K), 0.0199650 secs] [Times: user=0.07 sys=0.01, real=0.02 secs]
1.623: [GC1.623: [ParNew: 300306K->27658K(306688K), 0.0237020 secs] 844790K->574868K(6257408K), 0.0237630 secs] [Times: user=0.08 sys=0.00, real=0.02 secs]
1.678: [GC1.678: [ParNew: 300298K->31737K(306688K), 0.0237820 secs] 847508K->581674K(6257408K), 0.0238530 secs] [Times: user=0.08 sys=0.00, real=0.03 secs]
1.733: [GC1.733: [ParNew: 304377K->21022K(306688K), 0.0265400 secs] 854314K->573685K(6257408K), 0.0265980 secs] [Times: user=0.08 sys=0.00, real=0.02 secs]
1.791: [GC1.791: [ParNew: 293662K->25359K(306688K), 0.0249520 secs] 846325K->580748K(6257408K), 0.0250050 secs] [Times: user=0.07 sys=0.00, real=0.02 secs]
1.847: [GC1.847: [ParNew: 297999K->19930K(306688K), 0.0195120 secs] 853388K->581179K(6257408K), 0.0195650 secs] [Times: user=0.07 sys=0.00, real=0.02 secs]
1.898: [GC1.898: [ParNew: 292570K->20318K(306688K), 0.0233960 secs] 853819K->584294K(6257408K), 0.0234650 secs] [Times: user=0.07 sys=0.00, real=0.03 secs]
1.953: [GC1.953: [ParNew: 292958K->20415K(306688K), 0.0233530 secs] 856934K->587117K(6257408K), 0.0234130 secs] [Times: user=0.07 sys=0.00, real=0.02 secs]
2.007: [GC2.007: [ParNew: 293055K->20439K(306688K), 0.0301410 secs] 859757K->589868K(6257408K), 0.0302070 secs] [Times: user=0.09 sys=0.00, real=0.03 secs]
2.068: [GC2.068: [ParNew: 293079K->20445K(306688K), 0.0289190 secs] 862508K->592600K(6257408K), 0.0289690 secs] [Times: user=0.09 sys=0.00, real=0.03 secs]
^C2.129: [GC2.129: [ParNew: 293085K->29284K(306688K), 0.0218880 secs] 865240K->604166K(6257408K), 0.0219350 secs] [Times: user=0.09 sys=0.00, real=0.02 secs]
Heap
par new generation   total 306688K, used 40135K [0x000000067ae00000, 0x000000068fac0000, 0x000000068fac0000)
   eden space 272640K,   3% used [0x000000067ae00000, 0x000000067b898a78, 0x000000068b840000)
   from space 34048K, 86% used [0x000000068d980000, 0x000000068f619320, 0x000000068fac0000)
   to   space 34048K,   0% used [0x000000068b840000, 0x000000068b840000, 0x000000068d980000)
concurrent mark-sweep generation total 5950720K, used 574881K [0x000000068fac0000, 0x00000007fae00000, 0x00000007fae00000)
concurrent-mark-sweep perm gen total 21248K, used 2435K [0x00000007fae00000, 0x00000007fc2c0000, 0x0000000800000000)

After doing a Google search, I click on a link and go to the searched web page. When I go back to the Google page using the back button the links I originally clicked on no longer show as "greyed out". Any idea what is going on with the browser?

After doing a Google search, I click on a link and go to the searched web page. When I go back to the Google page using the back button the links I originally clicked on no longer show as "greyed out". Any idea what is going on with the browser?

Type '''about:config''' in the Location (address) bar and press the "Enter" key. When you see a warning, click '''I'll be careful, I promise!''' button.
* Preferences that have been modified are shown as '''bold (user set)'''.
* Preferences can be '''Reset to the default''' or changed via the right-click context menu.
-> In the '''Filter bar''', type '''browser.sessionhistory.max_entries'''
* Right click the preference '''browser.sessionhistory.max_entries''' and click '''Modify'''
* Change value from 0 to whatever you want over 0 (Default value is 50)
* click OK
-> Close the '''about:config''' tab and then Restart Firefox.
See this post:
* https://support.mozilla.com/en-US/questions/860894#answer-229574
Check and tell if its working.

HT1455 I have started my computer in safe mode as recommended but not long after the grey Apple icon appears with the spinning gear it automatically shuts down! any suggestions?

I have started my computer in safe mode as recommended but not long after the grey Apple icon appears with the spinning gear it automatically shuts down! any suggestions?

Try these options:
Credit Kappy.
This support article addresses a 'blue scree';
http://support.apple.com/kb/PH7212
Ciao.

Notiifcation Long text not grey out

Guru
I have seen the Notification Long text screen grey out once the user saves and log out. When next user enters he wil not b able to chnage the contents entered by previous user.
This is not actually hapening in my case...The screen and info entered doesnt grey out and the user can change it easily with no change documents generated,
Please help me achieve this. I need the field to be grey out once it is enterd and user has loggeds out. System shoud show the log-in user name and time when saved.
Please reply soon..

Hello
Please check in spro
Plant Maintenance and Customer Service>Maintenance and Service Processing>Maintenance and Service Notifications>Notification Creation>Notification Types-->Define Long Text Control for Notification Types
Check the below Check Box is Marked for That notification type
Log Line
No Text Change change
If above setting is already done then run Notication Transction again go in long text of Notification then after that Run transction code SU53 check your authorisation weather you have right authorisation obejct assign to you.
Regards,
Rakesh

Why is there a strange grey object on the top left corner of my iPhone?I have included a photo

Why is there a strange grey object on the top left corner of my iPhone? I have included a photo. It randomly appears and disappears.

Hey Scott! Like I said, I thought I had done some damage -- even though the drop was just a couple of inches that was my very first thought, but when it came and went with which app I was in (or not) I knew it wasn't a damaged SCREEN. So I wondered if it was a different damaged part, memory or some such.
When I saw that others had the exact same shape, I could only imagine that perhaps the phone was indicating it was running a diagnostic, had been forcefully dropped, had a faulty/damaged accelerometer or some other purposeful object. It clearly wasn't random, it was a definite shape.
Hey Paul! I'm hoping they've seen the issue and tried replacing a few parts or something... Ya never know. As a (mostly) retired guy I have the time!
I also mentioned in a kind of oblique way that I had enabled the Kanji keyboard. I should also mention that I have the field strength test enabled so that I am able to see the -db numbers instead of the antenna bars. That's right in the same area, so it could be related.... maybe... or not. The screen was unlocked when this happened and I'm guessing I pushed a whole lotta buttons and/or icons as I was grabbing at it... I wonder if it is possibly an easter egg of some sort -- just the right combo of touches. Then again, it bounced right on THAT corner... LOL
That's the only stuff I've ever done to the phone. It's never been jailbroken or anything like that. It has taken a few falls in its lifetime but none resulting in any obvious damage.
It's a 32GB iPhone 3Gs and it is now 2 years old (bought June 27, 2009.) I'm just happy that it seems to be OK. While Apple's stock may be the largest market cap in the US, my portfolio sure isn't.

Upgraded from XI 3.0 to Pi.711 - greyed object

Hi,
we just upgraded from XI 3.0 to PI 7.11, in the scenario view i have now some greyed out object, when do a double click on them i'm getting the information that this object is not present.
Why do these non-existant objects are now shown, and how gan i get rid of them? i tried to delete them, but still i'm getting the message that they are not in existance..
Are these some kind of left overs? Entries in the scenarion table with no relationship to anything else?

Hi Rainer,
Check this thread: Not able to edit mapings in PI 7.1 after upgrade
Thanks,

Long GC pauses due to 'wb processing'

Hi all,
I'm in the process of evaluating/optimizing JRockit for a standalone application we're developing with a really large heap (around 40GB), and after reading about EVERY guide and forum thread there is about GC tuning I think I got a pretty good understanding about whats going on in the JVM. But there's still one thing thats killing me and I cant seem to find a single mention of it anywhere, and thats 'wb processing' which happens during old collections while all threads are stopped, even with concurrent garbage collector. E.g.
[INFO ][gcpause] (pause includes wb processing: 4142.326 ms, compaction: 6.892 ms (external), update ref: 0.002 ms)
Most of the time the pauses are fine, maybe 100-200ms which is totally ok, but there are occasional spikes that take up several seconds (I've seen up to 15s), and since I'm trying to optimize for pausetime thats really, really bad.
Now before I start going into details of our application and start doing JRA recordings or sending you logs and stuff: could you maybe tell me whats exactly happening during that phase? Is that a common problem or is it normal behaviour? And can it be avoided somehow?
Any help is appreciated.
Regards,
Matthias

When it comes to the stopping of Java threads there are usually one of two things that is the problem:
1) Roll forwarding takes too long. This is at least easy to debug. Run with -Xverbose:thread=debug. You might get debug info saying:
Thread X (NAME) stopped roll forwarding (5 times, rfLimit: 100), will sleep and try again.
This is not a problem. However, if you see the info-level output saying
Thread X (NAME) stopped roll forwarding (100 times, rfLimit: 100), will do unlimited roll forwarding
Then you probably have a problem. What happens is that if we roll forward too long without finding a safe place to stop a Java thread, we release the thread, let it run for a short while and then try to stop it again. We do this a maximum of 100 times, then we do unlimited roll forwarding. If this happen, we can roll forward for a very long time.
The solution for this is to run with the flag "-XXrollforwardretrylimit:-1". This will allow us to bail from a roll forward unlimited amount of times without falling back to unlimited roll forwarding.
2) The other common problem with stopping of Java threads is that the application is blocking signals. JRockit is using signals to stop threads, but some operations stops signals on an OS level. The most common of these operations is reading and writing to a NFS share. This is a linux limitation.
To debug this, I would suggest taking a JRA recording with Latency data (see http://download.oracle.com/docs/cd/E13188_01/jrockit/geninfo/diagnos/intromiscon.html#wp1077578). This will show file io events, and you can search for long latencies there.

Long GC pauses; full gc eventually takes 30 secs. (from Developer Forums)

from http://forum.java.sun.com/thread.jspa?threadID=5145522
jre 1.5.0_06,
-Dcom.sun.management.jmxremote -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution -XX:NewRatio=3 -XX:MaxTenuringThreshold=3 -XX:NewSize=90M -XX:MaxNewSize=90M -Xmx800M
windows 2003 server
normally, full gc's occur with < 1 second durations, but eventually, the duration peaks at 30 seconds, then 7 seconds, then back to normal
the heap was at about 290MB (far from full).
setting maxgcpausemillis has no effect (something extraordinary happens?)
there is no obvious pattern in the long pauses (not due to perm resizing or so)
does anyone have experience with sudden long pauses?
we could think of heap being swapped - but we don't know how to monitor this (and nobody was starting memory consuming applications at the time)
does anyone know how we best monitor swapping on a windows?
we are not able to use CMS immediately without testing for a period (had crashes due to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6386633)
here are samples of long pauses
here are some long pauses (days apart - the gc log is embedded in our own loggings)
061221 102753 0750 EV coreservice.taskoutput.container 75.537: [GC [PSYoungGen: 70133K->19827K(53632K)] 173056K->138149K(172736K), 11.5205585 secs] ##[
070301 122542 0812 EV coreservice.taskoutput.container 6146.116: [Full GC [PSYoungGen: 768K->0K(90944K)] [PSOldGen: 286976K->213826K(259328K)] 287744K->213826K(350272K) [PSPermGen: 19432K->19432K(23040K)], 30.1171480 secs] ##[
070305 163701 0140 EV coreservice.taskoutput.container [PSYoungGen: 1256K->0K(90176K)] [PSOldGen: 239309K->197132K(221632K)] 240565K->197132K(311808K) [PSPermGen: 19260K->19039K(23808K)], 20.3872070 secs] ##[
tak!
/aksel

does anyone know how we best monitor swapping on awindows?I not sure if this is the best.
You can use ctrl-shift-escape. Click on the processes tab and then goto the menu: View->Select Columns... and add "Page Fault Delta" column. I would also suggest you add the VM Memory size column too.

Extremely long GC pauses

Hi,
We're running the following cluster on a single machine:
- 2 x extend nodes running at 1Gb
     - 6 x storage nodes running at 2Gb
     - Coherence 3.6.1
     - Java 6u16
After a period of about 20 hours use we see massive GC pauses of between 246 and 1440 seconds in the storage enabled nodes with messages including "concurrent mode failure" and "promotion failed".
Is anyone able to advise which of the the many GC parameters we should be using for a simple cluster such as ours?
Thanks
Richard

Here is an extract of the GC log from the extend node:
2012-01-18 20:19:16.136/23277.871 Oracle Coherence GE 3.6.1.0 <D5> (thread=Cluster, member=1): Service guardian is 13187ms late, indicating that this JVM may be running slowly or experienced a long GC
2012-01-18T20:19:16.417+0100: [GC Before GC:
Statistics for BinaryTreeDictionary:
Total Free Space: 39786722
Max   Chunk Size: 5166196
Number of Blocks: 1323
Av. Block Size: 30073
Tree      Height: 29
Before GC:
Statistics for BinaryTreeDictionary:
Total Free Space: 49152
Max   Chunk Size: 49152
Number of Blocks: 1
Av. Block Size: 49152
Tree      Height: 1
[ParNew
Desired survivor size 6684672 bytes, new threshold 1 (max 4)
- age   1:   13317624 bytes,   13317624 total
: 118016K->13056K(118016K), 29.7267156 secs] 603664K->577106K(1035520K)After GC:
Statistics for BinaryTreeDictionary:
Total Free Space: 30371405
Max Chunk Size: 5166196
Number of Blocks: 768
Av. Block Size: 39546
Tree Height: 28
After GC:
Statistics for BinaryTreeDictionary:
Total Free Space: 49152
Max Chunk Size: 49152
Number of Blocks: 1
Av. Block Size: 49152
Tree Height: 1
, 29.7272082 secs] [Times: user=0.84 sys=0.34, real=29.73 secs]
2012-01-18 20:19:46.151/23307.886 Oracle Coherence GE 3.6.1.0 <D5> (thread=Cluster, member=1): Service guardian is 25015ms late, indicating that this JVM may be running slowly or experienced a long GC
2012-01-18T20:19:46.526+0100: [GC Before GC:
Statistics for BinaryTreeDictionary:
Total Free Space: 30371405
Max   Chunk Size: 5166196
Number of Blocks: 768
Av. Block Size: 39546
Tree      Height: 28
Before GC:
Statistics for BinaryTreeDictionary:
Total Free Space: 49152
Max   Chunk Size: 49152
Number of Blocks: 1
Av. Block Size: 49152
Tree      Height: 1
[ParNew
Desired survivor size 6684672 bytes, new threshold 1 (max 4)
- age   1:   13336344 bytes,   13336344 total
: 118016K->13056K(118016K), 28.6324107 secs] 682066K->651460K(1035520K)After GC:
Statistics for BinaryTreeDictionary:
Total Free Space: 21568859
Max Chunk Size: 5166196
Number of Blocks: 383
Av. Block Size: 56315
Tree Height: 20
After GC:
Statistics for BinaryTreeDictionary:
Total Free Space: 49152
Max Chunk Size: 49152
Number of Blocks: 1
Av. Block Size: 49152
Tree Height: 1
, 28.6328374 secs] [Times: user=6.59 sys=0.27, real=28.62 secs]
2012-01-18 20:20:15.149/23336.884 Oracle Coherence GE 3.6.1.0 <D5> (thread=Cluster, member=1): Service guardian is 23998ms late, indicating that this JVM may be running slowly or experienced a long GC

June 2009 15" MBP - 5400 Hitachi Drive - Long BeachBall Pauses

I've got a new late June Unibody 15" MBP with a 5400 rpm Hitachi drive and 4Gb RAM and I periodically experience long (30 or so second) freezes.
I suspected (and continue to suspect) Safari 4. It seems that this pause always happens while I am in Safari. When it happens it always freezes iTunes output. Sometimes other windows (like terminal or mail are fine, sometimes they are frozen.)
When these happen, I see no CPU load. I've started monitoring iostat to see if any i/o is going on and I see i/o go to zero when the freeze occurs. (I have an external drive attached for time machine, but in the example below it wasn't actively doing anything.)
disk0 disk2 cpu load average
KB/t tps MB/s KB/t tps MB/s us sy id 1m 5m 15m
49.77 14 0.68 0.00 0 0.00 12 12 76 0.48 0.48 0.42
12.34 28 0.33 0.00 0 0.00 10 10 80 0.41 0.46 0.42
14.43 91 1.28 0.00 0 0.00 18 12 71 0.43 0.46 0.42
17.96 35 0.61 0.00 0 0.00 12 11 77 0.83 0.55 0.45
11.87 44 0.52 0.00 0 0.00 13 11 76 0.71 0.53 0.44
7.87 297 2.28 0.00 0 0.00 13 12 75 0.82 0.56 0.45
*0.00 0 0.00* 0.00 0 0.00 12 11 77 0.77 0.56 0.45 (iTunes is frozen during these samples)
*0.00 0 0.00* 0.00 0 0.00 3 8 89 0.65 0.54 0.45
86.55 2 0.19 0.00 0 0.00 5 9 86 0.55 0.52 0.44
I've noticed that it occurs more often when I use my higher power GPU.
I've tried resetting Safari and disabling top sites (although I haven't been successful at that.) I've also reinstalled Safari.
Any ideas?
Thanks,
John

It does appear that I am running that update. From System Profile:
Hardware Overview:
Model Name: MacBook Pro
Model Identifier: MacBookPro5,3
Processor Name: Intel Core 2 Duo
Processor Speed: 2.8 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache: 6 MB
Memory: 4 GB
Bus Speed: 1.07 GHz
Boot ROM Version: MBP53.00AC.B03
SMC Version (system): 1.48f2
Serial Number (system): W89236DU644
Hardware UUID: B06E8157-1F18-5D8B-AC83-6D515B508B3B
Sudden Motion Sensor:
State: Enabled
Thanks,
John

Does Best Buy have a: Defined Mission Statement? Defined Vision? Long Term/Short term objectives?

Does best buy have, in terms of as a company: A Defined Mission Statement? A Defined Vision? A long Term and/or Short Term Objective? This is for a senior level college report. I could not find anything on your official website. Please ignore the category. It was chosen at random. Thank you

Hi Tomas,
Best Buy doesn't have an official mission statement per se, but you can learn about our Customer Promise by visiting our Community Relations site:
http://www.bby.com/about-best-buy/
This site also has information on our giving partnerships, national and community grant programs, and links to both our quarterly and annual earnings reports.
I hope this helps!
Aaron|Social Media Specialist | Best Buy® Corporate
Private Message

Long GC pauses; full gc eventually takes 30 seconds+

jre 1.5.0_06,
-Dcom.sun.management.jmxremote -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution -XX:NewRatio=3 -XX:MaxTenuringThreshold=3 -XX:NewSize=90M -XX:MaxNewSize=90M -Xmx800M
normally, full gc's occur with < 1 second durations, but eventually, the duration peaks at 30 seconds, then 7 seconds, then back to normal
the heap was at about 290MB (far from full).
setting maxgcpausemillis has no effect (something extraordinary happens?)
there is no obvious pattern in the long pauses (not due to perm resizing or so)
does anyone have experience with sudden long pauses?
we could think of heap being swapped - but we don't know how to monitor this (and nobody was starting memory consuming applications at the time)
tak!
/aksel

EDIT: Also I think NewSize/MaxNewSize should be set to the same value as NewRatio (fourth of the heap)yes - there is some confusion there.. the 90MB is used by the vm though
unfortunately we are not able to try out the cms immediately (as we are in production) - and even if this might be the end, we have to test the cms for a long time before entering production. we were hit by crashes caused by cms a year ago when we decided not to use it (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6386633)
here are some long pauses (days apart - the gc log is embedded in our own loggings)
061221 102753 0750 EV coreservice.taskoutput.container 75.537: [GC [PSYoungGen: 70133K->19827K(53632K)] 173056K->138149K(172736K), 11.5205585 secs] ##[
070301 122542 0812 EV coreservice.taskoutput.container 6146.116: [Full GC [PSYoungGen: 768K->0K(90944K)] [PSOldGen: 286976K->213826K(259328K)] 287744K->213826K(350272K) [PSPermGen: 19432K->19432K(23040K)], 30.1171480 secs] ##[
070305 163701 0140 EV coreservice.taskoutput.container [PSYoungGen: 1256K->0K(90176K)] [PSOldGen: 239309K->197132K(221632K)] 240565K->197132K(311808K) [PSPermGen: 19260K->19039K(23808K)], 20.3872070 secs] ##[

Extremely long build times using object oriented code

We have a LabVIEW application that we need to build an .exe for distrubution purposes. The application relies on several object-oriented classes for data handling and dynamic dispatch type casting and function selection. Currently it takes approximately 1.5 hours to build the application and it seems that most of the time is spent processing the object oriented files. Has anyone else seen this issue and are there any creative ways to improve the build times?

Hi again. We are still having issues using LVOOP due to extrmely long .exe build times as well as long labview loading times. I traced the source of this to one class hierarchy, shown below. This hierarchy also relies heavily on overriding top-level functions, declared as virtual VIs in the top level class, which I suspect contributes to this problem. While debugging another issue, I was trying to build a small piece of my main code into an .exe to verify its functionality and experienced the same extremely long build times. When I removed this class hierarchy from the VI, it built extremely fast. Also to be clear, I am using neither the mean function or Mean.vi anywhere in this set of code. To date we have been delighted with LVOOP and how it has made our code cleaner, mroe robust, and more maintanable. However, when creating new functionality in the code we often elect NOT to create new objects (even though they would be beneficial) because we are hesitant to introduce the extra time (load and build) required for LabVIEW to handle these classes. If our entire system was rewritten in LVOOP, I would suspect that it would become unmaintainable and unbuildable due to the LVOOP overhead. I was hoping that LV2009 would address some of these issues but, alas, it did not. Still looking for a way to improve this and thanks in advance for all of the replies.

Long GC pause - grey object rescan

Similar Messages

Maybe you are looking for