Unflatten from string takes long time to execute in x64

Hi All,
I am running into an issue where "Unflatten from String" is taking enormous amout of memory n time in LV 2012 SP1 x64 to execute. I pass in a NOT flattened string to this function and it consumes ~5 Gigs of memory and takes more than 10 minutes to execute it. On x86, it executes almost instantly.
It only happens if the input is not a flattened string.
Is this a known bug?
I have attached the vi here for you to see the problem. If you run it on x64, it might take more than 10 mins to execute and your system will be in a hung state.
Ritesh
Attachments:
Flat String to Data bug.vi ‏9 KB

LVCoder wrote:
With "x64" I meant LV x64. It executes instantly on LV x86 running on Win 64 bit but on LV x64 it takes like eternity.
I know it cannot unflatten it and I want it to return an error. My actual code can receive a flattened or NOT flattened string and I have a case structure which handles different strings differently.
Be careful with that terminology, it only applies to the Windows Operating System with respect to 32-bit and 64-bit processors. There is no such thing as LabVIEW x64, or LabVIEW x86. The property terminology is LabVIEW 32-bit (the most common one, most people use, even on 64-bit OS's since it is the most fully supported), and LabVIEW 64-bit (not commonly used, doesn't have full support of all add-on modules and toolkits, and is mainly only used by people who need LabVIEW to analyze very large datasets.)

Similar Messages

Procedure takes long time to execute...

Hi all
i wrote the proxcedure but it takes long time to execute.
The INterdata table contains 300 records.
Here is the procedure:
create or replace procedure inter_filter
is
     /*v_sessionid interdata.sessionid%type;
     v_clientip interdata.clientip%type;
     v_userid interdata.userid%type;
     v_logindate interdata%type;
     v_createddate interdata%type;
     v_sourceurl interdata%type;
     v_destinationurl interdata%type;*/
     v_sessionid filter.sessionid%type;
     v_filterid filter.filterid%type;
     cursor c1 is
     select sessionid,clientip,browsertype,userid,logindate,createddate,sourceurl,destinationurl
     from interdata;
     cursor c2 is
     select sessionid,filterid
     from filter;
begin
     open c2;
     loop
          fetch c2 into v_sessionid,v_filterid;
          for i in c1 loop
               if i.sessionid = v_sessionid then
                    insert into filterdetail(filterdetailid,filterid,sourceurl,destinationurl,createddate)
                    values (filterdetail_seq.nextval,v_filterid,i.sourceurl,i.destinationurl,i.createddate);
               else
                    insert into filter (filterid,sessionid,clientip,browsertype,userid,logindate,createddate)
                    values (filter_seq.nextval,i.sessionid,i.clientip,i.browsertype,i.userid,i.logindate,i.createddate);
                    insert into filterdetail(filterdetailid,filterid,sourceurl,destinationurl,createddate)
                    values (filterdetail_seq.nextval,filter_seq.currval,i.sourceurl,i.destinationurl,i.createddate);
               end if;
          end loop;
     end loop;
     commit;
end
Please Help!
Prathamesh

i wrote the proxcedure but it takes long time to execute.Please define "long time". How long does it take? What are you expecting it to take?
The INterdata table contains 300 records.But how many records are there in the FILTER table? As this is the one you are driving off this is going to determine the length of time it takes to complete. Also, this solution inserts every row in the INTERDATA table for each row in the FILTER table - in other words, if the FILTER table has twenty rows to start with you are going to end up with 6000 rows in FILTERDETAIL. No wonder it takes a long time. Is that want you want?
Also of course, you are using PL/SQL cursors when you ought to be using set operations. Did you try the solution I posted in Re: Confusion in this scenario>>>>>>> on this topic?
Cheers, APC

How does "Unflatten From String" take a type and return a value of that type?

http://zone.ni.com/reference/en-XX/help/371361E-01/glang/unflatten_from_string/
How exactly does the "type" argument for "Unflatten From String" work? I need to create a VI that takes a type, passes it as an argument to several calls of the "Unflatten From String" function, and returns an array containing elements of the type originally passed. The "Unflatten From String" function seems to do some magic though, because the type of the "value" that it outputs changes depending on the type it is passed as input. How do I do the same magic in my VI?
Ultimately, what I need to accomplish is an unflatten-list operation. Given a type T and a byte string of length L (which contains a concatenation of T elements that are flattened to their bytes), create a VI that unflattens all the types in the string and return an array of length (L / sizeof(T)) that contains each type.
Note: performing the unflatten-list operation is trivial, but I cannot for the life of me figure out how to do it in a VI that takes a type and returns an array of the appropriate type. By the way, my data is being given to me from another source, so please don't bother suggesting that I should be flattening an array using LabVIEW's "Flatten To String" function in the first place. My data is not given in LabVIEW's array format: http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/flattened_data/
Thanks a ton!
-Wakka

