7

Im currently updating lots of records of an SObject having extensive trigger logic and today I've noticed this limit consumption:

Limit Name .................... ┃ ...Actual ┃ ....Maximal ┃ ....Usage 
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
HeapSize....................... ┃ 8'254'161 ┃ ..6'000'000 ┃ ..137.57% 
CpuTime........................ ┃ ....8'061 ┃ .....10'000 ┃ ...80.61% 
DmlStatements.................. ┃ ........2 ┃ ........150 ┃ ....1.33% 
DmlRows........................ ┃ ....3'550 ┃ .....10'000 ┃ ...35.50% 
Queries........................ ┃ .......40 ┃ ........100 ┃ ...40.00% 
QueryRows...................... ┃ ....5'664 ┃ .....50'000 ┃ ...11.33% 
EmailInvocations............... ┃ ........1 ┃ .........10 ┃ ...10.00% 

So far, my understanding was that the 6MB limit for HeapSize is strict. Now it seems, that salesforce is tolerating some kind of exceeding since > 8MB was executed without exception.

Does anyone of you had similar experiences? If so, for which limit and how much of over consumption has worked for you? Is it reliable or random? Or is there any kind of documentation for this I haven't noticed? Of course more heap would be wonderful!

  • My understanding is that the limits are not always enforced but may be enforced so code should be tuned to stay within them. Will be interested to see if anyone can explain why this is. – Keith C Jun 14 at 8:54
  • @KeithC Wild guess: they are test driving the impact of higher limits to their server performance. But would be nice to get some feedback. – Uwe Heim Jun 14 at 9:17
  • I know there was at least one Dreamforce/Trailhead DX session that covered Salesforce's plans to move to a different enforcement model for governor limits, but I don't know if heap size was among the governor limits discussed. I'll try to find a video of the session. – Derek F Jun 14 at 13:22
7

Back at Dreamforce '17, there was a session that outlined Salesforce's plans to restructure how governor limits worked.

The link to the video (for however long it'll be valid) is https://www.youtube.com/watch?v=0wHRmS1j3r4

The talk about "Reimagining Limits" begins at about 19:22 of the video, and heap size is included.

The "Cliff's Notes" for the presentation are:

  • Salesforce re-evaluates their strategies and approaches from time to time
  • And now it's time to re-evaluate limits
  • Salesforce wants to remove some limits, and make others be "thresholds" that are enforced based on how much activity is on your pod, how far you exceed the threshold, and how often you exceed the threshold
  • CPU, Heap, Database, and Concurrent Transactions are all explicitly mentioned as being targets for the new "thresholds" approach
  • There is a base threshold, and we're allowed to exceed that by some unknown % which is tied to activity on your pod
  • 24:35 of the video goes into some good examples of what Salesforce may look for when enforcing/notifying about thresholds (one time, under enforcement threshold => no notification. Multiple days just over the threshold => get notified to improve yer code)
  • This was supposed to be fully rolled-out in Summer '18 (i.e. one year ago)
0

The way heap limits appear to be enforced often allows you to break it without any consequence but obviously probably not good practice to rely on this. I would be looking to assign null to any references to objects that you don't need anymore to try and reduce usage below the limit or cut your volume if not possible.

You can also overrun the CPU limit a bit but this is much more likely to cause an exception. Think most of the other limits don't have any flex. Not seen any changes in how these have worked for last few years but you never know.

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.