Apex heap size too large (when querying less than 1500 records) in a table

edited June 25, 2020 in Questions
I have a table (opportunity line items) with two filters (opportunity record type, and opportunity probability), 7 sortable fields, which pulls through less than 1500 records. The table opens as a popup when a button is clicked.

When I sort the table on any field with no filters on, 1325 records load without issue.Β 

When I sort any field in the table with record type filtered to any value, I face no issue.

When I filter of the probability field, a numeric range filter type, I seem to run into some issues.

If the probability is between 10 and 90. All records are returned and I can sort on any field with no issue.

If the probability is between 11 and 70. All records are returned and I can sort any field with no issue.

If the probability is between 11 and 69. I get an error "Filter could not be applied. Apex heap size too large"

If the probability is between 20 and 60 . I get an error "Filter could not be applied. Apex heap size too large"

If the probability is between 30 and 60. All records are returned and I can sort any field with no issue.

I'm really struggling to understand how to debug this error. Any ideas for me on what could be causing the problem, or any steps I can take to to debug the error (I'm a button click Salesforce admin)

Comments

  • Pat VachonPat Vachon πŸ’ŽπŸ’ŽπŸ’Ž
    edited June 25, 2020
    Hmmmm .... testing these specific ranges gives you consistent results? NO deviations? If so, I've got no idea.

    Have you tried to copy the SOQL out of the model to try the same in SF developer console? If the same error happens here then I'm stumped. I'd additionally want to see the SOQL.

    image

    image




  • edited June 25, 2020
    Glenn, that is pretty confusing, I agree. It sounds like your Model query is right on the edge of consuming the Apex Heap Size limit, which is 6MB. There's a lot that contributes to this limit being exceeded, and only some of it is within your control. Also, we are actively working to reduce Skuid's Apex Heap Size consumption --- the next Millau update release, 11.1.9, will include some changes that should reduce heap size usage significantly, so when that comes out (~ 2 weeks from now) I highly recommend getting that release.Β 

    However, in the mean time, there are a few things you can do to reduce heap size consumption:

    1. Are you only querying for one Model in this page? Or are there multiple Models? If there are multiple Models, it's worth considering whether you can load some of them asynchronously. If however you've only got one Model on the page, then let's dissect what all's going on in that Model.
    2. How many fields are you requesting on your Opportunity Line Items Model? Do you need all of these fields? Each field you remove will contribute significantly to reducing heap size usage, because with each field you request, Skuid has to request field metadata as well as query for that field on every row, so reducing the fields you query for is the most effective way to reduce heap size consumption.
    3. Do you need to load 1500 records into the table on page load? Could you just load, say, 200, and then allow users to request more using "Load More" on the table?

    Hopefully some of these get you started.
  • edited April 10, 2018
    The query I am trying to run is below. When I run it in dev console it returns records.

    SELECT Opportunity.RecordType.DeveloperName, Opportunity.Probability, Product2Id,Product2.Name, OpportunityId,Opportunity.Name,TotalPrice,Opportunity.RecordType.Name, Opportunity.AccountId, Opportunity.Account.Name,Β 
    Name, Opportunity.RecordTypeId, Opportunity.CreatedDate, Opportunity.CloseDateΒ 
    FROM OpportunityLineItem WHERE ((Opportunity.IsWon = TRUE AND Opportunity.CloseDate >= 2017-08-01) OR Opportunity.IsWon = FALSE) AND Opportunity.Probability >= 20 AND Opportunity.Probability <= 60 AND Opportunity.RecordType.Name != 'Grant'

  • edited April 10, 2018
    I have 7 aggregate models, and 1 basic model.

    The basic model pulls through the following fields, all of which are required.

    Opportunity.RecordType.DeveloperName,
    Opportunity.Probability,
    Product2Id,Product2.Name,
    OpportunityId,
    Opportunity.Name,
    TotalPrice,
    Opportunity.RecordType.Name,
    Opportunity.AccountId,
    Opportunity.Account.Name,Β 
    Name,
    Opportunity.RecordTypeId,
    Opportunity.CreatedDate,
    Opportunity.CloseDate

    All of the models need to be called at once. Below is a screenshot of the page.

    image


    I've restricted the number of records loaded for the table that appears when "Show all" is clicked to 200 and it seems to work without error. So I guess it's working fine now, but seems like a small number of records to cause such a problem.
  • edited April 10, 2018
    You apparently edited out a sentence about the user clicking Load More. I wonder if you discovered the Export options for the table and if those settings have any bearing on the issue.
  • edited April 10, 2018
    this is exactly what I've found, and I think it resolves the issue for me. Though I'm still curious why I was hitting limits, it doesn't make immediate sense?
  • Pat VachonPat Vachon πŸ’ŽπŸ’ŽπŸ’Ž
    edited April 10, 2018
    That is strange for sure. The agg models shouldn't be part of this issue.

    This leaves some weird issue that only Skuid can resolve since the query runs without issue in developer console.
  • edited April 10, 2018
    How many records are being returned in the Aggregate models?
  • Pat VachonPat Vachon πŸ’ŽπŸ’ŽπŸ’Ž
    edited April 10, 2018
    Oh yeah... Group by
  • edited April 13, 2018
    I think the aggregate models are pulling through 9 records (see screenshot to make sure i understand you correctly). I don't know if it's worth mentioning, but the basic model orders by two seperate fields, could this be causing problems?






    image







  • Pat VachonPat Vachon πŸ’ŽπŸ’ŽπŸ’Ž
    edited April 13, 2018
    Hmmm ... agg models isn't an issue then. At least I don't think so. Heap size is based on the size of the records package. # of fields per record affects this greatly.

    The Order By w/ 2 fields also shouldn't be an issue.

    Honestly stumped since a query that should return less records is an issue and the a query that should more records isn't an issue.
  • edited June 25, 2020
    If the heap size is affected by the content of the records as much as by the number of records, then the fewer records may be larger (wider?) than the records with the greater quantity. Does the data size of your fields vary significantly?
  • Pat VachonPat Vachon πŸ’ŽπŸ’ŽπŸ’Ž
    edited April 13, 2018
    This can't be the case here since the query returning more records would include all the records from the query returning fewer.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!