High CPU response times, altough low CPU utilization

Hi Friends,
We have a performance problem after we migrate our basis system,
The current system is :
Database server : Sun SPARC Enterprise T5240 Server - 2 CPU's with 6 core, 8 thread, 1.2 Ghz
32 GB RAM
and we use another identical configured server as an application server.
Database is Oracle 10.2.0 and operating system is Solaris 10.
The problem is average CPU response time is 450 ms, and max. CPU load is %5 percent.
Pre-migration configuration with old servers, we had CPU response : 150 ms and max CPU load: 50%.
Has anyone of you, have experinced a similar problem with this new CPU's?
Thanks in advance

> I am aware that there might be lots of reasons, but what I guess is, there should be a parameter wrong with the CPU settings. This SPARC server CPU is a new tech. 6 core 8 thread one, which is expected to work much faster than the old simple dual core CPU.
Is it?
ABAP is basically a virtual machine and what is most important: ABAP runs single threaded. This means in consequence that the processing time of a program relies on the single processing power of one core. More cores means more parallelism but the speed of the single statement always relies on the power of one core and how fast it can get the data over the bus and back. So the significant number for speed is basically the Mhz (for ABAP, Java is very different).
Your old machine may have had a DualCore SPARC 1,2 Ghz and the new machine has one 1,4 Ghz 6core CPU (assuming so).
> However its response time is very high, although it is never utilized more than %5 percent.
see above.
> The problem might be at database settings(Oracle 10.2.0) or at Solaris ? ? ?
Well - no - I don't think so
Since ABAP is a single threaded application it can't leverage the CPU power due to the fact, that a parallelism in the program itself does not take place and hence the machine scales not linear with the number of cores. So you may have factually a machine with about 1 dot something CPUs and not 6 as you would expect.
This is not specific to SPARC CPU design but for all multi-core systems. A single threaded application is only as fast as the CPU speed. ABAP programs tend to be huge so you will also see effects of cache displacement and bus congestions. Less cores and more physical CPUs perform much better than any multicore CPU.
For Java the world is very different because Java works as one process (in the SAP case jlaunch) which has many many threads that can be executed in parallel on different pipelines on the CPU.
Unfortunately this is a design problem and there's not much you can do about it.
Markus

Similar Messages

"Windows 8 using 100% of HDD with high average response times and low read/write speed"

Turns out this is a fairly well known windows 8.1 issue that has been plaguing users since at least 2013 and there is no one simple fix, so it may not be *entirely* hp's fault; but I've had two of these laptops, both the same model, the first one needing to be returned and exchanged for an entirely unrelated issue (hardware failure: ethernet port nonfunctional with lights stuck on). Both are refurbished. Both have been extreemly slow and unresponsive even compared to a lesser Brazos powered laptop I had before, but I've only recently decided to investigate why.
So if there is something HP specific going on here, I hope there is one simple fix. My average response time has gone up as far as well over a minute (>60,000ms), so I may be an outlier case here compared to the typical windows 8.1 hardrive responsiveness/bandwidth problem.
Edit: there is a case with another HP pavilion laptop (intel powered though, so it may be an intel storage driver issue described in the first link) being much, much worse.
This question was solved.
View Solution.

Guess what just now happened again
So using DISM did _not_ fix it.

High RFC response time in SAP BW system

Hello all,
How to analyze and fine tune high RFC response time in SAP BW system ?
Regards,
Archana

Hi
Kindly Check follows
1. Check the RFC connections are correctly Configured or not? You can execute the program “RSRFCTRC” and get a full log of the RFC connections details
2 you can check the BW queries are right optimized? Is this any network issues?
3. In which time are you facing the high rfc response? (During the 24 hours which time)?
4. Kindly refer the SCN & SAP Notes for overall system performance
Short Notes on PERFORMANCE MONITORING - ABAP Development - SCN Wiki
1063061 - Information about response time in STAD/ST03
948066 - Performance Analysis: Transactions to use
Regards
Sriram

