JVM - Survivor Space fills up to max

We have run into an issue, where the survivor space fills up to the max pretty quickly, and things start running very slowly as the day progresses.
We are using jdk1.6.0_16, and here's the JVM parameters the server runs with:
-Xms12g -Xmx50g -XX:MaxNewSize=8g -XX:NewSize=4g -XX:SurvivorRatio=6 -XX:MaxPermSize=128M
Here's how it looked like at one point:
Attribute
Max Value(MB)
Committed(MB)
Initial(MB)
Used(MB)
Heap Memory
50176
15980
12288
6392
12
Eden Space
7389
3072
7389
1872
25
Survivor Space
399
512
399
399
99
Tenured Gen
43008
8192
8192
4120
9
Non Heap Memory
176
132
23
111
63
Perm Gen
128
20
110
88
69
I'm not really sure if it's the survivor space that's causing the slowness or nor, but if so, what should I set it to, to get better performance? Or, can I just get rid of it, and let the system handle it.
Any assistance/insight would be very much appreciated.

Profiling the application with data that represents real traffic is the way to determine performance bottlenecks.
If memory is actually an issue then reducing it will make the error occur more quickly, but again one should do that while profiling.

Similar Messages

  • Default GC/ empty survivor space

    I have a web application running on Solaris 8 using JDK 1.5.0_11 on a 64-bit OS. I am uncertain as to what GC algorithm I am using by default; my machine is a server-class machine, as defined by Sun, with 4 processors and 4G of RAM. I have read things that say that the concurrent mark sweep collector is used by default on this machine, as well as others that say that this option MUST be specified to be used. Which is it?
    On this same machine, I have observed that if I specify these parameters
    -server
    -d64
    -Xms2304m
    -Xmx2304m
    -verbose:gc
    -Xloggc:<path to file>
    -XX:+HeapDumpOnOutOfMemoryError
    -XX:+CMSClassUnloadingEnabled
    -XX:+CMSPermGenSweepingEnabled
    -XX:+PrintGCDetails
    -XX:+PrintGCTimeStamps
    according to Jconsole, the "old" generation is empty (never filled). If I indeed do specify -XX:+UseConcMarkSweep, Jconsole shows the survivor space as never being filled. This would suggest that unless I specify -XX:+UseConcMarkSweepGC, the concurrent collector won't be used. Is that correct?
    Why is it that either the old generation or the survivor space is never filled? What does that indicate? Is/are there other parameters that I should be setting?
    Thanks!

    Hi,
    CMS is never selected as the default collector. You have to explicitly specify -XX:+UseConcMarkSweepGC to use it.
    The default collector for server class machines is the parallel collector:
    The following changes take effect with J2SE 5.0.
    1. On server-class machines running the server VM, the garbage collector (GC) has changed from the previous serial collector (-XX:+UseSerialGC) to a parallel collector (-XX:+UseParallelGC). You can override this default by using the -XX:+UseSerialGC command-line option to the java command.
    [http://java.sun.com/j2se/1.5.0/docs/guide/vm/gc-ergonomics.html]
    Not seing your old generation being filled is quite unusual. Are you sure you are running your application long enough? All your objects are always allocated in eden. At each young garbage collection cycle, the surviving objects are copied between the survivor spaces. If they have been copied MaxTenuringThreshold times (can be specified explicitly, the default is somehow object to ergonomics), they tenure into the old generation. If you just run your application for a short time, you might never see this happen.
    With CMS, the survivor spaces should be used at each young gc cycle for the objects surviving the gc, unless you specify -XX:MaxTenuringThreshold=0.
    Also see http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html for more details.
    Nick.

  • Can you alter the JVM heap space size for all Windows users?

    Hi,
    I have used the "-Xmx" option to increase the Java Heap space for my Java application. This works fine, but all other users on my system still have the default heap space setting and I want them to have use an increased heap space as well. I cannot alter the JVM heap space at the command line since our Java application is started via an ActiveX bridge from a Windows application.
    So far I have found one potential, but not really good solution; I have figured out that I can copy the deployment.properties file containing the altered JVM heap setting from the "Application Data\Sun\Java\Deployment" folder in my own Windows "Documents and Settings" folder to the same folder of another user. However, this is not a really good solution since we are running a system with about 60 users and often new user accounts are created and sometimes people forget to copy the deployment.properties file.
    Does anyone know a better solution. I've tried to search the Windows registry or the JRE files for a default JVM heap space setting but I can't find it anywhere. Still on some systems the default is 64Mb and on others 96Mb, so I guess there must be a setting somewhere?

    The following is my eclipse.ini:
    -vmargs
    -Xms256m
    -Xmx512m
    -Dfuego.fstudio=true
    -DprodMode=preProduction
    -Dbea.home=C:\bea\albpm6.0\studio\..
    -Djava.endorsed.dirs=""
    -XX:PermSize=256M
    -XX:MaxNewSize=256M
    -XX:MaxPermSize=1024M
    but i think this configuration just effect the eclipse, not embed bpm engine. I also change the engine preference, increase the heap size, but engine crash as before.
    I want to change the jvm from jdk to jrockit, i hope any suggest.

  • Reading in a space filled file

    I am reading in a file which is in byte format and each record is 50 chars wide and space-filled. If an element is not present in the file, then it is just space filled.
    Example input.prn file:
    Bob ����� Smith�����12 North Rd�����Denver�����CO�����USA�����12435
    John �� Williams�����123 State St�����New York�����NY����������12435
    Notice in the second record, that John Williams does not have a country. It is just space-filled (50 chars).
    So I need to read in this file, and send it to a constructor in this format:
    Bob,Smith,12 North Rd,Denver,CO,USA,12435
    John,Williams,123 State St,New York,NY,,12435
    in the second record where there was no country, a "," needs to be in it's place.
           BufferedReader br = new BufferedReader(new FileReader("input.prn"));
           String line = " ";
           // the delim needs to be space filled somehow
               while((line = br.readLine()) != null)
                    StringTokenizer st = new StringTokenizer(line,delim);
               }I'm not sure how to approach this problem. Any help would be greatly appreciated.
    thank you

                while ((len = br.read(data, 0, data.length)) != -1 ) {
                    //You do now have len characters available in the data.
                     line = new String(data, 0, data.length);
                     String firstName = line.substring(0,10) + ",";
                     String lastName = line.substring(10,27) + ",";
                     String startDate = line.substring(27,35) + ",";
                     String address1 = line.substring(35,45) + ",";
                     String address2 = line.substring(45,55) + ",";
                     String city = line.substring(55,65) + ",";
                     String state = line.substring(65,67) + ",";
                     String country = line.substring(67,70) + ",";
                     String zip = line.substring(70,80);
                     String record = firstName+lastName+startDate+address1+address2+city
                                              +state+country+zip;
                                                  System.out.println(record.toString());
                                      }If I add the + "," onto the String values to output comma-seperated values, the results for the second record appear incorrectly as below:
    Bob ,Smith ,20051018,12 North Rd ,Apt 1 ,Miami ,FL,usa,87782
    Tom
    Jon,es 200,307308 S,tate St Apt, 12 Boi,se IDu,sa,112,35
    Tom
    The output for the first record of Bob Smith is absolutely correct, but the record for Tom Jones is not. All of the commas are misplaced.

  • Message Mapping using Left justified, right blank/space filled

    Hi,
    My Interface is outbound Interface.
    Suppose source field named 'Filename' is mapped with Target field named 'Filename'.Condition is AS IS(Left justified, right blank/space filled).
    How should i do this mapping?

    Hi Sanghamitra Duttagupta,
                                                you can try this UDF below
    public static String fieldJustified(String s)
              try
                   final int fieldLength=20;
                   char filler=' ';
                   s=s.trim();
                   int l=s.length();
                   while(l<fieldLength)
                        s=s+filler;
                        l++;
              catch(Exception e)
                   return s;
              return s;
    Please reset the value of the variable "fieldLength",  in code above to the field length as per your need. The right side will be filled with extra spaces since value of "filler" variable is ' '. you can set this to any character of your choice so that total field length is equal to value of variable "fieldLength" (which is 20 here).
    so if input is  "        hi"
    output           "hi                  "
    regards
    Anupam
    Edited by: anupamsap on Aug 1, 2011 1:53 PM

  • Hi, will my downloadable PDF forms look exactly the same as when I upload but with spaces filled in?

    Hi, will my downloadable PDF forms look exactly the same as when I upload but with spaces filled in?

    Not sure I understand the question. Are you talking about the "Download Response as PDF" feature (to see the PDF filled out with the filler's data) or the "Download Submission Enabled PDF" (to sent to people to fill out)?
    If you imported a PDF in FormsCentral, the Submission Enabled PDF will look exactly the same as the imported PDF plus a submit button
    If you designed the form in FormsCentral and save the Submission Enabled PDF it will look very similar to the web form (switch the view in the Design Tab to Page View to see what the PDF will look like)
    The PDF doesn't use skip logic or show/hide logic so this mean that the PDF always shows all the form elements
    I answered a similar question today. See http://forums.adobe.com/thread/1251981
    Gen

  • How to know the disk space -(filled and not filled) in Macbook pro?

    How to know the disk space -(filled and not filled) in Macbook pro? what is the easiest way to know about it? how can i know a % of disk space that is filled in my mac book pro (2012 model MD101)

    Hi ...
    What's taking up disk space >  OSX Tips The Storage Display
    Click your Apple menu  top left in your screen. From the drop down menu click About This Mac > More Info > Storage
    Make sure there's at least 15% free disk space.

  • Survivor Space is always full and causes Full GC

    Hi, Gurus,
    I got full GCs on the server today and when I used jstat to look at it, it quite surprised me that survivor space was always full.
    Eden had about 40M free, Old Gen had about 1G free. Permant space looks fine. I don't see why there should be Full GC.
    S0C S1C S0U S1U EC EU OC OU PC PU {color:#ff0000}YGC{color} YGCT {color:#ff0000}FGC{color} FGCT GCT
    17024.0 17024.0 0.0 {color:#ff0000}17024.{color}0 136320.0 97397.6 2424448.0 983664.4 83760.0 50162.0 2389 141.766 {color:#ff0000}1182{color} 57.500 199.266
    S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT
    17024.0 17024.0 0.0 {color:#ff0000}17024.0{color} 136320.0 97479.5 2424448.0 983664.4 83760.0 50162.0 2389 141.766 {color:#ff0000}1182 {color}57.500 199.266
    S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT
    17024.0 17024.0 {color:#ff0000}17024.0{color} 0.0 136320.0 86847.5 2424448.0 1254066.8 83760.0 50181.5 2406 142.381 {color:#ff0000}1183 {color}57.547 199.928
    S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT
    17024.0 17024.0 0.0 {color:#ff0000}17024.0{color} 136320.0 63901.1 2424448.0 980688.6 83760.0 50194.9 2409 142.470 {color:#ff0000}1184 {color}57.629 200.099
    S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT
    17024.0 17024.0 0.0 {color:#ff0000}17024.0{color} 136320.0 63978.7 2424448.0 980688.6 83760.0 50194.9 2409 142.470 1184 57.629 200.099
    S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT
    17024.0 17024.0 0.0 {color:#ff0000}17024.0{color} 136320.0 64138.8 2424448.0 980688.6 83760.0 50194.9 2409 142.470 1184 57.629 200.099
    GC setting is:
    1.6.0_02-b05-x86_64/bin/java -showversion -verbose:gc -XX:CMSInitiatingOccupancyFraction=60 -XX:CMSIncrementalDutyCycle=50 -XX:CMSIncrementalDutyCycleMin=10 -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+UseCMSCompactAtFullCollection -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Dsun.rmi.dgc.client.gcInterval=86400000 -Dsun.rmi.dgc.server.gcInterval=86400000 -Xms2534m -Xmx2534m -DLOG4J_WATCHDOG=true
    I don't know why there was no "Full GC" in the log:
    87827.250: [GC 287827.251: [ParNew: 153344K->17024K(153344K), 0.0325760 secs] 642111K->520423K(2577792K) icms_dc=10 , 0.0327100 secs]
    287827.568: [GC 287827.568: [ParNew: 153344K->17024K(153344K), 0.0260580 secs] 656743K->532347K(2577792K) icms_dc=10 , 0.0261780 secs]
    287827.823: [GC 287827.823: [ParNew: 153344K->15632K(153344K), 0.0273900 secs] 668667K->540848K(2577792K) icms_dc=10 , 0.0275110 secs]
    287828.098: [GC 287828.098: [ParNew: 151952K->17024K(153344K), 0.0304150 secs] 677168K->555053K(2577792K) icms_dc=10 , 0.0305420 secs]
    287828.403: [GC 287828.403: [ParNew: 153344K->17024K(153344K), 0.0305150 secs] 691373K->570859K(2577792K) icms_dc=10 , 0.0306520 secs]
    287828.685: [GC 287828.685: [ParNew: 153344K->17024K(153344K), 0.0379710 secs] 707179K->585425K(2577792K) icms_dc=10 , 0.0381200 secs]
    287828.985: [GC 287828.985: [ParNew: 153344K->17024K(153344K), 0.0431150 secs] 721745K->610830K(2577792K) icms_dc=10 , 0.0432430 secs]
    287829.253: [GC 287829.253: [ParNew: 153344K->17024K(153344K), 0.0345560 secs] 747150K->629754K(2577792K) icms_dc=10 , 0.0346570 secs]
    287829.551: [GC 287829.551: [ParNew: 153344K->17024K(153344K), 0.0345630 secs] 766074K->643360K(2577792K) icms_dc=10 , 0.0347040 secs]
    287829.785: [GC 287829.785: [ParNew: 153344K->17024K(153344K), 0.0347640 secs] 779680K->657564K(2577792K) icms_dc=10 , 0.0348710 secs]
    287830.046: [GC 287830.046: [ParNew: 153344K->17024K(153344K), 0.0347300 secs] 793884K->671947K(2577792K) icms_dc=10 , 0.0348460 secs]
    287830.347: [GC 287830.347: [ParNew: 153344K->17024K(153344K), 0.0375390 secs] 808267K->689272K(2577792K) icms_dc=10 , 0.0376620 secs]
    287835.620: [GC 287835.620: [ParNew: 153344K->16585K(153344K), 0.0295650 secs] 825592K->701839K(2577792K) icms_dc=10 , 0.0297360 secs]
    287841.587: [GC 287841.587: [ParNew: 152905K->15178K(153344K), 0.0240180 secs] 838159K->709028K(2577792K) icms_dc=10 , 0.0241380 secs]
    287962.309: [GC 287962.309: [ParNew: 151498K->17024K(153344K), 0.0829110 secs] 845348K->734092K(2577792K) icms_dc=10 , 0.0830450 secs]
    288325.418: [GC 288325.418: [ParNew: 153344K->17024K(153344K), 0.2753590 secs] 869434K->754338K(2577792K) icms_dc=10 , 0.2754940 secs]
    288383.372: [GC [1 CMS-initial-mark: 737314K(2424448K)] 815727K(2577792K), 0.0504460 secs]
    288383.547: [GC 288383.547: [ParNew: 153344K->17024K(153344K), 0.0361790 secs] 890658K->758050K(2577792K) icms_dc=10 , 0.0363070 secs]
    288383.800: [GC 288383.800: [ParNew: 153344K->17024K(153344K), 0.0351570 secs] 894370K->773090K(2577792K) icms_dc=10 , 0.0352870 secs]
    288384.039: [GC 288384.039: [ParNew: 153344K->17024K(153344K), 0.0304930 secs] 909410K->784697K(2577792K) icms_dc=10 , 0.0306350 secs]
    288384.323: [GC 288384.323: [ParNew: 153344K->17024K(153344K), 0.0317450 secs] 921017K->798864K(2577792K) icms_dc=10 , 0.0318700 secs]
    288384.630: [GC 288384.630: [ParNew: 153344K->17024K(153344K), 0.0366800 secs] 935184K->815969K(2577792K) icms_dc=10 , 0.0368140 secs]
    288384.852: [GC 288384.852: [ParNew: 153344K->17024K(153344K), 0.0337750 secs] 952289K->831548K(2577792K) icms_dc=10 , 0.0339080 secs]
    288385.138: [GC 288385.138: [ParNew: 153344K->16444K(153344K), 0.0300460 secs] 967868K->843332K(2577792K) icms_dc=10 , 0.0301850 secs]
    288385.403: [GC 288385.403: [ParNew: 152764K->17024K(153344K), 0.0319640 secs] 979652K->853758K(2577792K) icms_dc=10 , 0.0320770 secs]
    288385.658: [GC 288385.658: [ParNew: 153344K->17024K(153344K), 0.0295970 secs] 990078K->865590K(2577792K) icms_dc=10 , 0.0297140 secs]
    288385.947: [GC 288385.948: [ParNew: 153344K->17024K(153344K), 0.0352280 secs] 1001910K->881224K(2577792K) icms_dc=10 , 0.0353640 secs]
    288386.228: [GC 288386.228: [ParNew: 153344K->17024K(153344K), 0.0358860 secs] 1017544K->897416K(2577792K) icms_dc=10 , 0.0360310 secs]
    288386.522: [GC 288386.522: [ParNew: 153344K->17024K(153344K), 0.0505040 secs] 1033736K->920867K(2577792K) icms_dc=10 , 0.0506410 secs]
    288386.807: [GC 288386.807: [ParNew: 153344K->17024K(153344K), 0.0356400 secs] 1057187K->939937K(2577792K) icms_dc=10 , 0.0358620 secs]
    288387.088: [GC 288387.088: [ParNew: 153344K->17024K(153344K), 0.0347680 secs] 1076257K->955399K(2577792K) icms_dc=10 , 0.0348950 secs]
    288387.329: [GC 288387.329: [ParNew: 153344K->17024K(153344K), 0.0330050 secs] 1091719K->969242K(2577792K) icms_dc=10 , 0.0331310 secs]
    288387.570: [GC 288387.570: [ParNew: 153344K->17024K(153344K), 0.0357920 secs] 1105562K->982914K(2577792K) icms_dc=10 , 0.0359160 secs]
    288387.868: [GC 288387.868: [ParNew: 153344K->17024K(153344K), 0.0367610 secs] 1119234K->998638K(2577792K) icms_dc=10 , 0.0368880 secs]
    288388.512: [GC 288388.512: [ParNew: 153344K->16630K(153344K), 0.0362600 secs] 1134958K->1013366K(2577792K) icms_dc=12 , 0.0364030 secs]
    288398.870: [GC 288398.870: [ParNew: 152950K->14088K(153344K), 0.0250260 secs] 1149686K->1022215K(2577792K) icms_dc=12 , 0.0251510 secs]
    288434.572: [GC 288434.572: [ParNew: 150408K->17024K(153344K), 0.0519690 secs] 1158535K->1043752K(2577792K) icms_dc=12 , 0.0521010 secs]
    288805.656: [GC 288805.656: [ParNew: 153344K->17024K(153344K), 0.2108850 secs] 858554K->744507K(2577792K) icms_dc=10 , 0.2110200 secs]
    288999.265: [GC [1 CMS-initial-mark: 727483K(2424448K)] 806594K(2577792K), 0.0613950 secs]
    289198.629: [GC 289198.629: [ParNew: 153340K->17024K(153344K), 0.2407550 secs] 565998K->436213K(2577792K) icms_dc=10 , 0.2408970 secs]
    289394.326: [GC [1 CMS-initial-mark: 419189K(2424448K)] 498224K(2577792K), 0.0617040 secs]
    289630.132: [GC 289630.132: [ParNew: 153344K->17024K(153344K), 0.2492610 secs] 565902K->436417K(2577792K) icms_dc=10 , 0.2494310 secs]
    289798.632: [GC [1 CMS-initial-mark: 419393K(2424448K)] 497878K(2577792K), 0.0599100 secs]
    290039.842: [GC 290039.843: [ParNew: 153344K->17024K(153344K), 0.2310620 secs] 565827K->435926K(2577792K) icms_dc=10 , 0.2312040 secs]
    290210.826: [GC [1 CMS-initial-mark: 418902K(2424448K)] 498601K(2577792K), 0.0598820 secs]
    290414.495: [GC 290414.495: [ParNew: 153344K->17024K(153344K), 0.2432180 secs] 565680K->435900K(2577792K) icms_dc=10 , 0.2433510 secs]
    290644.238: [GC [1 CMS-initial-mark: 418876K(2424448K)] 498334K(2577792K), 0.0606010 secs]
    291120.210: [GC 291120.210: [ParNew: 153344K->17024K(153344K), 0.2008300 secs] 565657K->435372K(2577792K) icms_dc=10 , 0.2009970 secs]
    291164.186: [GC [1 CMS-initial-mark: 418348K(2424448K)] 496750K(2577792K), 0.0467970 secs]
    291164.359: [GC 291164.359: [ParNew: 153344K->17024K(153344K), 0.0273010 secs] 571692K->437891K(2577792K) icms_dc=10 , 0.0274210 secs]
    291164.605: [GC 291164.605: [ParNew: 153344K->17024K(153344K), 0.0372920 secs] 574211K->452665K(2577792K) icms_dc=10 , 0.0374300 secs]
    291164.860: [GC 291164.860: [ParNew: 153344K->16640K(153344K), 0.0335340 secs] 588985K->464865K(2577792K) icms_dc=10 , 0.0336600 secs]
    291165.153: [GC 291165.154: [ParNew: 152960K->17024K(153344K), 0.0331560 secs] 601185K->479410K(2577792K) icms_dc=10 , 0.0332850 secs]
    Your help is greatly appreciated.
    Jim

    The "FGC" in the jstat output could include CMS actions? If yes, that answers the later half of the question.

  • Why is my iPad storage space filling up when transferring purchases to iTunes?

    Hi there,
    Hopefully somebody can help.
    I recently bought an iPad & it's been great, but I noticed when I was Transferring my purchases from my Pad to my Mac, my iPads disk space starting filling up under the 'Other' catagory.
    Why is it doing it? Surely it shouldn't be putting anything on to my Pad?
    Now my storage space is almost full, but I have nothing on my iPad that wasn't there before.
    Thanks for your time.
    Paul

    Okay, first thing is to look at all your iTunest tab settings like music, movies, podcasts, etc... to make sure you don't have it set to automatically download new content onto the iPad.  If so, anything you've purchased on your computer will then turn around and try to load itself onto your iPad.
    The next thing would be to do a restore to factory settings and then re-sync using your most recent backup, assuming you have a good backup.  Once in a blue moon the data on the iPad can get corrupt somehow and give all kinds of false readings on how much memory is being used, etc...  The restore usually fixes it.
    Best.

  • Filesystem space filling up

    Hello, I am running a batch job of database select queries and I see the filesystem is filling up quickly although this script is not generating any files in the diretcory it is running. What else could be filling up? I am not able to trace.

    It depends on the database you are running and how it is installed (I'm guessing on FS)
    But usually, all queries that need temporary space (like sort, agregate, group by, etc...) will use temporary space in the db which is reflecting on the FS.

  • How much jvm affects space & performance of DB????

    Hi ,
    as i know , there are some objects created in system tablespace or something else in the DB after installing jvm.
    My question is how much space those object occupted and how those changes affect on the original DB ????
    Thanks
    Stephen

    If you measure the performance as the time required to allocate the initial 600 GB data file plus the time to do the load and compare that to allocating a small file and doing the load, letting the data file autoextend, it's unlikely that you'll see a noticable difference. You'll get far more variation just in moving 600 GB around than you'll lose waiting on the data file to extend. If there is a difference, allocating the entire file up front will be slightly more efficient.
    More likely, however, is that you wouldn't count the time required to allocate the initial 600 GB data file since that is something that can be done far in advance. If you don't count that time, then allocating the entire file up front will be much more efficient.
    If you may need less than 600 GB, on the other hand, allocating the entire file at once may waste some space. If that is a concern, it may make sense to compromise and allocate a 500 GB file initially (assuming that is a reasonable lower bound on the size you'll actually need) and let the file extend in 1 GB chunks. That won't be the most efficient approach and you may waste up to a GB of space but that may be a reasonable compromise.
    Justin

  • Root space filling up

    Hi
    I got a problem with my Sun E450 server. Actually the root is filling up the space. After investigation was made, i realize that the /var/tmp seems to have a file that is so large. So, i moved the file to another location to free up the space in. Just wondering:
    1. Is it normal that a Sun to have such a temporary file with that size?
    2. How was this file created? Is it by users doing transactions which created the temp file, or could it be other main reason?
    Any help would be much appreciated. Thanks.

    This would probablly be better answered in the OS forums, but look at things like:
    1. user processes
    2. patch /package files
    3. etc

  • TS1503 Why do I have so much "other" space filled up and how do I get rid of it?

    When I plug my phone into my computer my "other" field is taking up 9.3 GB of my space on my phone. How do I get rid of it?! And, what is it even??

    This indicates corrupt files.  A restore should resolve.

  • Erase free space filled my free space..help !

    I used DU erase free space on 'zero data option'
    I had 50/50% free /used space on 80 Gb int HD
    after that I had no free space ...
    I started from OSX disc, ran DU, repair disk, which fixed 2 issues but
    left 'Invalid leaf record' 'should be 13 not 2001'
    Last line ... '1 HFS volumne repaired'
    '1 volumne could not be repaired'
    This HD was NOT partioned..
    I guess DU wrote in my free space but didn't record that fact correctly ?
    It's running but slow slow
    Any idea what to do ?
    Thanks

    Do you have a full backup of your system and data? If not back up as much as you can, if you can. After that that, I would stop using it.
    You need to free up space on your hard drive to allow it run properly. Then it may be able to be repaired. But I wouldn't want to try without knowing how backed up you are, or not.
    Let us know.
    -mj
    [email protected]

  • Can someone explain what my GC is doing here?

    We have a Tomcat application that starts up and soon ends up doing nothing but Full GCs.
    Java build 1.4.2-b28
    JAVA_OPTS="-XX:+PrintGCDetails -XX:-TraceClassUnloading -verbose:gc -XX:+PrintGCTimeStamps -server -ms128m -mx512m -Djava.awt.headless=true"
    Here's a snapshot of the GC messages:
    3763.189: [GC 3763.189: [DefNew: 164480K->164480K(169600K), 0.0000477 secs]3763.189: [Tenured: 224835K->234198K(349568K), 7.1295042 secs] 389315K->234198K(519168K), 7.1299718 secs]
    3797.932: [GC 3797.932: [DefNew: 164480K->164480K(169600K), 0.0000627 secs]3797.932: [Tenured: 234198K->213404K(349568K), 9.9411877 secs] 398678K->213404K(519168K), 9.9416814 secs]
    3812.581: [GC 3812.581: [DefNew: 164480K->164480K(169600K), 0.0000565 secs]3812.581: [Tenured: 213404K->222265K(349568K), 6.5605187 secs] 377884K->222265K(519168K), 6.5609745 secs]
    3825.311: [GC 3825.311: [DefNew: 164480K->164480K(169600K), 0.0000552 secs]3825.312: [Tenured: 222265K->223176K(349568K), 7.2857512 secs] 386745K->223176K(519168K), 7.2862375 secs]
    3840.347: [GC 3840.347: [DefNew: 164480K->164480K(169600K), 0.0000531 secs]3840.348: [Tenured: 223176K->231956K(349568K), 7.2114165 secs] 387656K->231956K(519168K), 7.2118540 secs]
    3863.643: [GC 3863.644: [DefNew: 164480K->164480K(169600K), 0.0000436 secs]3863.644: [Tenured: 231956K->226878K(349568K), 9.1507566 secs] 396436K->226878K(519168K), 9.1511355 secs]
    3932.556: [GC 3932.556: [DefNew: 164480K->164480K(169600K), 0.0000452 secs]3932.556: [Tenured: 226878K->231426K(349568K), 8.2257418 secs] 391358K->231426K(519168K), 8.2261586 secs]
    3948.090: [GC 3948.090: [DefNew: 164480K->164480K(169600K), 0.0000917 secs]3948.091: [Tenured: 231426K->242666K(349568K), 7.5205790 secs] 395906K->242666K(519168K), 7.5214889 secs]
    The way I read the last one is:
    a) I have 164Mb in my New (Eden?) section.
    b) I have 349Mb virtually allocated for my Tenured, and it expanded from 231426 to 242666
    c) All said, I collected ~153MB during that sweep.
    My understanding is that when the heap is GC'd, it copies the objects from the Eden and the first survivor space to the second survivor space, but anything that doesn't fit in the second survivor space gets dumped into the Tenured space.
    At the end of the GC, the Eden space should have only a survivor space filled with data, the Eden is empty, the other survivor is empty (and ready for the next GC), and any excess is in the Tenured.
    Ideally, you continue this cycle until Tenured fills up, at which point a deeper, "full" GC is triggered, cleaning out Tenured. At the end of a Full GC, you should have one Survivor space filled with data, an empty Eden, the other Surivior empty, and the Tenured area ideally reduced.
    If the ratio of free space in Tenured is too low, the GC expands the Tenured space in anticipation of Next time.
    Is this correct?
    So, my question here is why am I never seeing simply the basic Eden GCs, rather it's always GCing Tenured? Would playing with the ratios help here? It's production, so I can't bounce the machine willy nilly play with parameters, and unfortunately I haven't found a good way to duplicate the behavior on my workstation.
    Any insight would be greatly appreciated.

    Yes, the Dropbox app is capable of playing some media.

Maybe you are looking for