Again, the issue with the LOH is that its objects are only collected after a full GC. This is fine for long-lived objects. But short-lived objects, such as those allocated and released during execution of an ASPX page, are bad for the LOH. The GC performs well because Gen 0 is quick to collect, which means that short-lived objects are normally very easy to collect, and that memory can be used again. If however you exceed the current LOH threshold of 85000, your object won’t be collected until after Gen 0, Gen 1, and Gen 2 are collected. A full collection like this takes a long time and is expensive to do. If you allocate too many short-lived objects in the LOH, your Gen 0 to Gen 1 to Gen 2 ratio becomes flat (1:1:1), and your performance will be very bad. Unfortunately there’s no simple solution to this problem, and it seems the best we can do is alert people to the problem and possibly increase the threshold on x64 servers. In particular, framework builders and application service providers should be aware of this issue. The only solution for them is to chain smaller buffers together, and avoid exceeding the 85000 limit. And if it’s an object, not a buffer (byte array), that they’re allocating, they should consider redesigning that object to work around this LOH issue.