Performance problem on free chacteristics

Hi Friends,
We are getting performance problem with some of our BW Reports.
When we run BW web reports. Intial Screen of the report is OK.
when we do filtering on some free characteristics, It is taking ages to filter.
this is only for some Free characteristics.
These free characteristics are ok few days back and now we are facing this problems since 10 days.
Please help us in by providing your valuable solutions.
Thanks
Tony

Hi Oliver,
Let me explain in detail.
When we do drill down all Free chacteristics(Characteristics, Nav Attributes) - This is Fine
When we press filter option in order to filter (Nav Attributes) - This is Fine
When we press filter option in order to filter (Characteristics) - This is fine for some characteristics and some other are taking ages. These Guilty Chacteristics are SAP defined characteristics like 0Material, 0Plant, 0Sold_To.
Data loading is same since somany days.
Please advice how to proceed
Thanks.
Tony
Message was edited by:
tony

Similar Messages

Performance problem - Tablespace Free Space

Hi,
Version 10204
I am running the following statment in order to monitor tablespace free space.
There are some tablespaces that i am not interesting to monitor , and i also whant to be alert
only when less than 4 GB left in the tablespace.
I build the following statment.
Using the hint : /*+ NO_CPU_COSTING */ gave me the best performance but there are alot of time
that its took to this statment few minute to run befor it finished.
Could one help to improve its performance ?
Please note that it performe even less good when i used the RULE hint or not using hint at all.
SELECT /*+ gather_plan_statistics */ 'tablespace_free_space;'||to_char(pct_used,'999.99')||','||TBSNAME
FROM( SELECT *
      FROM( SELECT NVL(b.tablespace_name, NVL(a.tablespace_name,'UNKOWN')) TBSNAME,
                   MBytes_alloc,
                       maxbytes,
                       MBytes_max,
                   ROUND(MBytes_alloc-NVL(MBytes_free,0),2) used,
                   ROUND(NVL(MBytes_free,0),2) free,
                   MBytes_free,
                   ROUND(DECODE( MBytes_max, 0,((MBytes_alloc-NVL(MBytes_free,0))/MBytes_alloc)*100,100*(MBytes_alloc) / maxbytes),2)PCT_USED
            FROM ( SELECT /*+ NO_CPU_COSTING */ SUM(bytes)/1024/1024 MBytes_free,
                          MAX(bytes)/1024/1024 largest,
                          tablespace_name
                   FROM   sys.DBA_FREE_SPACE
                   WHERE TABLESPACE_NAME NOT IN
                          ('Q405_CALLS_TS','Q405_ICALLS_TS',
                           'Q305_CALLS_TS','Q305_ICALLS_TS',
                           'Q205_ICALLS_TS','Q306_CALLS_TS',
                           'Q406_CALLS_TS','Q206_CALLS_TS',
                           'Q205_CALLS_TS','Q105_CALLS_TS',
                           'Q105_ICALLS_TS','Q206_CALLS_TS','Q106_CALLS_TS',
                           'Q306_ICALLS_TS','Q107_ICALLS_TS','Q406_ICALLS_TS',
                           'Q206_ICALLS_TS','UNLMT_INTERNET_CALLS_2006_TS',
                           'UNLMT_INTERNET_CALLS_2007_TS',
                           'UNLMT_INTERNET_CALLS_2008_TS',
                           'Q107_ICALLS_TBS','Q107_CALLS_TBS',
                           'Q207_ICALLS_TBS','Q207_CALLS_TBS',
                           'Q307_ICALLS_TBS','Q307_CALLS_TBS',
                           'Q407_ICALLS_TBS','Q407_CALLS_TBS',
                           'Q408_ICALLS_TS','Q408_CALLS_TS',
                           'Q308_ICALLS_TS','Q308_CALLS_TS',
                           'Q208_ICALLS_TS','Q208_CALLS_TS',
                           'Q108_ICALLS_TS','Q108_CALLS_TS',
                           'Q109_ICALLS_TS','Q109_CALLS_TS',
                           'UNLMT_INT_CALLS_Q308_TS',
                           'UNLMT_INT_ICALLS_Q308_TS',
                           'UNLMT_INT_CALLS_Q408_TS',
                           'UNLMT_INT_ICALLS_Q408_TS'
                   GROUP BY tablespace_name ) a,
                 ( SELECT SUM(bytes)/1024/1024 MBytes_alloc,
                          SUM(maxbytes)/1024/1024 MBytes_max,
                          SUM(DECODE (autoextensible,'YES',maxbytes/1024/1024,'NO', BYTES/1024/1024 )) maxbytes,
                          tablespace_name
                   FROM   DBA_DATA_FILES
                   WHERE TABLESPACE_NAME NOT IN
                          ('Q405_CALLS_TS','Q405_ICALLS_TS',
                           'Q305_CALLS_TS','Q305_ICALLS_TS',
                           'Q205_ICALLS_TS','Q306_CALLS_TS',
                           'Q406_CALLS_TS','Q206_CALLS_TS',
                           'Q205_CALLS_TS','Q105_CALLS_TS',
                           'Q105_ICALLS_TS','Q206_CALLS_TS',
                           'Q106_CALLS_TS','Q306_ICALLS_TS',
                           'Q107_ICALLS_TS','Q406_ICALLS_TS',
                           'Q206_ICALLS_TS','UNLMT_INTERNET_CALLS_2006_TS',
                           'UNLMT_INTERNET_CALLS_2007_TS',
                           'UNLMT_INTERNET_CALLS_2008_TS',
                           'Q107_ICALLS_TBS','Q107_CALLS_TBS',
                           'Q207_ICALLS_TBS','Q207_CALLS_TBS',
                           'Q307_ICALLS_TBS','Q307_CALLS_TBS',
                           'Q407_ICALLS_TBS','Q407_CALLS_TBS',
                           'Q408_ICALLS_TS','Q408_CALLS_TS',
                           'Q308_ICALLS_TS','Q308_CALLS_TS',
                           'Q208_ICALLS_TS','Q208_CALLS_TS',
                           'Q108_ICALLS_TS','Q108_CALLS_TS',
                           'Q109_ICALLS_TS','Q109_CALLS_TS',
                           'UNLMT_INT_CALLS_Q308_TS',
                           'UNLMT_INT_ICALLS_Q308_TS',
                           'UNLMT_INT_CALLS_Q408_TS',
                           'UNLMT_INT_ICALLS_Q408_TS'
                   GROUP BY tablespace_name) b
            WHERE a.tablespace_name (+) = b.tablespace_name
            AND (a.MBytes_free<4000 or a.MBytes_free is null)
         ORDER BY PCT_USED DESC
WHERE TBSNAME not in (select tablespace_name from dba_tablespaces where contents in ('UNDO'))
and ROWNUM =1;
select * from table(dbms_xplan.display_cursor('42hppgtx2h1gb',0,'ALLSTATS LAST'));
Plan hash value: 2979461796
PLAN_TABLE_OUTPUT
| Id | Operation                               | Name             | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads | OMem | 1Mem | Used-Mem |
|* 1 | COUNT STOPKEY                          |                  |      1 |        |      1 |00:00:15.52 |     146K|   8927 |       |       |      |
|* 2 |   FILTER                                |                  |      1 |        |      1 |00:00:15.52 |     146K|   8927 |       |       |      |
|   3 |    VIEW                                 |                  |      1 |      3 |      1 |00:00:15.52 |     146K|   8927 |       |       |      |
|   4 |     SORT ORDER BY                       |                  |      1 |      3 |      1 |00:00:15.52 |     146K|   8927 | 2048 | 2048 | 2048 (0)|
|* 5 |      FILTER                             |                  |      1 |        |     16 |00:00:15.52 |     146K|   8927 |       |       |      |
|* 6 |       HASH JOIN OUTER                   |                  |      1 |      3 |     25 |00:00:15.52 |     146K|   8927 |   561K|   561K| 982K (0)|
|   7 |        VIEW                             |                  |      1 |      2 |     25 |00:00:02.95 |     105K|      0 |       |       |      |
|   8 |         HASH GROUP BY                   |                  |      1 |      2 |     25 |00:00:02.95 |     105K|      0 |   447K|   447K| 977K (0)|
|   9 |          VIEW                           | DBA_DATA_FILES   |      1 |      2 |    217 |00:00:03.25 |     105K|      0 |       |       |      |
| 10 |           UNION-ALL                     |                  |      1 |        |    217 |00:00:03.25 |     105K|      0 |       |       |      |
| 11 |            NESTED LOOPS                 |                  |      1 |      1 |      0 |00:00:00.67 |     219 |      0 |       |       |      |
| 12 |             NESTED LOOPS                |                  |      1 |      1 |      0 |00:00:00.67 |     219 |      0 |       |       |      |
| 13 |              MERGE JOIN CARTESIAN       |                  |      1 |      1 | 52297 |00:00:00.22 |       0 |      0 |       |       |      |
|* 14 |               FIXED TABLE FULL          | X$KCCFN          |      1 |      1 |    217 |00:00:00.01 |       0 |      0 |       |       |      |
| 15 |               BUFFER SORT               |                  |    217 |    100 | 52297 |00:00:00.06 |       0 |      0 | 11264 | 11264 |10240 (0)|
| 16 |                FIXED TABLE FULL         | X$KCCFE          |      1 |    100 |    241 |00:00:00.01 |       0 |      0 |       |       |      |
|* 17 |              TABLE ACCESS BY INDEX ROWID| FILE$            | 52297 |      1 |      0 |00:00:00.52 |     219 |      0 |       |       |      |
|* 18 |               INDEX UNIQUE SCAN         | I_FILE1          | 52297 |      1 |    217 |00:00:00.24 |       2 |      0 |       |       |      |
|* 19 |             TABLE ACCESS CLUSTER        | TS$              |      0 |      1 |      0 |00:00:00.01 |       0 |      0 |       |       |      |
|* 20 |              INDEX UNIQUE SCAN          | I_TS#            |      0 |      1 |      0 |00:00:00.01 |       0 |      0 |       |       |      |
| 21 |            NESTED LOOPS                 |                  |      1 |      1 |    217 |00:00:02.58 |     105K|      0 |       |       |      |
| 22 |             NESTED LOOPS                |                  |      1 |      1 | 52297 |00:00:01.89 |     104K|      0 |       |       |      |
| 23 |              MERGE JOIN CARTESIAN       |                  |      1 |      1 | 52297 |00:00:00.22 |     217 |      0 |       |       |      |
| 24 |               NESTED LOOPS              |                  |      1 |      1 |    217 |00:00:00.02 |     217 |      0 |       |       |      |
|* 25 |                FIXED TABLE FULL         | X$KCCFN          |      1 |      1 |    217 |00:00:00.01 |       0 |      0 |       |       |      |
|* 26 |                FIXED TABLE FIXED INDEX | X$KTFBHC (ind:1) |    217 |      1 |    217 |00:00:00.01 |     217 |      0 |       |       |      |
| 27 |               BUFFER SORT               |                  |    217 |    100 | 52297 |00:00:00.11 |       0 |      0 | 11264 | 11264 |10240 (0)|
| 28 |                FIXED TABLE FULL         | X$KCCFE          |      1 |    100 |    241 |00:00:00.01 |       0 |      0 |       |       |      |
|* 29 |              TABLE ACCESS CLUSTER       | TS$              | 52297 |      1 | 52297 |00:00:01.41 |     104K|      0 |       |       |      |
|* 30 |               INDEX UNIQUE SCAN         | I_TS#            | 52297 |      1 | 52297 |00:00:00.37 |       2 |      0 |       |       |      |
|* 31 |             TABLE ACCESS BY INDEX ROWID | FILE$            | 52297 |      1 |    217 |00:00:00.57 |     219 |      0 |       |       |      |
|* 32 |              INDEX UNIQUE SCAN          | I_FILE1          | 52297 |      1 |    217 |00:00:00.28 |       2 |      0 |       |       |      |
| 33 |        VIEW                             |                  |      1 |   1401 |     25 |00:00:12.56 |   40846 |   8927 |       |       |      |
| 34 |         HASH GROUP BY                   |                  |      1 |   1401 |     25 |00:00:12.56 |   40846 |   8927 |   465K|   465K| 982K (0)|
| 35 |          VIEW                           | DBA_FREE_SPACE   |      1 |   1401 | 73133 |00:00:14.19 |   40846 |   8927 |       |       |      |
| 36 |           UNION-ALL                     |                  |      1 |        | 73133 |00:00:14.04 |   40846 |   8927 |       |       |      |
| 37 |            NESTED LOOPS                 |                  |      1 |      1 |      0 |00:00:00.01 |      45 |      0 |       |       |      |
| 38 |             NESTED LOOPS                |                  |      1 |      1 |      0 |00:00:00.01 |      45 |      0 |       |       |      |
| 39 |              TABLE ACCESS FULL          | FET$             |      1 |      1 |      0 |00:00:00.01 |      45 |      0 |       |       |      |
|* 40 |              INDEX UNIQUE SCAN          | I_FILE2          |      0 |      1 |      0 |00:00:00.01 |       0 |      0 |       |       |      |
|* 41 |             TABLE ACCESS CLUSTER        | TS$              |      0 |      1 |      0 |00:00:00.01 |       0 |      0 |       |       |      |
| 42 |            NESTED LOOPS                 |                  |      1 |      5 |   7271 |00:00:00.20 |    1156 |      0 |       |       |      |
| 43 |             NESTED LOOPS                |                  |      1 |      6 |   7271 |00:00:00.14 |    1154 |      0 |       |       |      |
|* 44 |              TABLE ACCESS FULL          | TS$              |      1 |      2 |     25 |00:00:00.01 |      45 |      0 |       |       |      |
|* 45 |              FIXED TABLE FIXED INDEX    | X$KTFBFE (ind:1) |     25 |      3 |   7271 |00:00:00.11 |    1109 |      0 |       |       |      |
|* 46 |             INDEX UNIQUE SCAN           | I_FILE2          |   7271 |      1 |   7271 |00:00:00.04 |       2 |      0 |       |       |      |
| 47 |            NESTED LOOPS                 |                  |      1 |   1394 | 65862 |00:00:17.73 |   39476 |   8927 |       |       |      |
| 48 |             NESTED LOOPS                |                  |      1 | 30528 | 65862 |00:00:16.94 |   39474 |   8927 |       |       |      |
|* 49 |              HASH JOIN                  |                  |      1 |   2540 |   8927 |00:00:00.03 |      90 |      0 |   811K|   811K| 1397K (0)|
| 50 |               TABLE ACCESS FULL         | RECYCLEBIN$      |      1 |   8319 |   8935 |00:00:00.01 |      45 |      0 |       |       |      |
|* 51 |               TABLE ACCESS FULL         | TS$              |      1 |      2 |     25 |00:00:00.01 |      45 |      0 |       |       |      |
|* 52 |              FIXED TABLE FIXED INDEX    | X$KTFBUE (ind:1) |   8927 |     12 | 65862 |00:00:11.66 |   39384 |   8927 |       |       |      |
|* 53 |             INDEX UNIQUE SCAN           | I_FILE2          | 65862 |      1 | 65862 |00:00:00.45 |       2 |      0 |       |       |      |
|* 54 |            TABLE ACCESS BY INDEX ROWID | RECYCLEBIN$      |      1 |      1 |      0 |00:00:00.01 |     169 |      0 |       |       |      |
| 55 |             NESTED LOOPS                |                  |      1 |      1 |      1 |00:00:00.01 |     169 |      0 |       |       |      |
| 56 |              NESTED LOOPS               |                  |      1 |      1 |      0 |00:00:00.01 |     169 |      0 |       |       |      |
| 57 |               NESTED LOOPS              |                  |      1 |      1 |      0 |00:00:00.01 |     169 |      0 |       |       |      |
| 58 |                TABLE ACCESS FULL        | UET$             |      1 |      1 |      0 |00:00:00.01 |     169 |      0 |       |       |      |
|* 59 |                INDEX UNIQUE SCAN        | I_FILE2          |      0 |      1 |      0 |00:00:00.01 |       0 |      0 |       |       |      |
|* 60 |               TABLE ACCESS CLUSTER      | TS$              |      0 |      1 |      0 |00:00:00.01 |       0 |      0 |       |       |      |
|* 61 |                INDEX UNIQUE SCAN        | I_TS#            |      0 |      1 |      0 |00:00:00.01 |       0 |      0 |       |       |      |
|* 62 |              INDEX RANGE SCAN           | RECYCLEBIN$_TS   |      0 |   1188 |      0 |00:00:00.01 |       0 |      0 |       |       |      |
|* 63 |    TABLE ACCESS FULL                    | TS$              |      1 |      1 |      0 |00:00:00.01 |      45 |      0 |       |       |      |
Predicate Information (identified by operation id):
   1 - filter(ROWNUM=1)
   2 - filter( IS NULL)
   5 - filter(("A"."MBYTES_FREE"<4000 OR "A"."MBYTES_FREE" IS NULL))
   6 - access("A"."TABLESPACE_NAME"="B"."TABLESPACE_NAME")
14 - filter(("INST_ID"=USERENV('INSTANCE') AND "FNNAM" IS NOT NULL AND BITAND("FNFLG",4)<>4 AND "FNTYP"=4))
PLAN_TABLE_OUTPUT
17 - filter(("F"."SPARE1" IS NULL AND "F"."TS#" IS NOT NULL))
18 - access("FE"."FENUM"="F"."FILE#")
       filter("FNFNO"="F"."FILE#")
19 - filter(("TS"."NAME"<>'Q405_CALLS_TS' AND "TS"."NAME"<>'Q405_ICALLS_TS' ... AND "TS"."NAME"<>'UNLMT_INT_ICALLS_Q408_TS'))
20 - access("F"."TS#"="TS"."TS#")
25 - filter(("INST_ID"=USERENV('INSTANCE') AND "FNNAM" IS NOT NULL AND BITAND("FNFLG",4)<>4 AND "FNTYP"=4))
26 - filter("FNFNO"="HC"."KTFBHCAFNO")
29 - filter(("TS"."NAME"<>'Q405_CALLS_TS' AND "TS"."NAME"<>'Q405_ICALLS_TS' AND ... AND "TS"."NAME"<>'UNLMT_INT_ICALLS_Q408_TS'))
30 - access("HC"."KTFBHCTSN"="TS"."TS#")
31 - filter("F"."SPARE1" IS NOT NULL)
32 - access("FE"."FENUM"="F"."FILE#")
       filter("FNFNO"="F"."FILE#")
40 - access("F"."TS#"="FI"."TS#" AND "F"."FILE#"="FI"."RELFILE#")
PLAN_TABLE_OUTPUT
       filter(("FI"."TS#" IS NOT NULL AND "FI"."RELFILE#" IS NOT NULL))
41 - filter(("TS"."TS#"="F"."TS#" AND "TS"."BITMAPPED"=0 AND "TS"."NAME"<>'Q405_CALLS_TS' AND "TS"."NAME"<>'Q405_ICALLS_TS' AND
              "TS"."NAME"<>'Q305_CALLS_TS' AND "TS"."NAME"<>'Q305_ICALLS_TS' AND ... "TS"."NAME"<>'UNLMT_INT_ICALLS_Q408_TS'))
44 - filter(("TS"."BITMAPPED"<>0 AND INTERNAL_FUNCTION("TS"."ONLINE$") AND .... "TS"."NAME"<>'UNLMT_INT_ICALLS_Q408_TS'))
45 - filter("TS"."TS#"="F"."KTFBFETSN")
46 - access("F"."KTFBFETSN"="FI"."TS#" AND "F"."KTFBFEFNO"="FI"."RELFILE#")
       filter(("FI"."TS#" IS NOT NULL AND "FI"."RELFILE#" IS NOT NULL))
49 - access("TS"."TS#"="RB"."TS#")
51 - filter(("TS"."BITMAPPED"<>0 AND INTERNAL_FUNCTION("TS"."ONLINE$") AND...."TS"."NAME"<>'UNLMT_INT_ICALLS_Q408_TS'))
52 - filter(("U"."KTFBUESEGTSN"="RB"."TS#" AND "U"."KTFBUESEGFNO"="RB"."FILE#" AND "U"."KTFBUESEGBNO"="RB"."BLOCK#"))
53 - access("RB"."TS#"="FI"."TS#" AND "U"."KTFBUEFNO"="FI"."RELFILE#")
       filter(("FI"."TS#" IS NOT NULL AND "FI"."RELFILE#" IS NOT NULL))
PLAN_TABLE_OUTPUT
54 - filter(("U"."SEGFILE#"="RB"."FILE#" AND "U"."SEGBLOCK#"="RB"."BLOCK#"))
59 - access("U"."TS#"="FI"."TS#" AND "U"."SEGFILE#"="FI"."RELFILE#")
       filter(("FI"."TS#" IS NOT NULL AND "FI"."RELFILE#" IS NOT NULL))
60 - filter(("TS"."BITMAPPED"=0 AND "TS"."NAME"<>'Q405_CALLS_TS' AND .... AND "TS"."NAME"<>'UNLMT_INT_CALLS_Q408_TS' AND
              "TS"."NAME"<>'UNLMT_INT_ICALLS_Q408_TS'))
61 - access("TS"."TS#"="U"."TS#")
62 - access("U"."TS#"="RB"."TS#")
63 - filter((DECODE("TS"."CONTENTS$",0,DECODE(BITAND("TS"."FLAGS",16),16,'UNDO','PERMANENT'),1,'TEMPORARY')='UNDO' AND "TS"."ONLINE$"<>3 AND
              BITAND("FLAGS",2048)<>2048 AND LNNVL("TS"."NAME"<>:B1)))
Note
PLAN_TABLE_OUTPUT
   - cpu costing is off (consider enabling it)

Version 10204
I am running the following statment in order to monitor tablespace free space.
There are some tablespaces that i am not interesting to monitor , and i also whant to be alert
only when less than 4 GB left in the tablespace.
And just adding to Dan's reply, if you are on 10g as you mentioned, why not to use the built in Alert mechanism to monitor and get alerts about the tablespace usage using the GC or Database Console than creating a home grown solution like the one you have posted?
Aman....

Performance Problems on Faces Navigation Diagram and Hyperthreading query

Am I the only one having performance problems when dealing with Faces-Config Diagrams of about 35 JSPs displayed on the sheet. using Jdev 10.1.3 It's taking my workstation about a full minute and a half to update the name of an arrow. The most stressed component during this task seems to be the CPU.
And just another question has anybody investigated how is the performance of Jdev affected by either enabling or disabling hyperthreading? In my case my CPU usage manages to reach only 50%. I'm tempted to switch HT off to let JDev use all the cpu power. if that would be the case.

Hello Diego,
you mentioned that you compared a BEx Query with the Web INtelligence report. Could you provide more details here ?
- what are the elements in the rows, columns and free characterisitcs in the BEx Query ?
- was the query execute as designed in the BEx Query Designer with BEx Web Reporting ?
- what are the elements in the WebIntelligence Query panel ?
thanks
Ingo

Performance problem with Mavericks.

Performance problem with Mavericks. My Mac is extremly slow after upgrading to Mavericks. What can i do to solve that?

If you are still experiencing slow down issues, it maybe because of a few other reasons.
Our experience with OS X upgrades, and Mavericks is no exception, is that users have installed a combination of third party software and/or hardware that is incompatible and/or is outdated that causes many negative performance issues when upgrading to a new OS X version.
Your Mac's hard drive maybe getting full.
Do you run any antivirus software on your Mac? Commercial Antivirus software can slow down and negatively impact the normal operation of OS X.
Do you have apps like MacKeeper or any other maintenance apps like CleanMyMac 1 or 2, TuneUpMyMac or anything like these apps, installed on your Mac? These types of apps, while they appear to be helpful, can do too good a job of data "cleanup" causing the potential to do serious data corruption or data deletion and render a perfectly running OS completely dead and useless leaving you with a frozen, non-functional Mac.
Your Mac may have way too many applications launching at startup/login.
Your Mac may have old, non-updated or incompatible software installed.
Your Mac could have incompatible or outdated web browser extensions, plugins or add-ons.
Your Mac could have connected third party hardware that needs updated device drivers.
It would help us to help you if we could have some more technical info about your iMac.
If you so choose, please download, install and run Etrecheck.
Etrecheck was developed as a simple Mac diagnostic report tool by a regular Apple Support forum user and technical support contributor named Etresoft. Etrecheck is a small, unobstrusive app that compiles a static snapshot of your entire Mac hardware system and installed software.
This is a free app that has been honestly created to provided help in diagnosing issues with Macs running the new OS X 10.9 Mavericks.
It is not malware and can be safely downloaded and installed onto your Mac.
http://www.etresoft.com/etrecheck
Copy/paste and post its report here in another reply thread so that we have a complete profile of your Mac's hardware and installed software so we can all help continue with your Mac performance issues.
Thank you.

(new?) performance problem using jDriver after a Sql Server 6.5 to 2000 conversion

Hi,
This is similar - yet different - to a few of the old postings about performance
problems with using jdbc drivers against Sql Server 7 & 2000.
Here's the situation:
I am running a standalone java application on a Solaris box using BEA's jdbc driver
to connect to a Sql Server database on another network. The application retrieves
data from the database through joins on several tables for approximately 40,000
unique ids. It then processes all of this data and produces a file. We tuned
the app so that the execution time for a single run through the application was
24 minutes running against Sql Server 6.5 with BEA's jdbc driver. After performing
a DBMS conversion to upgrade it to Sql Server 2000 I switched the jDriver to the
Sql Server 2000 version. I ran the app and got an alarming execution time of
5hrs 32 min. After some research, I found the problem with unicode and nvarchar/varchar
and set the "useVarChars" property to "true" on the driver. The execution time
for a single run through the application is now 56 minutes.
56 minutes compared to 5 1/2 hrs is an amazing improvement. However, it is still
over twice the execution time that I was seeing against the 6.5 database. Theoretically,
I should be able to switch out my jdbc driver and the DBMS conversion should be
invisible to my application. That would also mean that I should be seeing the
same execution times with both versions of the DBMS. Has anybody else seen a
simlar situation? Are there any other settings or fixes that I can put into place
to get my performance back down to what I was seeing with 6.5? I would rather
not have to go through and perform another round of performance tuning after having
already done this when the app was originally built.
thanks,
mike

Mike wrote:
Joe,
This was actually my next step. I replaced the BEA driver with
the MS driver and let it run through with out making any
configuration changes, just to see what happened. I got an
execution time of about 7 1/2 hrs (which was shocking). So,
(comparing apples to apples) while leaving the default unicode
property on, BEA ran faster than MS, 5 1/2 hrs to 7 1/2 hrs.
I then set the 'SendStringParametersAsUnicode' to 'false' on the
MS driver and ran another test. This time the application
executed in just over 24 minutes. The actual runtime was 24 min
16 sec, which is still ever so slightly above the actual runtime
against SS 6.5 which was 23 min 35 sec, but is twice as fast as the
56 minutes that BEA's driver was giving me.
I think that this is very interesting. I checked to make sure that
there were no outside factors that may have been influencing the
runtimes in either case, and there were none. Just to make sure,
I ran each driver again and got the same results. It sounds like
there are no known issues regarding this?
We have people looking into things on the DBMS side and I'm still
looking into things on my end, but so far none of us have found
anything. We'd like to continue using BEA's driver for the
support and the fact that we use Weblogic Server for all of our
online applications, but this new data might mean that I have to
switch drivers for this particular application.Thanks. No, there is no known issue, and if you put a packet sniffer
between the client and DBMS, you will probably not see any appreciable
difference in the content of the SQL sent be either driver. My suspicion is
that it involves the historical backward compatibility built in to the DBMS.
It must still handle several iterations of older applications, speaking obsolete
versions of the DBMS protocol, and expecting different DBMS behavior!
Our driver presents itself as a SQL7-level application, and may well be treated
differently than a newer one. This may include different query processing.
Because our driver is deprecated, it is unlikely that it will be changed in
future. We will certainly support you using the MS driver, and if you look
in the MS JDBC newsgroup, you'll see more answers from BEA folks than
from MS people!
Joe
>
>
Mike
The next test you should do, to isolate the issue, is to try another
JDBC driver.
MS provides a type-4 driver now, for free. If it is significantly faster,
it would be
interesting. However, it would still not isolate the problem, because
we still would
need to know what query plan is created by the DBMS, and why.
Joe Weinstein at BEA
PS: I can only tell you that our driver has not changed in it's semantic
function.
It essentially send SQL to the DBMS. It doesn't alter it.

LR3 "Extra Processing in Develop" Performance Problem

I have been investigating a specific LR3 performance problem. It may explain a small subset of the problems people have reported in the "Why is LR3 So Slow?" thread. I'm starting this thread to focus on this particular problem. I hope others will confirm/refute/refine my findings.
The Problem
In Develop, when I make an adjustment, normally the following happens: The CPU usage (as shown in Activity Monitor's bar graph) jumps to between 50 and 75% for all four cores, the updated image appears, and the CPU usage settles back down. This all happens in less than half a second. Note: this is with the image at the Fit size. However, sometimes I instead get the following after an adjustment: the CPU usage jumps to 50 to 75% for all four cores and the updated image appears as usual, however, instead of settling back down, the CPU usage jumps up to 90 to 100% for all cores and stays there for 3 to 5 seconds before settling down. Thus it appears that LR is doing some kind of "extra processing" since a lot of computation is happening AFTER the updated image has already appeared. I will refer to this problem as "EP". Obviously, when you are getting EP, editing in Develop becomes very balky.
Dependency on ratio between image size and displayed size
It appears that EP only happens when the displayed size of the image (in Fit zoom level and perhaps also Fill zoom level) is above a certain percentage of the actual image size (as currently cropped). Evidence: When editing full 21MP 5D2 images, I don't experience EP. If I crop the 5D2 image fairly significantly, then I can get EP. When editing 10MP images from my Canon S90, I usually get EP for landscape orientation pictures but not for portrait orientation pictures (since in Fit mode, landscape images display at a higher zoom level than portrait images). If I am getting EP, I can eliminate it by sufficiently reducing the size that LR is displaying the image by resizing the LR window smaller, opening additional panels (I normally edit with only the right panel open), displaying the toolbar, etc. It appears that EP is enabled when the displayed image is about 50% or larger w.r.t. the actual image (as currently cropped). For example, EP becomes enabled when a 3648 pixel wide S90 image is displayed at least 17 and 7/8 inches wide on my 100 ppi monitor (i.e. about 1787 pixels).
Dependency on HOW an adjustment is invoked
Even when the displayed image size is large enough w.r.t. the actual image size to enable EP, whether you get it on a given adjustment depends on how you invoke it:
- If you CLICK (i.e. press the mouse button down and quickly release it) on the track of one of the sliders (a technique I use often to make big jumps), EP will happen.
- If you press the mouse button down on a slider handle, drag it to a new position, and quickly release the mouse button), EP will happen
- If you press the mouse button down on a slider handle, drag it to a new position, but continue to hold the mouse button down until the displayed image is updated, EP does NOT happen (either before or after you then release the mouse button).
- If you highlight the numeric field at the end of a slider and use the arrow keys (possibly along with Shift) to increment or decrement the value, EP does NOT happen.
- EP will happen if you resize the LR window such that the displayed image size is above the threshold. (In fact, I determined the threshold by making a series of window width increases until I saw EP indicated by the CPU bar graphs.)
- EP can happen with local adjustment brush applications, but as with the sliders, it depends on HOW you perform the brush stroke. Single click and drags with immediate mouse release cause EP, drags with delayed mouse button release don't.
- Clicking an earlier History state causes EP
- More exploration could be done. For example, I haven't looked at Graduated Filter and Spot Removal adjustments.
My theory of what's happening
With LR2, my understanding is that in Develop mode when the displayed image is below 1:1 zoom level, after an adjustment is invoked, LR calculates the new version of the image to display using a fast, simplified algorithm that doesn't include the more computationally intensive adjustments like Sharpening and Noise Reduction (and perhaps works on a lower rez version of the image with multiple sensels binned together?). It appears that in conditions described above, LR3 calculates the initial, fast image update and then goes on to do the full update of the image, including the computationally intensive adjustments. Evidence: setting Sharpening Amount and Luminance and Color Noise Reduction to zero eliminates EP (or reduces the amount of time it takes to be barely noticeable). I'm not sure whether the displayed image is updated with the results of the extra processing. I think the answer is Yes since when I tried an adjustment of changing Sharpening Amount from 0 to 90, the initial update of the displayed image showed sharpening but after the EP, the displayed image was updated again to show somewhat different sharpening. Perhaps Adobe felt that it would be useful to see the more accurate version of the image when it is at or above 50% zoom. Maybe the UI is supposed to cancel the EP if you start to make another adjustment before it has completed but the canceling doesn't happen unless you invoke the adjustment in one of the ways described above that doesn't cause EP.
Misc
- EP doesn't seem to happen for Process 2003
- As others have mentioned, I'm surprised that LR (both version 2 and 3) in 64bit mode doesn't use more available RAM. I don't think I've seen LR go above 4GB of virtual memory or above 3GB "Real Memory" (as reported by Activity Monitor) even though I have several GB free.
- It should be obvious from the above that if you experience EP, there are workarounds: reduce the size of the displayed image (e.g. by window resizing), invoke adjustments in ways that don't cause EP, turn off Sharpening and Noise Reduction until the end of editing an image.
System specs
First generation Intel Mac Pro with two dual-core CPUs at 2.66 Ghz
OS 10.5.8
21GB RAM
ACR cache on volume striped across 3 internal SATA drives
LR catalog and RAWs on an internal SATA drive
30" HP LP3065 monitor (2560 pixels wide)
NVIDIA GeForce 7300 GT

I'm impressed by your thorough analysis.
Clearly, the programmers haven't figured out the best way to do intelligent caching and/or parallel rendering at a reduced size yet.
In my experience reducing the settings in the "Details" panel doesn't help.
What really bugs me is that the lag (or increasing lack of interactiveness) depends on the number of adjustments one has made.
This shouldn't be the case. If a cache is produced then every further adjustment should only cost the effort for that latest adjustment and not include adjustments before it. There are things that stand in the way of straightforward edit applications:
If you work below 1:1 preview, adjustments have to be shown in a reduced form. If you don't have a way to faithfully mimic the adjustments on the reduced size, you have to do them on the original image and then scale down. That's expensive.
To the best of my knowledge LR uses a fixed image pipeline. Hence, independently of the order in which you apply edits, they are always performed in the same fixed order. Say all spot removal operations are done first. If you have a lot of adjustment brush edits and then add a spot removal operation, it means that all the adjustment brush operations have to be replayed each time you do a little adjustment on your spot removal edit.
I believe what you are seeing is mostly related to 1.
I also believe that the way LR currently handles a moderate number of edits is unacceptable and incompatible with the notion that it is usable in a commercial setting for more than trivial edits. I suspect there is something else going on. If everyone saw the deterioration in performance after a number of edits that I see, I don't think LR would be as accepted as it is. Having said that, I've read that the problem of repeated applications of the adjustment brush slowing LR down has existed for a long time. I truly hope that this doesn't mean we'll have to live for it for the foreseeable future.
There are two ways I can see how 2. should be addressed:
combine the effects of a set of operations into one bitmap operation. Instead of replaying all adjustment brush strokes one after the other (speedwise it feels like this is happening), compute a single bitmap operation that combines all effects.
give up the idea that there is an image pipeline with a fixed execution order.
Some might argue that the second point is at odds with the whole idea of parametric editing, but I dispute that. Either edit operations are commutable in which case the order is immaterial, or they are not. If they are not, the user applies the edits in a way as he/she sees fit and will thus compensate for any effect of a changed ordering.
N.B., currently the doctrine of "fixed ordering of edit applications" results in the effect that even if you convert an image into B&W all your adjustment brush edits that applied colour tints will still show through. Reasoning: The user should be able to locally tint a B&W image. I agree with the latter but this could be achieved by only applying those tinting brush strokes that were created after the B&W conversion. All the ones that happened before should only be used to obtain the correct luminance values for the B&W conversion but obviously they shouldn't cause tinted areas.
The above example demonstrates to me that users naturally expect operations to occurr in the order they have been introduced, not in a fixed predefined order. If that principle were followed, I see no reason why the speed of a single edit should depend on the number of edits that were done to the image before.
I hope the programmers can (and the management wants to) address the performance issues. While I find LR usable for pretty modest edits, in no way the performance on my system approaches that would I would expect from an industrial strenght application.
P.S.: Your message reminded me of the following: When I experience serious lag with LR showing the strokes I make with an adjustment brush, it helps to pause a moment after the first click before one starts moving. This allows LR to catch up and then one can see the effect of the application pretty much interactively. Otherwise, there is terrible lag and the feedback where you have brushed an effect comes way too late.

Performance problem with transaction log

We are having some performance problem in SAP BW 3.5 system running on MS SQL server 2000.The box is sized 63,574 MB. The transaction logs gets filled up after loading data in to a transactional cube or after doing selective deletion. The size of the transaction log is 7,587MB currently.
Basis team feels that when performing either loading or selective deletion, SQL server views it as a single transaction and doesn't commit until every record is written. And so as a result, transaction logs fills up ultimately bringing the system down.
The system log shows a DBIF error during the transaction log fill up as follows:
Database error 9002 at COM
> [9002] the log file for database 'BWP' is full. Back up the
> Transaction log for the database to free up some log space.
Function COMMIT on connection R/3 failed
Perform rollback
Can we make changes to Database to make commit action frequently? Is there any parameters we could change to reduce the packet size? Is there some setting to be changed in SQL server?
Any Help will be appreciated.

if you have disk space avialable you can allocate more space to the transaction log.

Performance problem , 100 % swap used, but vmstat - sr = 0

Hi,
I have a performance problem on a server. It is sometimes very low during several hours.
context : v890, 32 Go RAM, 8 SPARC IV+, solaris 10 release 03/05, veritas volume manager, containers, several oracle databases, applications...
with iostat, swap partition : %b -> 100% !!!!
with vmstat, r-> 0, b -> 0, w ->29, free memory : 600 Mo , sr -> 0, idle : more than 50%,
uptime, load average : 6
vmstat -S : si -> 0 , so -> 0
vmstat -p : api -> 45126682863 ( probably a bug ) , apo -> 0 fpi -> 1895320681342 ( probably a bug ), fpo -> 0
It's difficult to me to find the problem. Is it paging activity ??? someone can tell me, what is the memory limit for paging activity start ?
If you thing I'm in the wrong way, thanks for all ideas :)
Julien
Edited by: Wylem on Feb 28, 2008 6:11 PM

Does seem a bit odd.
The 'w' column doesn't necessarily mean that anything bad is happening now, but it does mean that the system was severely memory limited at some point in the past at least.
Paging should occur when free memory drops below LOTSFREE. I don't remember if swapping happens at a particular point, but probably wouldn't happen above DESFREE. The page scanner should become active (non-zero 'sr' numbers) any time the memory is below LOTSFREE.
Since you have Solaris 10, you might want to grab the dtrace toolkit and see if some of the tools in there show you anything more useful (some of the I/O ones might break down the access further).
So it really doesn't look like you're swapping/paging out anything now, but you almost certainly did in the past. It could be that you're using an app that has paged out a lot of stuff do disk, so that the I/O you're seeing is it bringing stuff back now that RAM is available.
Darren

Performance Problem, RPC Call auf SQLServer 2000

Hi,
we have a performance problem with SQLServer 2000. We use Bea WLS 6.1, SQLServer
2000, and JDBC Driver mssqlserver4v65.jar from Bea.
we use this for performance optimization as in Documetation at
"http://www.datadirect-technologies.com/download/docs/jdbc/Jdbcref/jdbcdesign.html"
case 2
Stored Procedure can be optimized to use a server-side RPC. Because the application
calls the procedure by name and the argument values are already encoded, the load
on the database server is less
CallableStatement cstmt = conn.prepareCall ("Call getCustName (?)");
cstmt.setLong (1,12345);
ResultSet rs = cstmt.executeQuery();
But the checking in the SQlServer 2000 with SQL Profiler don't show the use of
RPC Call.
I can test the different from Query Analyser:
exec IF_GetBueroStatistik 1 -> SQLProfiler: SQL:BatchCompleted
{call IF_GetBueroStatistik(1)} -> SQlProfiler: RPC:Completed
But the Call from Bea Aplication make in SQlProfiler alwasy SQl:BatchCompleted.
The RPC ist faster from the Batch call.
is that a bug in the driver implementation?
can any help me with a solution or workaround?
thanks Halim

Hi,
thank you very much Joe.
Halim.
Joseph Weinstein <[email protected]> wrote:
>
>
Halim wrote:
Hi,
we have a performance problem with SQLServer 2000. We use Bea WLS 6.1,SQLServer
2000, and JDBC Driver mssqlserver4v65.jar from Bea.You shouldn't be using the 6.5 version of the driver anyway. The 7.0
version is better,
but what you are seeing is that our driver does send fresh SQL for PreparedStatements,
which is not as fast as using the RPC protocol. It's not a bug, but it
is a feature we didn't
implement.
You should probably download and use the free driver from MS. It does
implement
the procedure protocol.
Joe
we use this for performance optimization as in Documetation at
"http://www.datadirect-technologies.com/download/docs/jdbc/Jdbcref/jdbcdesign.html"
case 2
Stored Procedure can be optimized to use a server-side RPC. Becausethe application
calls the procedure by name and the argument values are already encoded,the load
on the database server is less
CallableStatement cstmt = conn.prepareCall ("Call getCustName (?)");
cstmt.setLong (1,12345);
ResultSet rs = cstmt.executeQuery();
But the checking in the SQlServer 2000 with SQL Profiler don't showthe use of
RPC Call.
I can test the different from Query Analyser:
exec IF_GetBueroStatistik 1 -> SQLProfiler: SQL:BatchCompleted
{call IF_GetBueroStatistik(1)} -> SQlProfiler: RPC:Completed
But the Call from Bea Aplication make in SQlProfiler alwasy SQl:BatchCompleted.
The RPC ist faster from the Batch call.
is that a bug in the driver implementation?
can any help me with a solution or workaround?
thanks Halim

Performance problem of RAC

Dear,
I encountered performance problem in my production databases, running Oracle RAC (2 nodes) on version 10.2.0.2.0. The scenario is that the database suddenly slows down at a particular time. In reviewing the alert log, I found the following message:
Node 1: Ora-3136 inbound connection timed out (occurs around 20 times)
Node 2: SQL*net time-out error (occurs few times)
In addition, in my statspack report, at that particular time interval, the following messages appear:
Node 1:
For the top 5 timed events, 'log file switch completion' is the first on the list, with the following figures:
Waits Time(s) Avg Wait (ms) Total Call time
4143 4036 974 25.8
Node 2:
For the top 5 timed events, 'gc cr block busy' is the first on the list, with the following figures:
Waits Time(s) Avg Wait (ms) Total Call time
3387 1939 573 27.2
I just guess 'log file switch completion' should not always be on the 'wait list'. Also, Archive log seems not full at the moment. There are also a lot of I/O at that moment. Not understand what the DB is doing.
Do anyone have any ideas on the cause of the problem?
Thanks

You need to define a service to run preferably on node 2 with failover to node 1, and give a your batch jobs a connect string that connects to that service:
srvctl add service -d whatever -s batchserv -r node2 -a node1
and in your tnsnames.ora,
batchserv=
(description=
    (address_list=
         (failover=on)(load_balance=on)
         (address=(node1....)(address=(node2...))
     (connect_data=(service_name=batchserv))
I've recorded many demonstrations of this sort thing,
Free Oracle Databse 12c and 11g Tutorials for Administration and Developers SkillBuilders
John Watson
Oracle Certified Master DBA

Question for ORACLE EXPERTS!!! PERFORMANCE PROBLEM!!!

I have 2 nodes on RAC. On node1 the following query run in 15 seconds and on node2 the same query run in 40 minutes. This is a big problem because we are migrating a SQL Server database to Oracle RAC 10gR2 (10.2.0.2) on HP-UX Itanium and we can´t finish the project because of this performance problem!!! PLEASE HELP ME ORACLE GURUS !!! I have opened a TAR at Metalink a 3 month ago,but they can´t help me with this. Can anyone explain this event to me please??? " gc cr multi block request 92011 0.33 737.49
This is the query that i run on both nodes and this is the tkprof of the trace file when i run this on second node:
select /*+ NO_PARALLEL(t) */ sum(t.saldo_em_real)
from
brcapdb2.titulo t
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 13.76 790.26 0 107219 0 0
total 3 13.76 790.26 0 107219 0 0
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 31
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
SQL*Net message from client 2 0.02 0.02
gc cr multi block request 92011 0.33 737.49
gc current grant busy 1 0.00 0.00
latch: KCL gc element parent latch 4 0.00 0.00
latch: object queue header operation 17 0.00 0.01
latch free 6 0.00 0.00
gc remaster 9 1.94 9.00
gcs drm freeze in enter server mode 19 1.97 30.52
gc current block 2-way 10 0.61 2.72
SQL*Net break/reset to client 1 0.01 0.01
Please help me if you can!!
Tks,
Paulo.

Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
SQL*Net message from client 2 0.02 0.02
gc cr multi block request 92011 0.33 737.49
gc current grant busy 1 0.00 0.00
latch: KCL gc element parent latch 4 0.00 0.00
latch: object queue header operation 17 0.00 0.01
latch free 6 0.00 0.00
gc remaster 9 1.94 9.00
gcs drm freeze in enter server mode 19 1.97 30.52
gc current block 2-way 10 0.61 2.72
SQL*Net break/reset to client 1 0.01 0.01There's lots of global cache traffic going on. All those multiblock transfers seem to be saturating the interconnect. Some things to consider:
- Have a look at metalink note 3951017.8 for a possible fix
- Check that your interconnect is properly configured
- Try running the query with PARALLEL hint. This would mean doing disk I/O instead of buffer & interconnect I/O.
edit: changed "without NOPARALLEL" to "with PARALLEL"
Message was edited by:
antti.koskinen

Performance Problem Database Server on Solaris 10 5/08 (Update 5) v890 Box

Hello,
I am having performance problems on Solaris 10 5/08 (Update 5) Production server below I have mentioned the details information about the system and some command iostat and vmstat reports:
Sun Fire V890
Ram 32 GB
Physical CPU 8 (Logical 16)
Application Oracle 10G
Raid 1
1) iostat report
extended device statistics tty
device r/s w/s kr/s kw/s wait actv svc_t %w %b tin tout
md100 0.3 7.0 2.4 7.0 0.0 0.2 38.5 3 4 0 0
2/md3100 205.0 27.4 23099.6 472.2 0.0 2.5 10.9 0 79
2/md3200 225.3 27.3 24993.8 577.3 0.0 2.6 10.5 0 81
2/md3300 295.8 25.5 31538.0 412.5 0.0 3.1 9.8 0 84
2/md3400 198.3 25.6 21032.9 423.7 0.0 2.2 9.8 0 65
2/md3500 55.0 313.0 2397.5 2425.9 0.0 1.2 3.2 0 93
2/md3600 0.1 19.2 0.8 1440.0 0.0 0.1 5.4 0 10
2/md3700 3.1 0.8 48.8 35.7 0.0 0.0 9.3 0 4
2/md3800 300.4 0.7 30651.9 69.4 0.0 2.6 8.7 0 92
2/md3900 359.9 0.7 35876.8 56.6 0.0 3.3 9.1 0 95
2/md4100 0.6 512.1 9.6 1815.8 0.0 1.2 2.4 0 70
2/md4200 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0
2) vmstat report
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr 2m 2m 2m 2m in sy cs us sy id
1 20 0 39126264 11482648 2570 5039 16336 14 14 0 1 41 38 47 61 71072 41785 30463 51 14 35
0 16 0 40580912 9157288 273 2366 0 8 7 0 0 198 310 251 192 49207 47702 29823 39 8 53
0 16 0 40588992 9163784 187 1392 0 8 8 0 0 251 278 212 163 47310 44840 27821 31 7 62
0 12 0 40597208 9171640 624 3168 0 2 2 0 0 298 329 209 245 49150 44768 26264 29 8 62
0 13 0 40577400 9158032 425 4452 0 9 8 0 0 177 181 331 292 49149 42545 25544 31 8 61
0 14 0 40576680 9156328 868 6027 0 8 7 0 0 161 234 259 327 48726 41187 26184 26 9 65
0 13 0 40567952 9151360 1067 7302 0 3 3 0 0 254 386 256 160 50388 45422 26596 31 10 60
0 13 0 40565160 9150880 838 6582 0 9 8 0 0 257 289 236 281 49697 45190 26925 31 10 60
0 12 0 40568616 9153128 640 4880 0 11 10 0 0 334 206 214 214 48738 43552 26431 27 9 65
0 12 0 40581696 9163248 799 5895 0 2 2 0 0 426 273 138 226 47831 41873 26301 30 9 61
0 11 0 40572096 9157896 1087 7138 1 10 9 0 0 337 163 220 305 53124 55371 27933 45 11 44
0 18 0 40520032 9123424 868 5946 0 10 9 0 0 222 218 170 249 51322 49556 27867 40 10 50
0 17 0 40528544 9130112 481 3257 0 1 1 0 0 276 269 145 316 56103 44359 27645 39 9 51
0 15 0 40521776 9126208 490 3174 0 10 8 0 0 240 305 226 222 55839 43464 27003 42 10 48
0 15 0 40491176 9101072 769 4149 0 8 8 0 0 297 362 150 317 59718 55624 34333 43 11 46
0 17 0 40603696 9183224 785 4364 0 2 2 0 0 314 234 281 238 62990 67554 39122 43 12 45
0 19 0 40622592 9215816 711 5308 1 12 12 0 0 390 167 252 283 65340 60514 30525 45 12 44
0 17 0 40662248 9276136 767 5113 0 10 8 0 0 218 280 298 221 63734 53314 31029 43 11 45
3) SAR CPU Utilization report
12:30:51 %usr %sys %wio %idle
12:31:01 41 9 0 50
12:31:11 43 11 0 46
12:31:21 42 11 0 47
12:31:31 44 12 0 44
12:31:41 42 11 0 47
Average 42 11 0 47
Anybody have any comment regarding the reports ?
Thanks for your help,
Srikanta Sanpui

A suggestion: if you use the code tags with your output it will be a great deal easier to read.
extended device statistics tty
device r/s w/s kr/s kw/s wait actv svc_t %w %b tin tout
md100 0.3 7.0 2.4 7.0 0.0 0.2 38.5 3 4 0 0
2/md3100 205.0 27.4 23099.6 472.2 0.0 2.5 10.9 0 79
2/md3200 225.3 27.3 24993.8 577.3 0.0 2.6 10.5 0 81
2/md3300 295.8 25.5 31538.0 412.5 0.0 3.1 9.8 0 84
2/md3400 198.3 25.6 21032.9 423.7 0.0 2.2 9.8 0 65
2/md3500 55.0 313.0 2397.5 2425.9 0.0 1.2 3.2 0 93
2/md3600 0.1 19.2 0.8 1440.0 0.0 0.1 5.4 0 10
2/md3700 3.1 0.8 48.8 35.7 0.0 0.0 9.3 0 4
2/md3800 300.4 0.7 30651.9 69.4 0.0 2.6 8.7 0 92
2/md3900 359.9 0.7 35876.8 56.6 0.0 3.3 9.1 0 95
2/md4100 0.6 512.1 9.6 1815.8 0.0 1.2 2.4 0 70
2/md4200 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

1.1 performance problems related to system configuration?

It seems like a lot of people are having serious performance problems with Aperture 1.1 in areas were they didn't have any (or at least not so much) problems in the previous 1.01 release.
Most often these problems occur as slow behaviour of the application when switching views (especially into and out of full view), loading images into the viewer or doing image adjustments. In most cases Aperture works normal for some time and then starts to slow down gradually up to point were images are no longer refreshed correctly or the whole application crashes. Most of the time simply restarting Aperture doesn't help, one has to restart the OS.
Most of the time the problems occur in conjunction with CPU usage rates which are much higher than in 1.0.1.
For some people even other applications seem to be affected to a point where the whole system has to be restarted to get everything working up at full speed again. Also shutdown times seem to increase dramatically after such an Aperture slowdown.
My intention in this thread is to collect information from users who are experiencing such problems about their system configuration. At the moment it does not look like these problems are related to special configurations only, but maybe we can find a common point when we collect as much information as possible about system where Aperture 1.1 shows this behaviour.
Before I continue with my configuration, I would like to point out that this thread is not about general speed issues with Aperture. If you're not able to work smoothly with 16MPix RAW files on G5 systems with Radeon 9650 video cards or Aperture is generally slow on your iBook 14" system where you installed it with a hack, than this is not the right thread. I fully understand if you want to complain about these general speed issues, but please refrain from doing so in this thread.
Here I only want to collect information from people who either know that some things works considerably faster in the previous release or who notice that Aperture 1.1 really slows down after some time of use.
Enough said, here is my information:
- Powermac G5 Dualcore 2.0
- 2.5 GB RAM
- Nvidia 7800GT (flashed PC version)
- System disk: Software RAID0 (2 WD 10000rpm 74GB Raptor drives)
- Aperture library on a hardware RAID0 (2 Maxtor 160GB drives) connected to Highpoint RocketRAID 2320 PCIe adapter
- Displays: 17" and 15" TFT
I do not think, that we need more information, things like external drives (apart from ones used for the actual library), superdrive types, connected USB stuff like printers, scanners etc. shouldn't make any difference so no need to report that. Also it is self-evident that Mac OS 10.4.6 is used.
Of interest might be any internal cards (PCIe/PCI/PCI-X...) build into your system like my RAID adapter, Decklink cards (wasn't there a report about problems with them?), any other special video or audio cards or additional graphic cards.
Again, please only post here if you're experiencing any of the mentioned problems and please try to keep your information as condensed as possible. This thread is about collecting data, there are already enough other threads where the specific problems (or other general speed issues) are discussed.
Bye,
Carsten
BTW: Within the next week I will perform some tests which will include replacing my 7800GT with the original 6600 and removing as much extra stuff from my system as possible to see if that helps.

Yesterday i had my first decent run in 1.1 and was pleased i avoided a lot perfromance issues that seemed to affect others.
After i posted, i got hit by a big slow-down in system perfromance. I tried to quit Aperture but couldn't, it had no tasks in its activity window. However Activity Monitor showed Aperture as a 30 thread 1.4GB Virtual memory hairball soaking-up 80-90% of my 4 cpu's. Given the high cpu activity i suspected the reason was not my 2GB of RAM, althought its obviously better with more. So what caused the sudded decerease in system perfromance after 6 hours of relative trouble free editing/sorting with 1.1 ?
This morning i re-created the issue. Before i go further, when i ran 1.1 for the first time i did not migrate my whole library to the new raw algorithum (its not called the bleeding edge for nothing). So this morning i selected one project to migrate all its raw images to 1.1 and after the progress bar completed its work, the cpus ramped and system got bogged-down again.
So Aperture is doing a background task that is consuming large amounts of cpu power, shows nothing in its activity monitor and takes a very long time to complete. My project had 89 raw images migrated to the 1.1 algorithum and it took 4 minutes to complete those 'background processes' (more reconstituting of images?). I'm not sure what its doing, but it takes a long time and shows no obvious sign it is normal. If you leave it to complete its work, the system returns to normal. More of an issue is the system allows you to continue to work as the background processes crank, compounding the heavy workload.
Bit of a guess this, but is this what is causing people system's problems ? As i said if i left my quad alone for 4 minutes all returns as normal. Its just not normal to think it will ever end, so you do more and compound the slow-down ?
In the interests of research i did another project migrating 245 8MB raws to the 1.1 algorithum and it took 8 minutes. First 5mins consumed 1GB of virtual memory over 20 threads at average 250% CPU usage for Aperture alone. The last three minutes saw the cpus ramp higher to 350%, virtual memory increase to 1.2GB. After the 8 minutes all returned to nornal and fans slowed down (excellent fan/noise behaviour on these quads).
Is this what others are seeing ?
When you force quit Aperture during these system slow-downs what effect does this having on your images ? Do the uncompleted background processes restart when you go to try and view them ?
If i get time i'll try and compare to my MBP.

10.6 Performance Problems

Although I installed Snow Leopard from scratch, I encountered severe performance problems after a while. To copy a file, for instance, took minutes instead of seconds for a some 100 MB file. To switch between windows took long time. The processing was interrupted by waiting loops every few seconds. And so on.
I looked around in various forums to find hints how to solve this problem, but nothing worked. The activity monitor doesn't show anything unusual; from its point of view everything is fine.
In the meantime, I reinstalled again Snow Leopard from scratch. After installing iLife 08, I now have the impression that some Finder operations are again getting slower. This may be a trace to the reason for that performance problems. However, this only affects the file copying times, not the application performance, so this does not explain the full picture
So my question: does anyone else - having performance problems with SL - has similar observations in combination with iLife 08? Does anyone else have similar performance problems and solved them?
Regards,
Hardy

Sometimes the performance of the system is impacted by permission errors, I would recommend running Disk Utility and repair permissions, also, just in case... check the disk to make sure you don't have nay bad sectors. You can also use a system utility to optimize system performance, Onyx is a good utility that is also free, just make sure to download the appropriate version for your system. http://www.titanium.free.fr/pgs2/english/download.html

A017 performance Problem

Hi all
I am facing performance problem, While selecting field 'DATAB' ( Validity start date of the condition record ) from Pooled table 'A017',I am getting timed out error ( slong ).IS there any efficient way to retrieve data.
Regards
Sreenivasa Reddy

Hi,
follow below condition to improve performance
1) Remove * from select
2) Select field in sequence as defined in database
3) Avoid unnecessary selects
i.e check for internal table not initial
4) Use all entries and sort table by key fields
5) Remove selects ferom loop and use binary search
6) Try to use secondary index when you don't have
full key.
7) Modify internal table use transporting option
8) Avoid nested loop . Use read table and loop at itab
from sy-tabix statement.
9) free intrenal table memory wnen table is not
required for further processing.
10)
Follow below logic.
FORM SUB_SELECTION_AUFKTAB.
if not it_plant[] is initial.
it_plant1[] = it_plant[].
sort it_plant1 by werks.
delete adjacent duplicates from it_plant1 comparing werks
SELECT AUFNR KTEXT USER4 OBJNR INTO CORRESPONDING FIELDS OF TABLE
I_AUFKTAB
FROM AUFK
FOR ALL ENTRIES IN it_plant1
WHERE AUFNR IN S_AUFNR AND
KTEXT IN S_KTEXT AND
WERKS IN S_WERKS AND
AUART IN S_AUART AND
USER4 IN S_USER4 AND
werks eq it_plant1-werks.
free it_plant1.
Endif.
ENDFORM. "SUB_SELECTION_AUFKTAB
Regards
Amole

Performance problem on free chacteristics

Similar Messages

Maybe you are looking for