Memory leaks due to repeating `str_pad()` in `yii\base\ErrorHandler::register()` method about yii2-psr7-bridge HOT 9 CLOSED

This is a "general" PHP issue, in that PHP was designed to not live beyond a single request if you're thinking about it from an Nginx + PHP-FPM, Apache2 cgi perspective. Yii2 wasn't designed for any request model beyond that so it's fair for them to close that issue. It's not something specific to Yii2 or this framework, just a PHP thing.

I can't fix the memory leak in Yii2, but the application component provides a clean method to handle this. See: https://github.com/charlesportwoodii/yii2-psr7-bridge/blob/master/src/web/Application.php#L247. Basically at the end of each request, check if the current process memory is approaching 90% of the memory setting, then stop the worker and let road-runner handle it.

The example runner in the readme has this in it, ideally place within your main loop at the end of the request. Road Runner will handle creating new workers and redirecting traffic. If you're running multiple works the end-client shouldn't notice that the workers themselves are periodically refreshed.

            
            if ($application->clean()) {
                $psr7->getWorker()->stop();
                return;
            }

This should solve the problem (at least it has in my experience using this), but if it doesn't let me know.

from yii2-psr7-bridge.

Another option might be to add $this->getErrorHandler()->unregister() in the reset() function when the application resets.

If you want to give that a test then submit a MR I can merge that in. I suspect that would resolve this issue specifically.

from yii2-psr7-bridge.

The question is why the error hadler initialization sequence is triggered multiple times.

from yii2-psr7-bridge.

The framework (yii2) (at least with RoadRunner) needs the application reset on each request, and since this was (and is) originally a toy weekend project, a very rudimentary reset method was implemented similar to how yii2/codeception resets the application state.

Reattaching the config incidentally recreates a new error handler among other things. Either of the above solutions would alleviate it.

from yii2-psr7-bridge.

@maximal see deb2044 and let me know is that helps. I won't have an opportunity for some time to setup a profiler.

from yii2-psr7-bridge.

I also suspected some solution dealing with unregister() method as a first approximation.

@charlesportwoodii, thank you, will try that in the nearest future and let you guys know.

from yii2-psr7-bridge.

@charlesportwoodii similar to Codeception/module-yii2#78?

from yii2-psr7-bridge.

@charlesportwoodii, the deb2044 exact code is not working on the first run/iteration, but it seems like I found the closest solution.

Can I post a PR here?

from yii2-psr7-bridge.

Sure

from yii2-psr7-bridge.