Too many heap sections как исправить

Today, after getting like 20+ times the error "Too many heap sections", I began to be very frustrated with the fact that my game crashes every 5-10 minutes, so I tried to find why this error always spawn on my face, and by what it is caused. I found out that the game have a 900 mb of RAM of allocated memory, and by reading plenty of review and error crashes, this 900 mb is capped very easily and very fast. So I tried to boost that 900 mb so that my game crash less and less. By a simple Steam command, you can boost the allocated memory for a game and get a more fluid game, whatever the game is.

These are the simple steps for boosting the heapsize :
1.Go on your Library, right-click on Castle Story and select "Properties"
2.Go on General tab, and click on "Set Launch Options"
3.Type "-heapsize 786432" on it

I can’t remember what 786432 means, but I know that is upgrading the allocated memory to 1.5GB of RAM

Thanks for watching, and hope it’ll do the job for you all
Lol@YourFace

Aujourd’hui, après avoir eu le bug "Too many heap sections" trop de fois, je suis devenu vraiment frustré,donc j’ai essayé de découvrir pourquoi cette erreur apparaît trop souvent, mais surtout par quoi elle est provoquée. J’ai trouvé, après maintes recherches, que ce jeu a une mémoire allouée de 900 mb, et qu’en plus cette limite est atteinte beaucoup trop vite. J’ai donc décidé de trouver un moyen d’augmenter cette limite facilement. J’ai trouvé que l’on pouvait le faire avec une commandee Steam, que l’on édite dans les optiosn de lancement du jeu.

Voici les étapes simples pour augmenter la mémoire alloué, et cela fonctionne pour n’importe quel jeu :
1.Allez dans votre Bibliothèque, faites un clic droit sur Castle Story et allez sur "Propriétés. "
2.Allez dans l’onglet "Générales" et cliquez sur "Définir les optiosn de lancement. "
3.Écrivez "-heapsize 786432" dans cet espace

Je ne me souviens pas ce que le chiffre 786432 veut dire exactement, mais je sais que cela augmente votre limite jusqu’à 1.5GB de RAM

Merci d’avoir pris le temps de me lire, et j’espère grandement de vous avoir aidé
Lol@YourFace

Boehm GC++ garbage collector : Too many heap sections Increase MAXHINCR or MAX_HEAP_SECTS

I am using the Boehm C++ Garbage collector in an application. The application uses the Levenshtein Deterministic Finite Automata Python program to calculate the Levenshtein distance between two string. I have ported the Python program to C++ on version of Centos Linux using gcc 4.1.2.

Recently, I noticed that after I run the application more than 10 minutes, I get the SIGABRT error message: Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS . I was wondering if anyone knew how to fix or work around this problem.

Here is my gdb stack trace. Thank you.

Update:

I looked at Boehm Garbage Collector source and header files and realized that the: Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS error message could be fixed by adding ‑DLARGE_CONFIG to the CFLAGS section in my GNUmakefile.

I tested this change to my GNUmakfile and found that the Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS error message no longer occuured. However I am getting a new segmentation fault (core dump). Using gdb I found that the GDB segmentation fault occured in the following function at line 20 (which I have annotated):

I was wondering if it was possible to modify this function to fix the segmentation fault. Thank you.

Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS when allocating many sets #5610

Hello, I’m hitting an internal limit described in the error message below:

Here’s a simple example that crashes and gets this error message way before it runs out of memory. I ran this on an EC2 instance with 122GB of RAM, the loop got to 17690000 before crashing, and only used 8.6GB of RAM at its peak.

My use case is more complex than this (basically doing a GROUP BY and SUM on large 100MB CSVs), but this error is blocking this task. I’m not sure how to interpret Increase MAXHINCR or MAX_HEAP_SECTS — is there a suggested way to increase this limit?

The text was updated successfully, but these errors were encountered:

No, don’t try the immix gc. Its pre alpha and it will be broken. That’s terrible advice.

The problem is in how libgc is configured, it can only handle heaps of 8gb or less. It needs to be recompiled for large heaps using specific configure options. I’ll work out a process for this and include it in the omnibus and provide a download hopefully later today.

It seems you can set GC_MAXIMUM_HEAP_SIZE=. to the size you want.

I would recommend first trying to find out why you are allocating so much memory, and optimizing that. If you could post the real code you are working on we could help you optimize it.

@asterite some people genuinely need to use 120gb of ram for their datasets. We should support that usecase.

I mean, the CSV is 100MB, you shouldn’t require 120GB to process it.

My simplified code shows the issue more concretely. Abstracting away some of the business-specific logic, my code to do a group by/sum is below.

This should keep only one of the same group in memory at one time, so it builds the sum for the group online. I’m replacing a Python script that does that same thing using a less efficient algorithm that requires much more data stored in memory. Python doesn’t choke on using 120GB+ memory, but I’m rewriting so we can run this on smaller EC2 instances.

The dataset is like:

=> which should output one summarized CSV of all of them. So really this algorithm shouldn’t need 120GB, but the internal representation could be greater than 8GB.

Yeah, there doesn’t seem to be a way around that. I guess the number of different groups is probably huge so you basically have to have a lot of data in memory.

Tweaking the GC is probably good here. If there’s an option to disable that warning/crash, �� from me.

I have the same problem of allocating more than 8 GB.

Is Crystal going to support bigger heap allocation by default?

I could run the program when setting GC_INITIAL_HEAP_SIZE=

GC_INITIAL_HEAP_SIZE probably also adjusts the maximum size accordingly, but what’s really needed here is GC_MAXIMUM_HEAP_SIZE . Of course in your case it might make sense to set the initial heap size to a large value.

I’m not sure if crystal should have a larger max or initial size by default. What would that even be? 8GB seems reasonable for most use cases. When you need more, it’s just a simple environment setting.

Is there a performance advantage for keeping GC_MAXIMUM_HEAP_SIZE low? I’m wondering why it can’t be made arbitrarily large. Also is this environment variable meant to be used at compile time or runtime? And what is the format/units of the variable? I’ve been trying to test it with export GC_INITIAL_HEAP_SIZE=30G this morning and still running into the Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS error after

I’ve tried and errorred with:

I may be the exception, a lot of my use cases involves paging big datasets from memory.

@joeyrobert you’re not the Exception, this is a known and talked about issue, we also do lots of Big Data stuff and we managed to subvert it using the export max heap option

Читать:

Как открыть файл lic

Not necessarily a performance issue. But most typical use cases wont need an unlimited (or very large) heap size. Your’re certainly not an exception but a small minority.

I guess one of the reasons to limit the size by default is, if an application has a memory leak but huge amounts of memory available, the issue will probably not be noticed for a while.

So, IMO it is fine to have a default value limited to a heap size that totally fits 90% of applications and an easy way to change it if you have a higher demand.