Take a look at this example: You can see that the flattened string contains several bytes. The first four bytes contain the length of array (number of elements). Since the data type is U32, the next 32 bits (4 bytes) contains the value of the first element, and so on. Could you possibly use this scheme to do what you want to do? Other data types present different outputs. You would have to experiment with them.
- tbob
Inventor of the WORM Global

Why it takes long time to execute on Production than staging?

Hi Experts,
Any help apreciated on below issue.
I have one anonymous block for updating around 1 million records by joining 9 tables.
This is proceeded to production by following environments. And all env have exact equal volume of data.
development->Testing->Staging->Production.
The funny problem is while it takes 5 mins to be executed in all environments, it takes 30 mins on production.
why it happned and what can be action points for future?
Thanks
-J
==============
If the performance is that different in the different environments, one or more statements must have different query plans in the different environments. The first step would be to get the query plans and compare them to figure out which statement(s) is/are running slowly.
If there are different query plans, that implies that something is different between the environments. That could be any of
- Oracle version
- initialization parameters
- data
- object statistics
- system statistics
If you guarantee that the data is the same, I would tend to expect that the object statistics are different. How have you gathered statistics in the various environments? Can you move statistics from an environment where performance is acceptable to the environment where performance is unacceptable?
I would also recommend following the advice others have given you. You don't want to commit in a loop and you want to do as much processing in SQL as possible.
Justin
===============
Thanks Steve for your inputs.
My investigation resulted following 2 points.
There are 2 main reasons why some scripts might take longer in live than on Staging.
1: Weekend backups were running on the live server so slowing the server down allot.
2: the tables are re-orged when they are imported into staging/Dev – so the table and index layout is optimal, on live the tables and indexes are not necessarily contiguous so in order to do the same work the server will need to do many more I/O operations.
Can we have some action points to address these above issues?
I think if data can be contigous then it may help.
Best Regards
-J
===============
But before that, can you raise this in a seperate thread as there is a different issue going on in this thread?
Cheers
Sarma.
===========
Posts: 4
Registered: 08/28/06
Re: Performance issue (Oracle 10.2.0.3.0)
Posted: May 22, 2009 2:46 AM in response to: Radhakrishna Sa... Edit Reply
Hey Sarma,
Exterme aplogies to say that I don't know how to raise a new thread.
Thanks in advnce for your help.
-J
user636482
Posts: 202
Registered: 05/15/08
Re: Performance issue (Oracle 10.2.0.3.0)
Posted: May 22, 2009 2:51 AM in response to: user527345 Reply
Hi User 527345,
Please follow the steps to raise a request in this Forum.
1. Register urself.
2. Go to the forum home and select the Technolgy where do you want to rasie a request.
eg : If is related to Oracle DATAbase general then select Oracle databse general...
3. clik on post new thread
4. Give the summary of your issue.
5. then submit the issue.
please let me know if you need more information.
Thank you

Jayashree Mohanty wrote:
My investigation resulted following 2 points.
There are 2 main reasons why some scripts might take longer in live than on Staging.
1: Weekend backups were running on the live server so slowing the server down allot.
2: the tables are re-orged when they are imported into staging/Dev – so the table and index layout is optimal, on live the tables and indexes are not necessarily contiguous so in order to do the same work the server will need to do many more I/O operations.
Can we have some action points to address these above issues?
I think if data can be contigous then it may help.First , I didn't get at all what actually was that thing when you copied some part of don't know which post in your actual question? Please read this , it would help you post a proper question to get a proper answer ,
http://www.catb.org/~esr/faqs/smart-questions.html
Now, how did you come to the conclusion that the backups are actually making your query slower? What's the benchmark that you lead to this? And what's the meaning of the 2nd point , can you please explain it ?
As others have also mentioned, please post the plan of the query at boththe staging and production, that only can tell that what's going on.
HTH
Aman....

Query takes long time to execute.