High Update Response Time ticket from solman

Hi Experts,
We have monitoring setup from solman. We are getting an alert for ECC prod that the there is High Update Response Time. Can you please let me know how to fix it?
Thanks,
Asad

Hi Asad ,
How many update work process do you have . See a high amount of wait time for the update process
You may increase their number if you have enough memory .
Go to SM13 , Go to -> Administration of update system
Goto - > Statistics
Response Times: Rules of Thumb - CCMS Monitoring - SAP Library
Less than 1 second is the recommended , though sometimes you may breach it .
Thanks ,
Manu

High Update Response Time

Hi folks,
how could I to check the High Update Response Time
Thanks.

Hi Carlos,
Goto ST03 and check from there.
That link was posted by mistake.
Divyanshu

High Avg Response time for logon requests via CMS

Hi Team ,
We are continuously receiving observing high Average reponse time for logon requests to the BO system via Central Management Server.
We observe response time up to 25043 ms .
Currently we are on SAP BO 4.0 SP7 patch 9 (4.0.7.9)
DB = SQL server 2008 R2
App Server = SAP NW 7.31 SP 7.
Also the size of our CMS DB is around 15 GB .
What could be the possible reasons ?
Regards ,
Abhinav

Hi Abhinav,
As one of the issues has been raised as a bug which is resolved in BI 4.1 so you can upgrade to resolve this bug. Also if the CMS database size is large then CMS has to search for objects through huge number of rows hence that will affect overall performance. So you can try to reduce this size as per my previous upate.
Apart this you can try following steps
Try to ping CMS DB server from BO servers and confirm the response is coming in 1 ms. Run tracert <DB servers name> from CMD and check the number of hops. If response time is not 1 ms or there are more number of hops then ask your network team to resolve network latency issue
You can increase the "System database connections" for each CMS from server properties. It is set to 14 by default which means the CMS will establish 14 connections to CMS database at any time. You can increase this value, however please make sure that the system database allows more connections than default 14 from DB side. This needs to be confirmed from your DBA.
Please add CMS cluster members in platformservices.properties file under Tomcat folder. Please refer following SAP KBA for steps to add the cluster members
       http://service.sap.com/sap/support/notes/1668515
       http://service.sap.com/sap/support/notes/1766935
   4. Also please confirm number of users simultaneously login to system at peak time. Usually one           CMS is capable of handling around 500 requests. So if you have more then 1000 users then add           another new CMS on same nodes if there is enough free memory on the server
Regards,
Hrishikesh

High Dialog response time

Hi,
We have a solman 4.0 system. The average dialog response time of the system is very high. What can be done to bring down this response time??
Thanks in Advance
Amit.

Hi Amit,
Please check out the breakdown of dialog response time in Workload Monitor. Also, use the Time Profile to check if this high response time is at specific timings.
regards, Shantanu

Virtual Machine - high disk response time

Hi Everyone,
Got something strange happening in our lab at the moment and was wondering if anyone had experienced the same thing (and maybe has a solution).
Our lab environment in a nutshell:
2x Windows 2012 Hyper hosts cluster connected to a "home-made" SAN based on Windows 2012 iSCSI target.
Each Hyper-V host has two 1Gbps network cards to connect to the SAN via the Microsoft iSCSI initiator, with MPIO in load-balancing mode (least queue depth).
The SAN (Windows 2012 server with iSCSI target) has 4x 1Gbps cards, teamed two by two, so presenting two IP addresses used by each hosts to connect to it (via MPIO).
The disk subsystem on the Windows 2012 SAN is an external HP storage works with 25x HP 500 SATA disks, connected to the server via an INTEL RAID controller with 2x 240GB SSD caching enabled for read/write.
The iSCSI network is on a dedicated HP switch, with flow-control and jumbo frame enabled (tested ok).
Now the problem:
I've built a few virtual machines on the two hyper-v nodes and I'm getting very bad disk response time as soon as there is an increase in the disk traffic.
When the virtual server is doing very little, I get a normal 6-8ms, but I soon as I increase the traffic (by for example copying a big file, or installing an application), this figure shoots up to 200ms, 300ms and more!
So I first thought that it was my disk subsystem (and the SAN server), but while the spikes are happening within the virtual machine, the disks on the SAN Server are sitting at about 10ms, with some spikes to about 20ms (which is pretty good and what I would
expect to see within the VM because of the SSD cache).
I then thought it could be the network, but during those times of activity, the network does not get saturated at all. Barely 150Mbps to 200Mbps per link.
I even tried to disable MPIO and run everything across one Ethernet link, but still the same result.
Am I missing something here? doing something wrong? or is this expected behaviour?
Thank you,
Stephane

