4 ms·

> If the FaaS can catch the OOM, restart the instance and re-run the request, the visible effect would be somewhat greater latency for that request. I’m not aw

> If the FaaS can catch the OOM, restart the instance and re-run the request, the visible effect would be somewhat greater latency for that request. I’m not aware of an FaaS that would hide the OOM… that falls under the “not a real thing” category I mentioned previously. It would just be a failed request, which is a very visible effect. Would you like to link me to the Lamda docs that say it will automatically retry the request in case of an OOM? Also consider that code which OOMs will do so unpredictably. It may have completed half of a task, leaving that task in a corrupt state that requires manual intervention from a human to recover from. If everyone wrote fully idempotent code that can somehow skip the already-completed updates and continue where the OOM occurred, this wouldn’t be a problem, but that isn’t what everyone does. This is certainly a large reason why FaaS do not retry requests automatically at all, in most cases. > If the service is configured to automatically kill and restart instances after some time or some number of requests, it seems like a reasonable tradeoff. I don’t believe Lambda has any configuration parameters for those things. That’s not how this is meant to work. Lambda will kill the instance when it has been idle for too long, and that’s the primary factor. You could manually exit the process when your conditions are met, but why? The benefits of turning off the GC are likely to be negligible. This is a lot of complexity for no real gain. It would take some seriously huge gains demonstrated by well-written benchmarks to convince me that any of this is worthwhile for a FaaS function. Grug would rather fight t-rex.[0] If you need absolute performance and control over garbage collection, it’s better to just write the lambda in Rust than to try to hack together a solution by turning off the GC and hoping it doesn’t blow up at the wrong moment. [0]: https://grugbrain.dev/ https://grugbrain.dev/

davidjfelix 3y ago
https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html https://docs.aws.amazon.com/lambda/latest/dg/invocation-retr... Lambda retry docs. I still would strongly not advice intentionally disabling the GC and explicitly said not to above for the same reasons you're concerned.
- coder543 3y ago
  Glad you generally agree. From that link, here are two choice quotes that I think are highly relevant: > When you invoke a function, two types of error can occur. Invocation errors occur when the invocation request is rejected before your function receives it. Function errors occur when your function's code or runtime returns an error. > […] > When you invoke a function directly, you determine the strategy for handling errors related to your function code. Lambda does not automatically retry these types of errors on your behalf. To retry, you can manually re-invoke your function, send the failed event to a queue for debugging, or ignore the error. Your function's code might have run completely, partially, or not at all. If you retry, ensure that your function's code can handle the same event multiple times without causing duplicate transactions or other unwanted side effects. So, it won’t automatically retry if a function is being directly invoked and OOMs, which I believe was the context of my most recent reply. There are a few limited scenarios where certain AWS services that are invoking a Lambda asynchronously will decide to retry a couple of times, because it assumes that this type of function will be okay to call multiple times with the same input. Definitely not something worth relying on.

davidjfelix 3y ago

https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html https://docs.aws.amazon.com/lambda/latest/dg/invocation-retr... Lambda retry docs. I still would strongly not advice intentionally disabling the GC and explicitly said not to above for the same reasons you're concerned.

coder543 3y ago
Glad you generally agree. From that link, here are two choice quotes that I think are highly relevant: > When you invoke a function, two types of error can occur. Invocation errors occur when the invocation request is rejected before your function receives it. Function errors occur when your function's code or runtime returns an error. > […] > When you invoke a function directly, you determine the strategy for handling errors related to your function code. Lambda does not automatically retry these types of errors on your behalf. To retry, you can manually re-invoke your function, send the failed event to a queue for debugging, or ignore the error. Your function's code might have run completely, partially, or not at all. If you retry, ensure that your function's code can handle the same event multiple times without causing duplicate transactions or other unwanted side effects. So, it won’t automatically retry if a function is being directly invoked and OOMs, which I believe was the context of my most recent reply. There are a few limited scenarios where certain AWS services that are invoking a Lambda asynchronously will decide to retry a couple of times, because it assumes that this type of function will be okay to call multiple times with the same input. Definitely not something worth relying on.