Post History

Generally speaking, the frequency of garbage collection is a space / time tradeoff:


                  collection effort   live object size
    GC overhead ~ ----------------- = ---------------- 
                     memory freed     dead object size 

In defaulting to collect garbage only when memory is starting to get scarce, the runtime maximizes dead object size, and thus the efficiency of collection. 

When determining whether memory is scarce, the runtime assumes that the Operating System's (or container's) free memory is available for use. In your case, this isn't the case, because you want to share that memory with many other applications. The typical response would be to tell the runtime how much memory it is allowed to use by setting `System.GC.HeapHardLimit` (or `System.GC.HeapHardLimitPercent`). It is worth noting that these settings set the maximum size of the heap, which is only part of the total memory used by your process. In particular, the just in time compiled executable code, as well as any native memory used, does not count towards that limit, so if you are aiming for 1GB total memory, you should be setting the heap limit quite a bit lower than that (as a rough guideline: if not specified, the max heap size [defaults to 75% of available memory](https://docs.microsoft.com/en-us/dotnet/core/run-time-config/garbage-collector#heap-limit-percent)).

For applications with very dynamic live object sizes, better collection efficiency may be achieved by manually triggering collection when live object size is particularly low (and dead object size is considerable). Whether this is true for your file upload depends on how significantly the file upload affects the overall live object size, and how easy it is to identify times where no file upload is running (which may be non-trivial due to concurrency). It may be easier to simply set a heap size limit instead.