Hi,
VR38DETT is right, if you want to use more ISCSI bandwidth or redundancy you must use the MPIO method, Multipath I/O (MPIO) is a feature that provides support for using multiple
data paths to a storage device. Multipathing increases the availability of storage resources by providing path failover from a server or cluster to a storage subsystem.
More information:
Multipath I/O Overview
http://technet.microsoft.com/en-us/library/cc725907.aspx
Support for Multipath I/O (MPIO)
http://technet.microsoft.com/en-us/library/cc770294.aspx
Hope this helps.
Alex Lv

Response times (PING) very high with CAP3602i access point

I have installed an access point CAP3602i in mode HREAP a controller Model 5508 with version 7.4.100.0 but the response times of the connected users are very high.
The less users are connected to the access point is faster surfing the internet and response times are low. But if there are many users connected, increase response times.
I'll be grateful someone comments any experience with this problem.
Thanks

We are talking about 15 users per AP, but that everything is surfing the internet and not so heavy downloads before aps 1141 and had had no such problem response times were normal between 2,3,4 ms
There is performing some function more cap3602i ap causes high response times.
Supposedly CAP3602i I say are better than the 1141, which is why we made the change but we found with surprise that high times.
The SSID was HREAP doubt it has anything to do with the 1141 does not give the issue of high times.

High GUI Time - Causing high Response time

Hi All,
Average GUI Response time is approx 400 ms in my ECC 6.0 system, OS - HP UX, Database - Oracle 10.2.0.5.
I expect it should always be approx 200 ms, but as it is high it is contibuting to high overall response time.
I expect there are normally two ways of high GUI time :
1) High network time between Presentation layer( User System) and Application Layer(SAP Server).
2) High amount of time in Loading User Screen
For Option 2 I have checked we are using SAP access menu so there should not any problem with loading of User Access Menu.
Average Response time for session_manager is 2 Secs.
Please suggest me what all other ways available to improve GUI time,
Can there be other reasons of high GUI time and how can we make sure that high GUI time is only because of high Network time.
Please suggest.
Shivam

I believe in case you have multiple roundtrips per step, then the client performance comes into play as well. So if you have slow clients this could be an issue too.
Basically you are already looking in the right place (network connection), but i recommend you also check:
- roundtrips per step and amount of data sent to the client
- are all transactions having high gui times, or only a few?
- how is the situation on the clients?
- if you have clients working on prod and qas check the values on the qas system too
Cheers Michael

Reduce Dialogue response Time

Hi Friends,
ST03N transaction is showing very high dialogue response time for my ERP system.
On doing further analysis in STAD , i found the SQL queries (DB response) time is fine. Is there any way i can reduce the time. Increasing the CPU capacity is not an option.
Please advice.

Hello,
Performance tuning can be a complex thing, you have to find where the bottleneck is e.g.:
-Memory/paging (OS)
-SAP buffers (ST02)
-to few work processes (SM51)
-user behaviour
-disk I/O
Take a look at:
http://wiki.sdn.sap.com/wiki/display/ABAP/Performance+Tuning
There are also some good SAP Press books about this available.
regards
Christian

Strange response time for an RFC call viewed from STAD on R/3 4.7