Hi All,
I have one query that takes 5 minutes to execute.
The query depends on four tables.
The table IBS_WORK_BANKDATA and IBS_ORG_BANKDATA contains 25 lack records. Table IBS_CURRENCYMASTER have 250 records and IBS_CURRENCYEEXCHANGERATE have 50 records.
Out put of query contains 3500 records.
Oracle version is 9.0.1.1 and OS is windows 2003 server.
Query:
select distinct trim(wrk.bd_alcd) as ALCD, wrk.bd_typecd as TypeCD, wrk.bd_forcd as FORCD, wrk.bd_curcd as CURCD,
wrk.bd_councd as COUNCD, wrk.bd_sectcd as SECCD,
wrk.bd_matcd as MATCD, wrk.bd_c_u_cd as C_U_CD, wrk.bd_s_u_cd as S_U_CD,
0 as Org_FCBal,0 as ORG_Bal,case when wrk.bd_type='O' then wrk.bd_fc_bal else 0 end as Main_FCBal,
case when wrk.bd_type='O' then (wrk.bd_fc_bal * nvl(exchg.cer_exchangerate, 1)) else 0 end as main_Bal,
wrk.bd_rs_int,wrk.bd_rs_bal,wrk.bd_fc_int,wrk.bd_fc_bal,
' ' as TrackChangs
from ibs_work_bankdata wrk inner join ibs_org_bankdata org ON org.bd_yrqtr = wrk.bd_yrqtr and org.bd_bkcode=wrk.bd_bkcode and org.bd_forcd = wrk.bd_forcd
and wrk.BD_YRQTR=20044 and wrk.BD_BKCODE ='000'
and wrk.BD_ALCD = '51' and wrk.BD_FORCD ='IN' and wrk.BD_TYPECD = '11'
left join ibs_currencymaster curmst on curmst.cur_code = wrk.bd_curcd
left join ibs_currencyexchangerate exchg on exchg.cer_currencyid = curmst.cur_id
and exchg.cer_yearqtr = 20051 and exchg.CER_ACTIVE=1
Explain Plan:
SELECT STATEMENT, GOAL = CHOOSE               Cost=26     Cardinality=1     Bytes=157
SORT UNIQUE               Cost=26     Cardinality=1     Bytes=157
TABLE ACCESS BY INDEX ROWID     Object owner=RBI     Object name=IBS_ORG_BANKDATA     Cost=2     Cardinality=204     Bytes=2856
NESTED LOOPS               Cost=26     Cardinality=1     Bytes=157
NESTED LOOPS OUTER               Cost=24     Cardinality=1     Bytes=143
NESTED LOOPS OUTER               Cost=23     Cardinality=1     Bytes=93
TABLE ACCESS BY INDEX ROWID     Object owner=RBI     Object name=IBS_WORK_BANKDATA     Cost=22     Cardinality=1     Bytes=52
INDEX SKIP SCAN     Object owner=RBI     Object name=IBS_WORK_BANKDATA_IDX     Cost=7     Cardinality=1
TABLE ACCESS FULL     Object owner=RBI     Object name=IBS_CURRENCYMASTER     Cost=1     Cardinality=178     Bytes=7298
TABLE ACCESS FULL     Object owner=RBI     Object name=IBS_CURRENCYEXCHANGERATE     Cost=1     Cardinality=19     Bytes=950
INDEX RANGE SCAN     Object owner=RBI     Object name=IBS_ORG_BANKDATA_IDX     Cost=1     Cardinality=204
Please help me.
Thanks in advance,
Prathamesh.

Hi prathemesh,
Check whether the tables accessed by the query are recently analyzed.
Thanks,
Sathis.

Query takes long time to execute on exceptional cases

Hi Tuning Experts,
My query runs on prod db on daily basis on fixed scheduled time, out of seven days, for 1-2 exeptional days it takes 7-10 hr which takes 10-15 min on rest of the days.
I want to do RCA for it, so please help me how i can proceed. either i go with
AUTOTRACE,TKPROF, EXPLAIN PLAN or STATSPACK, which is best method to find out the real culprit.
Regards
Asif

To answer your question...
Running AUTOTRACE and EXPLAIN PLAN against the query in your development environment won't help diagnose the abnormal executions in production. Statspack is a global thing. It's a good thing to run but probably of insufficient granularity for here.
TKPROF is an anlyzing tool. You need something to analyze. Read this article on Interpreting Wait Events to find out how to set the 10046 event to gather evidence.
Cheers, APC

My view take long time

