12

We have a very slow save happening in Salesforce. Most of the time it succeeds, but is probably just under the CPU limit. If I enable debugging, then the overhead associated with debugging causes it to hit the CPU limit every time. I opened a case with Salesforce and was told this is by design.

I've tried to work around this and collect logs anyways looking for slow triggers, loops, etc. The problem I run into is when I set my log levels to a sufficient level of detail (Debug), my logs get truncated and I can't see the entire picture. In Developer Console, it only shows me 3 seconds worth of Apex code, the rest gets truncated.

Does anyone have any advice on proper log levels to find the loops or slow running process? I've tried trial and error and deactivated all processes, workflow field updates, and custom triggers. I still hit the CPU limit due to a number of managed packages in the org. I can't see the code in those managed packages, but I suspect they are interacting with each other and causing triggers to fire multiple times.

  • 1
    You can ask Salesforce support to increase the log file size truncation limit if you have a good reason (and I think you do). I've had this set to 16M instead of the default 2M. Seeing repeated code might help identify the problem though solving it may remain difficult. – Keith C Nov 24 '15 at 18:34
  • Ah, I have a case open with Salesforce now. At this point, I'm happy with just identifying the areas we need to focus on and hopefully get our vendors involved. Right now they are just pointing fingers at each other. – Daniel Hoechst Nov 24 '15 at 18:35
  • Tough problem. If I remember correctly you should see all the queries done in the org (by the various managed packages) so setting logging to only see those might give you some kind of summary view of the whole code set... – Keith C Nov 24 '15 at 18:39
  • How much, if any, of this is code that you control outside of the managed packages? If you have any triggers of your own in the mix I'd start using the Limit.getCpuTime() in combination with a System.assert(false,...) to track the usage at various point. This approach would only be useful in a sandbox environment. – Daniel Ballinger Nov 24 '15 at 19:39
  • 1
    Another option would be to define multiple Debug Levels. Have one with minimal/no logging and one with debug logging. Then set different levels to different Apex classes and triggers via the trace flags. This should give you increased logging for just a subset of classes of interest. – Daniel Ballinger Nov 24 '15 at 19:41
3

After debug generated(for CPU time error) open that debug log in developer console then, Debug-->Switch Perspective-->Analysis This will help you understand which block of code consumes most of the cpu time.

And if you want to see the debugs then add system.assert() statement followed by the debug statements in the code/block for which you need to check debugs. all debug statements around the system.assert() call will be there in your debug log. For example:

system.debug('***getCpuTime()***'+Limits.getCpuTime());
system.assert(false,'Show debug');
0

Try the log levels set when using force trace start:

ApexCode      => Debug
ApexProfiling => Error
Callout       => Info
Database      => Info
System        => Info
Validation    => Warn
Visualforce   => Info
Workflow      => Info

These are the levels I came up with to get sufficient detail without truncation when troubleshooting similar problems.

This will get you the following events (plus the corresponding end/finished/exit events):

CALLOUT_REQUEST
CODE_UNIT_STARTED
DML_BEGIN
EMAIL_QUEUE
EXCEPTION_THROWN
FLOW_ELEMENT_ERROR
FLOW_START_INTERVIEW_BEGIN
FLOW_START_INTERVIEWS_BEGIN
METHOD_ENTRY
SOQL_EXECUTE_BEGIN
SOSL_EXECUTE_BEGIN
SYSTEM_METHOD_ENTRY
USER_DEBUG
VF_DESERIALIZE_VIEWSTATE_BEGIN
VF_SERIALIZE_VIEWSTATE_BEGIN
WF_CRITERIA_BEGIN
WF_FLOW_ACTION_ERROR

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.