Hello,
On our R/3 4.7 production system, we have a lot of external RFC calls to execute an abap module function. There are 70 000 of these calls per day.
The mean response time for this RFC call is 35 ms.
Some times a few of them (maybe 10 to 20 per day) are way much longer.
I am currently analysing with STAD one of these long calls which lasted 10 seconds !
Here is the info from STAD
Response time :                10 683 ms
Total time in workprocess : 10 683 ms
CPU time :                               0 ms
RFC+CPIC time :                       0 ms
Wait for work process           0 ms
Processing time           10.679 ms
Load time                            1 ms
Generating time                   0 ms
Roll (in) time                        0 ms
Database request time         3 ms
Enqueue time                      0 ms
Number      Roll ins            0
                 Roll outs           0
                 Enqueues         0
Load time   Program             1 ms
                  Screen              0 ms
                 CUA interf.          0 ms
Roll time    Out                 0 ms
                  In                  0 ms
                Wait                0 ms
Frontend    No.roundtrips       0
                  GUI time            0 ms
                  Net time            0 ms
There is nearly no abap processing in the function module.
I really don't uderstand what is this 10 679 ms processing time especially with 0 ms cpu time and 0 ms wait time.
A usual fast RFC call gives this data
23 ms response time
16 ms cpu time
14 ms processing time
1 ms load time
8 ms Database request time
Does anybody have an idea of what is the system doing during the 10 seconds processing time ?
Regards,
Olivier