SELECT DISTINCT xxxx
TO_CHAR(TRUNC(MTRAN.DAT_TRANSACTION_MTRAN), 'YYYY') DAT_TRANSACTION_MTRAN,
NVL((SELECT DISTINCT SUM(MTRAN1.QTY_PRIMARY_MTRAN)
FROM MAM_MATERIAL_TRANSACTIONS MTRAN1
WHERE TO_CHAR(TRUNC(MTRAN1.DAT_TRANSACTION_MTRAN),
'YYYY') =
TO_CHAR(TRUNC(MTRAN.DAT_TRANSACTION_MTRAN),
'YYYY')
AND TO_CHAR(TRUNC(MTRAN1.DAT_TRANSACTION_MTRAN),
'MM') = '01'
AND MTRAN1.MTYP_TRANSACTION_TYPE_ID IN
(41, 42, 43, 44, 45)
AND MTRAN1.ITEM_ITEM_ID_FOR = MTRAN.ITEM_ITEM_ID_FOR),
0) QTY_FARVARDIN,
NVL((SELECT DISTINCT SUM(MTRAN1.QTY_PRIMARY_MTRAN)
FROM M
i have a view like above with 10 select to select on one table.
this view take long time to execute ,how could i decrese this time!

user498843 wrote:
SELECT DISTINCT xxxx
TO_CHAR(TRUNC(MTRAN.DAT_TRANSACTION_MTRAN), 'YYYY') DAT_TRANSACTION_MTRAN,
NVL((SELECT DISTINCT SUM(MTRAN1.QTY_PRIMARY_MTRAN)
FROM MAM_MATERIAL_TRANSACTIONS MTRAN1
WHERE TO_CHAR(TRUNC(MTRAN1.DAT_TRANSACTION_MTRAN),
'YYYY') =
TO_CHAR(TRUNC(MTRAN.DAT_TRANSACTION_MTRAN),
'YYYY')
AND TO_CHAR(TRUNC(MTRAN1.DAT_TRANSACTION_MTRAN),
'MM') = '01'
AND MTRAN1.MTYP_TRANSACTION_TYPE_ID IN
(41, 42, 43, 44, 45)
AND MTRAN1.ITEM_ITEM_ID_FOR = MTRAN.ITEM_ITEM_ID_FOR),
0) QTY_FARVARDIN,
NVL((SELECT DISTINCT SUM(MTRAN1.QTY_PRIMARY_MTRAN)
FROM M
i have a view like above with 10 select to select on one table.
this view take long time to execute ,how could i decrese this time!Thread: HOW TO: Post a SQL statement tuning request - template posting
HOW TO: Post a SQL statement tuning request - template posting

Oracle report formatting takes long time

hi
i am using oracle 10g Application Server 9.0.4.0.0 on Red hat linux AS 3
oracle reports are run thru JSP's
some reports take long time to execute though query in it if executed on sql plus are fast.
it is fond that that formatting is going on for those reports
what might be the reason for this??
is the data fetched first and then formatting takes place as per data??
waiting for reply
Avinash

hi
i am using oracle 10g Application Server 9.0.4.0.0 on Red hat linux AS 3
oracle reports are run thru JSP's
some reports take long time to execute though query in it if executed on sql plus are fast.
it is fond that that formatting is going on for those reports
what might be the reason for this??
is the data fetched first and then formatting takes place as per data??
waiting for reply
Avinash

Brachive takes long time to copy from one system to another

HI TO ALL,
I AM USING IBM BLADE SERVER AND CONNET TO SAN WHEN I SHEDULE BRARCIVE / BRBACKUP ON ANOTHER SERVER (ANY SERVER ) IT TAKES LONG TIME TO COPY ARCHIVE FROM ONE SYSTEM TO OTHER SYSTEM.
I AM USING DB ORACLE 9i and SAP 4.7 EXT 1.1
REGARDS,
VIKAS NAGAR

- how big are the files you copy?
- are both machines connected in the same network segment?
Markus

When I use update software from my mobile it take long time for checking update software and no thing happened to update my IOS software

When I use update software from my mobile it take long time for checking update software and no thing happened to update my IOS software

Servers have been swamped. Keep trying and be patient. Wait a few days.

Takes Long time for Data Loading.

Hi All,
Good Morning.. I am new to SDN.
Currently i am using the datasource 0CRM_SRV_PROCESS_H and it contains 225 fields. Currently i am using around 40 fields in my report.
Can i hide the remaining fields in the datasource level itself (TCODE : RSA6)
Currently data loading takes more time to load the data from PSA to ODS (ODS 1).
And also right now i am pulling some data from another ODS(ODS 2)(LookUP). It takes long time to update the data in Active data table of the ODS.
Can you please suggest how to improve the performance of dataloading on this Case.
Thanks & Regards,
Siva.

Hi....
Yes...u can hide..........just Check the hide box for those fields.......R u in BI 7.0 or BW...........whatever ........is the no of records is huge?
If so u can split the records and execute............I mean use the same IP...........just execute it with different selections.........
Check in ST04............is there are any locks or lockwaits..........if so...........Go to SM37 >> Check whether any Long running job is there or not.........then check whether that job is progressing or not............double click on the Job >> From the Job details copy the PID..............go to ST04 .....expand the node............and check whether u r able to find that PID there or not.........
Also check System log in SM21............and shortdumps in ST04........
Now to improve performance...........u can try to increase the virtual memory or servers.........if possiblr........it will increase the number of work process..........since if many jobs run at a time .then there will be no free Work prrocesses to proceed........
Regards,
Debjani......

The 0co_om_opa_6 ip in the process chains takes long time to run

Hi experts,
The 0co_om_opa_6 ip in the process chains takes long time to run around 5 hours in production
I have checked the note 382329,
-> where the indexes 1 and 4 are active
-> index 4 was not "Index does not exist in database system ORACLE"- i have assgined to " Indexes on all database systems and ran the delta load in development system, but guess there are not much data in dev it took 2-1/2 hrs to run as it was taking earlier. so didnt find much differnce in performance.
As per the note Note 549552 - CO line item extractors: performance, i have checked in the table BWOM_SETTINGS these are the settings that are there in the ECC system.
-> OLTPSOURCE - is blank
   PARAM_NAME - OBJSELSIZE
   PARAM_VALUE- is blank
-> OLTPSOURCE - is blank
   PARAM_NAME - NOTSSELECT
   PARAM_VALUE- is blank
-> OLTPSOURCE- 0CO_OM_OPA_6
   PARAM_NAME - NOBLOCKING
   PARAM_VALUE- is blank.
Could you please check if any other settings needs to be done .
Also for the IP there is selction criteris for FISCALYEAR/PERIOD from 2004-2099, also an inti is done for the same period as a result it becoming difficult for me to load for a single year.
Please suggest.

The problem was the index 4 was not active in the database level..it was recommended by the SAP team to activate it in se14..however while doing so we face few issues se14 is a very sensitive transaction should be handled carefully ... it should be activate not created.
The OBJSELSIZE in the table BWOM_SETTINGS has to be Marked 'X' to improve the quality as well as the indexe 4 should be activate at the abap level i.e in the table COEP -> INDEXES-> INDEX 4 -> Select the u201Cindex on all database systemu201D in place of u201CNo database indexu201D, once it is activated in the table abap level you can activate the same indexes in the database level.
Be very carefull while you execute it in se14 best is to use db02 to do the same , basis tend to make less mistake there.
Thanks Hope this helps ..

DSO activation in Process Chains - takes long time

Dear All,
We have included DSO activation in Process Chains. This process takes a long time to execute. We manually cancel the corresponding process in Process Overview and repeat it from chain. The chain runs daily and this issue also occurs on a daily basis.
Does anyone one of you have an idea of how to deal with this performance issue?
Regards.

Figure out in which class does your process fall in:
Class A- High Priority
Class B- Medium Priority
Class C- Least Priority
Background processes
Class A jobs
The number of work processes reserved for job class A is a subset of the number of background processes.
You should only reserve work processes for job class A if it makes sense within your system organization. Work processes reserved for class A jobs are no longer available for job classes B or C.
Set parallel processing for a specific BW process in the (variant) maintenance of the process
Call the function for setting the parallel processes.
You can call the function in the process variant maintenance of a process chain or in the process maintenance. The function call varies for the different BW processes.
For example, in the data transfer process you call the function with Goto--> Background Manager Settings.
The Settings for Parallel Processing dialog box appears
Under Number of Processes, define the maximum number of work processes that should be used to process the BW process.
If you enter 1, the BW process is processed serially.
If you enter a number greater than 1, the BW process is processed in parallel
In the Parallel Processing group frame, make the relevant settings for parallel processing in the background:
Enter a job class for defining the job priority.
The job priority defines how the jobs are distributed among the available background work processes
In the group frame Parallel Processing, you can define whether parallel processing should take place in dialog work processes or in background work processes for the processes ODSACTIVAT, ODSSID and ODSREQUDEL for the DataStore object
Transport:
The entries in tables RSBATCHPARALLEL and RSBATCHSERVER are written on a transport request of the Change and Transport System.
Edited by: ram.pch on Oct 7, 2011 9:55 PM

Taking long time to execute views

Hi All,
my query is taking long time to execute(i am using standard views in my query)
XLA_INV_AEL_GL_V , XLA_WIP_AEL_GL_V -----these standard views itself taking long time to execute ,but i need the info from this views
WHERE gjh.je_batch_id = gjb.je_batch_id AND
gjh.je_header_id = gjl.je_header_id AND
gjh.je_header_id = xlawip.je_header_id AND
gjl.je_header_id = xlawip.je_header_id AND
gjl.je_line_num = xlawip.je_line_num AND
gcc.code_combination_id = gjl.code_combination_id AND
gjl.code_combination_id = xlawip.code_combination_id AND
gjb.set_of_books_id = xlawip.set_of_books_id AND
gjh.je_source = 'Inventory' AND
gjh.je_category = 'WIP' AND
gp.period_set_name = 'Accounting' AND
gp.period_name = gjl.period_name AND
gp.period_name = gjh.period_name AND
gp.start_date +1 between to_date(startdate,'DD-MON-YY') AND
to_date(enddate,'DD-MON-YY') AND
gjh.status =nvl(lstatus,gjh.status)
Could any one help me to execute it fast?
Thanks
Madhu

[url http://forums.oracle.com/forums/thread.jspa?threadID=501834&tstart=0]When your query takes too long...

Full GC takes long time

Hello,
Since the last two weeks, we're experiencing Full GCs that take long time and block our application.
Our platform is:
Windows 2003 Server 64 bit
Tomcat 6.0.18
Java 1.6.0_u13.
Total memory: 8Gb.
-Xms4096m
-Xmx6144m
-Xss256k
Old generation: min 2,66Gb max 4,0G
Eden generation: min 1,5Gb max 2,0G
Perm generation: min 57Mb max 84Mb
Here a piece of our gc.log:
21601.266: [GC [PSYoungGen: 2009225K->6206K(1942528K)] 3913618K->1913365K(4738752K), 0.0992347 secs] [Times: user=0.16 sys=0.03, real=0.11 secs]
21611.268: [GC [PSYoungGen: 1942485K->5485K(1879040K)] 3849645K->1914490K(4675264K), 0.0986129 secs] [Times: user=0.11 sys=0.00, real=0.11 secs]
21618.350: [GC [PSYoungGen: 1879021K->12392K(2060928K)] 3788026K->1930794K(4857152K), 0.2036000 secs] [Times: user=0.14 sys=0.02, real=0.20 secs]
21624.869: [GC [PSYoungGen: 1935116K->8545K(2065600K)] 3853519K->1930702K(4861824K), 0.0924182 secs] [Times: user=0.05 sys=0.00, real=0.09 secs]
21624.961: [Full GC (System) [PSYoungGen: 8545K->0K(2065600K)] [PSOldGen: 1922156K->635750K(2796224K)] 1930702K->635750K(4861824K) [PSPermGen: 38643K->38643K(60992K)], 1.3719842 secs] [Times: user=1.09 sys=0.00, real=1.36 secs]
21634.887: [GC [PSYoungGen: 2048500K->10395K(2078912K)] 2684250K->646145K(4875136K), 0.0180670 secs] [Times: user=0.02 sys=0.05, real=0.01 secs]
21645.165: [GC [PSYoungGen: 2074007K->8120K(2003392K)] 2709758K->648930K(4799616K), 0.0176943 secs] [Times: user=0.08 sys=0.00, real=0.03 secs]
25209.938: [GC [PSYoungGen: 1760190K->7344K(1707072K)] 4127764K->2376892K(4503296K), 0.0760053 secs] [Times: user=0.11 sys=0.03, real=0.06 secs]
25218.120: [GC [PSYoungGen: 1707056K->10511K(1657728K)] 4076604K->2382964K(4453952K), 0.0704081 secs] [Times: user=0.13 sys=0.00, real=0.08 secs]
25221.680: [GC [PSYoungGen: 1657679K->5731K(1982400K)] 4030132K->2385544K(4778624K), 0.0985384 secs] [Times: user=0.20 sys=0.00, real=0.09 secs]
25226.968: [GC [PSYoungGen: 993426K->6083K(1982784K)] 3373239K->2389543K(4779008K), 0.5147901 secs] [Times: user=0.08 sys=0.00, real=0.52 secs]
25227.483: [Full GC (System) [PSYoungGen: 6083K->0K(1982784K)] [PSOldGen: 2383460K->536034K(2796224K)] 2389543K->536034K(4779008K) [PSPermGen: 39765K->38756K(58816K)], 155.4030025 secs] [Times: user=1.34 sys=0.64, real=155.39 secs]
25389.833: [GC [PSYoungGen: 1976624K->12915K(2023616K)] 2512658K->566671K(4819840K), 13.1263397 secs] [Times: user=0.11 sys=0.03, real=13.13 secs]
25405.871: [GC [PSYoungGen: 2023579K->13857K(2031552K)] 2577335K->583736K(4827776K), 3.5796784 secs] [Times: user=0.03 sys=0.00, real=3.58 secs]
25416.490: [GC [PSYoungGen: 2024544K->9059K(2074944K)] 2594423K->587581K(4871168K), 0.1184355 secs] [Times: user=0.06 sys=0.00, real=0.13 secs]
25425.393: [GC [PSYoungGen: 2064144K->7415K(2075456K)] 2642665K->590222K(4871680K), 0.0441002 secs] [Times: user=0.02 sys=0.00, real=0.05 secs]
25438.547: [GC [PSYoungGen: 2062519K->8857K(2075264K)] 2645326K->594735K(4871488K), 0.0301620 secs] [Times: user=0.01 sys=0.00, real=0.03 secs]
The minor collections go perfect.
The first full GC in this piece of log takes 1,36s, and the old generation passes from 1922156K->635750K
But the second full GC (1 hour later) blocks the server for 155.39s, and the old generation pases from 2383460K->536034K
The server load between execution of full GC was similar. Any differences I saw in this two moments:
first full gc: number of Tomcat http threads : 230. The full gc provokes that Tomcat start new threads until get 500 (maxThreads)
second full gc: number of Tomcat http threads : 500.
I'm not an expert in tunning jvm. If somebody could help me, these pauses are killing the app and it's unacceptable for my client (for 2 min. the app does not work).
If you need more information (threads stack, histograms, ... I have ...)
Maybe I need to reduce the size of the old generation? Or change the garbage collector for old generation? The server cpu is going well, I prefer to consume more cpu in gc and avoid this pauses.
Any help will be very very appreciated.
Thanks in advance,
Joan.

Hello,
Sorry for my continuous replies. Another full gc has occurred. This is the trace:
262631.531: [GC [PSYoungGen: 2071685K->10889K(2078464K)] 4711353K->2652961K(4874688K), 0.3392037 secs] [Times: user=0.08 sys=0.00, real=0.34 secs]
262640.608: [GC [PSYoungGen: 2071978K->11055K(2078784K)] 4714051K->2656136K(4875008K), 1.3267436 secs] [Times: user=0.06 sys=0.00, real=1.33 secs]
262649.880: [GC [PSYoungGen: 2072165K->17337K(2071872K)] 4717246K->2669454K(4868096K), 3.0493937 secs] [Times: user=0.16 sys=0.00, real=3.05 secs]
262658.069: [GC [PSYoungGen: 2071865K->14678K(2075840K)] 4723982K->2676078K(4872064K), 5.4598301 secs] [Times: user=0.08 sys=0.03, real=5.45 secs]
262666.592: [GC [PSYoungGen: 2069183K->15835K(2075776K)] 4730583K->2682691K(4872000K), 1.6894894 secs] [Times: user=0.11 sys=0.05, real=1.70 secs]
262673.352: [GC [PSYoungGen: 2070620K->14122K(2068992K)] 4737476K->2687230K(4865216K), 2.9711981 secs] [Times: user=0.06 sys=0.03, real=2.97 secs]
262682.891: [GC [PSYoungGen: 2068909K->10709K(2075712K)] 4742017K->2686673K(4871936K), 1.1160323 secs] [Times: user=0.19 sys=0.00, real=1.13 secs]
262691.733: [GC [PSYoungGen: 2065941K->10683K(2075584K)] 4741905K->2689212K(4871808K), 1.4898942 secs] [Times: user=0.05 sys=0.00, real=1.50 secs]
262701.512: [GC [PSYoungGen: 2065888K->9341K(2076480K)] 4744418K->2690073K(4872704K), 1.3835846 secs] [Times: user=0.13 sys=0.00, real=1.39 secs]
262709.896: [GC [PSYoungGen: 2065601K->10718K(2076480K)] 4746334K->2693212K(4872704K), 0.7815897 secs] [Times: user=0.05 sys=0.01, real=0.78 secs]
262718.681: [GC [PSYoungGen: 2067028K->10199K(2076672K)] 4749523K->2695508K(4872896K), 1.2951014 secs] [Times: user=0.06 sys=0.00, real=1.30 secs]
262727.940: [GC [PSYoungGen: 2067345K->10112K(2076608K)] 4752654K->2698129K(4872832K), 1.6785345 secs] [Times: user=0.08 sys=0.00, real=1.69 secs]
262736.092: [GC [PSYoungGen: 2067264K->10886K(2077184K)] 4755281K->2702237K(4873408K), 1.1985764 secs] [Times: user=0.06 sys=0.02, real=1.20 secs]
262744.626: [GC [PSYoungGen: 2069382K->11366K(2077248K)] 4760733K->2705795K(4873472K), 1.4323653 secs] [Times: user=0.13 sys=0.00, real=1.44 secs]
262754.913: [GC [PSYoungGen: 2069912K->11945K(2077824K)] 4764342K->2708689K(4874048K), 0.8340946 secs] [Times: user=0.03 sys=0.00, real=0.84 secs]
262765.038: [GC [PSYoungGen: 2072283K->11669K(2077888K)] 4769028K->2711204K(4874112K), 1.3040060 secs] [Times: user=0.09 sys=0.02, real=1.31 secs]
262776.885: [GC [PSYoungGen: 2072021K->9940K(2079360K)] 4771556K->2711919K(4875584K), 0.8646772 secs] [Times: user=0.09 sys=0.00, real=0.88 secs]
262783.713: [GC [PSYoungGen: 1173115K->8659K(2079168K)] 3875094K->2713127K(4875392K), 1.4434465 secs] [Times: user=0.09 sys=0.00, real=1.45 secs]
262785.157: [Full GC (System) [PSYoungGen: 8659K->0K(2079168K)] [PSOldGen: 2704467K->655075K(2796224K)] 2713127K->655075K(4875392K) [PSPermGen: 41376K->40988K(42048K)], 132.6088125 secs] [Times: user=1.47 sys=0.39, real=132.58 secs]
262925.100: [GC [PSYoungGen: 2062280K->16892K(2068992K)] 2717355K->683188K(4865216K), 8.9491611 secs] [Times: user=0.13 sys=0.00, real=8.94 secs]
262971.183: [GC [PSYoungGen: 2068978K->8052K(2074624K)] 2735273K->692990K(4870848K), 7.7833800 secs]
When a "bad" full GC occurs, I can see that just before it the minor collections start to perform bad. Normal values for minor collections are 0,0x seconds, and before a "bad" full GC these minor collections take seconds (1, 2, ... up to 5 seconds).
I can show an histogram of the first 25 entries before and after the full GC:
BEFORE
num #instances #bytes class name
1: 226135 718455272 [I
2: 1905686 637239584 [C
3: 122775 621626112 [B
4: 8218 538714736 [Lcom.sun.org.apache.xpath.internal.objects.XObject;
5: 160974 445403288 [Ljava.lang.Object;
6: 1759928 70397120 java.lang.String
7: 334672 42838016 com.sun.org.apache.xerces.internal.dom.DeferredElementNSImpl
8: 103592 42699248 [[I
9: 227966 41945744 java.net.SocksSocketImpl
10: 629974 35278544 com.vpfw.proxy.cache.data.B
11: 636515 30552720 java.util.concurrent.ConcurrentHashMap$HashEntry
12: 555354 26656992 java.util.HashMap$Entry
13: 89059 18034280 [Ljava.util.HashMap$Entry;
14: 230432 16591104 com.sun.org.apache.xerces.internal.dom.DeferredTextImpl
15: 225401 14425664 java.lang.ref.Finalizer
16: 222588 14245632 java.net.SocketInputStream
17: 334644 13385760 com.sun.org.apache.xerces.internal.dom.AttributeMap
18: 386837 12378784 java.util.concurrent.ConcurrentLinkedQueue$Node
19: 40226 11263504 [[Ljava.lang.Object;
20: 21646 11246112 [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;
21: 684613 10953808 java.lang.Object
22: 227958 9118320 java.net.Socket
23: 218591 8743640 java.net.Inet4Address
24: 57810 8730528 <constMethodKlass>
25: 230658 7381056 java.io.FileDescriptor
AFTER
num #instances #bytes class name
1: 91917 650028776 [B
2: 1767088 612264368 [C
3: 176313 581838552 [I
4: 141278 322132688 [Ljava.lang.Object;
5: 1762956 70518240 java.lang.String
6: 367122 46991616 com.sun.org.apache.xerces.internal.dom.DeferredElementNSImpl
7: 239506 44069104 java.net.SocksSocketImpl
8: 633882 35497392 com.vpfw.proxy.cache.data.B
9: 639797 30710256 java.util.concurrent.ConcurrentHashMap$HashEntry
10: 606366 29105568 java.util.HashMap$Entry
11: 72730 20521256 [[I
12: 89136 18497696 [Ljava.util.HashMap$Entry;
13: 252946 18212112 com.sun.org.apache.xerces.internal.dom.DeferredTextImpl
14: 236339 15125696 java.lang.ref.Finalizer
15: 233891 14969024 java.net.SocketInputStream
16: 366906 14676240 com.sun.org.apache.xerces.internal.dom.AttributeMap
17: 429913 13757216 java.util.concurrent.ConcurrentLinkedQueue$Node
18: 43319 12129544 [[Ljava.lang.Object;
19: 719233 11507728 java.lang.Object
20: 21649 11246408 [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;
21: 239498 9579920 java.net.Socket
22: 143 9317736 [Lcom.sun.org.apache.xpath.internal.objects.XObject;
23: 229531 9181240 java.net.Inet4Address
24: 57817 8735944 <constMethodKlass>
25: 242443 7758176 java.io.FileDescriptor
The big differencies is the "com.sun.org.apache.xpath.internal.objects.XObject;".
Before and after, the values are:
4: 8218 538714736 [Lcom.sun.org.apache.xpath.internal.objects.XObject;
22: 143 9317736 [Lcom.sun.org.apache.xpath.internal.objects.XObject;
Could this the cause of the full GC that takes long time?
Thanks,
Joan.

Unflatten from string takes long time to execute in x64

Similar Messages

Maybe you are looking for