Hi Graham,
Thank you for your input and thoughts.
I will have to investigate on RZ23N and RZ21 because I'm not used to use them.
I'm used to investigate performance problems with ST03 and STAD.
My system is R/3 4.7 WAS 6.20. ABAP and BASIS 43
Kernel 6.40 patch level 109
We know these are old patch levels but we are not allowed to stop this system for upgrade "if it's not broken" as it is used 7/7 24/24.
I'm nearlly sure that the problem is not an RFC issue because I've found other slow dialog steps for web service calls and even for a SAPSYS technical dialog step of type <no buffer>. (what is this ?)
This SAPSYS dialog step has the following data :
User : SAPSYS
Task type : B
Program : <no buffer>
CPU time                       0 ms
RFC+CPIC time              0 ms
Total time in workprocs    5.490 ms
Response time               5.490 ms
Wait for work process           0 ms
Processing time             5.489 ms
Load time                            0 ms
Generating time                   0 ms
Roll (in+wait) time                0 ms
Database request time          1 ms ( 3 Database requests)
Enqueue time                       0 ms
All hundreds of other SAPSYS <no buffer> steps have a less than 5 ms response time.
It looks like the system was frozen during 5 seconds...
Here are some extracts from STAD of another case from last saturday.
11:00:03     bt1fsaplpr02_PLG RFC     R     3     USER_LECKIT     13     13     0     0
11:00:03     bt1sqkvf_PLG_18      RFC     R     4     USER_LECDIS     13     13     0     0
11:00:04     bt1sqkvh_PLG_18      RFC     R     0     USER_LECKIT     19     19     0     16
11:00:04     bt1sqkvf_PLG_18      RFC     R     4     USER_LECKIT     77     77     0     16
11:00:04     bt1sqkve_PLG_18      RFC     R     4     USER_LECDIS     13     13     0     0
11:00:04     bt1sqkvf_PLG_18      RFC     R     4     USER_LECDIS     14     14     0     16
11:00:05     bt1sqkvg_PLG_18      RFC     R     0     USER_LECKIT     12     12     0     16
11:00:05     bt1sqkve_PLG_18      RFC     R     4     USER_LECKIT     53     53     0     0
11:00:06     bt1sqkvh_PLG_18      RFC     R     0     USER_LECKIT     76     76     0     0
11:00:06     bt1sqk2t_PLG_18      RFC     R     0     USER_LECDIS     20     20     0     31
11:00:06     bt1sqk2t_PLG_18      RFC     R     0     USER_LECKIT     12     12     0     0
11:00:06     bt1sqkve_PLG_18      RFC     R     4     USER_LECKIT     13     13     0     0
11:00:06     bt1sqkvf_PLG_18      RFC     R     4     USER_LECKIT     34     34     0     16
11:00:07     bt1sqkvh_PLG_18      RFC     R     0     USER_LECDIS     15     15     0     0
11:00:07     bt1sqkvg_PLG_18      RFC     R     0     USER_LECKIT     13     13     0     16
11:00:07     bt1sqk2t_PLG_18      RFC     R     0     USER_LECKIT     19     19     0     0
11:00:07     bt1fsaplpr02_PLG RFC     R     3     USER_LECKIT     23     13     10     0
11:00:07     bt1sqkve_PLG_18      RFC     R     4     USER_LECDIS     38     38     0     0
11:00:08     bt1sqkvf_PLG_18      RFC     R     4     USER_LECKIT     20     20     0     16
11:00:09     bt1sqkvg_PLG_18      RFC     R     0     USER_LECDIS     9 495     9 495     0     16
11:00:09     bt1sqk2t_PLG_18      RFC     R     0     USER_LECDIS     9 404     9 404     0     0
11:00:09     bt1sqkvh_PLG_18      RFC     R     1     USER_LECKIT     9 181     9 181     0     0
11:00:10     bt1fsaplpr02_PLG RFC     R     3     USER_LECDIS     23     23     0     0
11:00:10     bt1sqkve_PLG_18      RFC     R     4     USER_LECKIT     8 465     8 465     0     16
11:00:18     bt1sqkvh_PLG_18      RFC     R     0     USER_LECKIT     18     18     0     16
11:00:18     bt1sqkvg_PLG_18      RFC     R     0     USER_LECKIT     89     89     0     0
11:00:18     bt1sqk2t_PLG_18      RFC     R     0     USER_LECKIT     75     75     0     0
11:00:18     bt1sqkvh_PLG_18      RFC     R     1     USER_LECDIS     43     43     0     0
11:00:18     bt1sqk2t_PLG_18      RFC     R     1     USER_LECDIS     32     32     0     16
11:00:18     bt1sqkvg_PLG_18      RFC     R     1     USER_LECDIS     15     15     0     16
11:00:18     bt1sqkve_PLG_18      RFC     R     4     USER_LECDIS     13     13     0     0
11:00:18     bt1sqkve_PLG_18      RFC     R     4     USER_LECDIS     14     14     0     0
11:00:18     bt1sqkvf_PLG_18      RFC     R     4     USER_LECKIT     69     69     0     16
11:00:18     bt1sqkvf_PLG_18     RFC     R     5     USER_LECDIS     49     49     0     16
11:00:18     bt1sqkve_PLG_18     RFC     R     5     USER_LECKIT     19     19     0     16
11:00:18     bt1sqkvf_PLG_18     RFC     R     5     USER_LECDIS     15     15     0     16
The load at that time was very light with only a few jobs starting :
11:00:08 bt1fsaplpr02_PLG RSCONN01                     B 31 USER_BATCH     39
11:00:08 bt1fsaplpr02_PLG RSBTCRTE                     B 31 USER_BATCH     34
11:00:08 bt1fsaplpr02_PLG /SDF/RSORAVSH                B 33 USER_BATCH     64
11:00:08 bt1fsaplpr02_PLG RSBTCRTE                     B 33 USER_BATCH     43
11:00:08 bt1fsaplpr02_PLG RSBTCRTE                     B 34 USER_BATCH     34
11:00:08 bt1fsaplpr02_PLG RSBTCRTE                     B 35 USER_BATCH     37
11:00:09 bt1fsaplpr02_PLG RVV50R10C                    B 34 USER_BATCH     60
11:00:09 bt1fsaplpr02_PLG ZLM_HDS_IS_PURGE_RESERVATION B 35 USER_BATCH    206
I'm thinking also now about the message server as there is load balancing for each RFC call ?
Regards,
Olivier

WebDynpro SSR / Browser Response Time

Good morning,
When we are visualizing a WebDynpro view we take an unacceptable response time (of almost 1 minute) and the CPU of the computer client rises almost until the 100%.
The View is composed by a menu to the left (which is a embedded view )and a main view, which is formed by a group that contains a Table within a ScrollContainer. So, the view is not much complex.
The table is mapped to a simple structure whose attributes are simple objects (string) and the maximum table record size is 100.
Additionally whenever any event takes place, either or in the menu of the left or the own table, the response time remains in 1 minute although business logic is not executed.
We have proven to delete the ScrollContainer and show the table but the performance doesnt improve. We have also tested that communication network problems doesnt exist.
The performance of the client browser has been verified including the SSR parameter (sap.session.ssr.showInfo=true). A document with an
image is attached, it is possible to see that the browser response time is 45 seconds to display a content of 1 MB (isn´t it too much?? Why WD generates too much HTML??).
SAP WAS 6.40 y SP15
Browser:Internet Explorer 6.0.2800.1106 SP1
Thanks in advance,
Eloy

Hi Eloy,
We also faced a similar problem in our project. When the page size reaches 0.5MB+ the reposonse becomes too slow.
This is becuase WebDynpro gets marshalled data from backend and unmarshlles it based on your screen design. So in your case if you have 100 rows * 50 columns it will unmarshall all these records at front-end i.e, the client. Hence you see the response time of your CPU reaching 100 %
You have very few options
1) Decrease the no of visible rows on the screen at a time. Say max 10. If you have 40-50 columns explore using Tab Strips with 12-15 columns in each tab.
2) Increase the RAM and Processing capabilities of your Client PC's. We were kind of lucky that our customer agreed to this and got P4 1GB machines.
Lets hope the performance is improved in the future releases.
Regards,
Shubham

High time consumption and CPU utilization on EPM 11.1.2.1

We are using a distributed environment for EPM system 11.1.2.0, in which, on system A, Foundation services and Planning have been installed and on system B, Essbase, Admin Services and Provider Services have been installed.
The configuration for the two systems is as mentioned below :
System A:
intel Xenon CPU X7560 2.27 GHz (dual core)
12 GB RAM
System B:
intel Xenon CPU X7560 2.27 GHz (dual core)
8 GB RAM
A business rule takes 15 minutes on being executed on version 9.3.1; whereas the time consumed on system 11.1.2.1 varies from 3 hours (mostly) to 10 minutes.
This business rule aggregates 5 dimensions (1 dense and 4 sparse). It does not create any new blocks and intelligent calc is also set to off.
Although the cache and memory values on the newer system are higher than the previous version, we fail to reduce the time consumption and CPU utilization. Please help us resolve this issue.

Your issues is beyond the scope of a forum. I suggest you find an infrastructure person who has Essbase experience. Your machines also have less resources than the standard deployment guide recommends.
This would appear to either be lack of physical memory or an issue with the IO speed of the disk subsystem which you are storing your Essbase data on.
Regards,
John A. Booth
http://www.metavero.com

Higher response time after adding more CPU

Hello all,
have you ever experienced that after incresing SAPs (adding 2 more CPU + 4 GB of memory) on the VMware ESX 3.5 the DB response time went from 150 to 400-500 ms ? NO DB parameter were changed. In app server, only extended memory and program buffer were enlarged.
We are running ECC6 system on MAXDB 7.6.6.3 (SLES9). MAXCPU is set to 1
Any idea ?
Thank you.
Pavol
Edited by: Pavol Simko on Jul 28, 2009 10:35 AM

> We are running ECC6 system on MAXDB 7.6.6.3 (SLES9). MAXCPU is set to 1
I'd always set MAXCPU to the number of physical CPUs/cores you have. It's VERY unlikely that the database will use more CPU than the application.
The database can't scale, if one CPU is used other requests have to wait.
Markus

High CPU response times, altough low CPU utilization

Similar Messages

Maybe you are looking for