We solved this issue by writing a small rack middleware that launches a background thread for every request that sleeps for one second short of the unicorn timeout and then logs some info (including the URL) to a file.
The nice thing about this approach is that you have access to the main thread's information, including env['action_controller.instance'] to get controller params, current user information, app backtrace, etc. That last one in particular has been very valuable in diagnosing complex performance problems. In very high volume applications the thread per request model might be a bottleneck, it could be modified to a persistent buddy thread approach. Carl On Sun, Jan 14, 2018 at 5:27 PM, Sam Saffron <[email protected]> wrote: > I would love to start logging the actual URL that timed out when > murder_lazy_workers does its thing. > > Clearly the master process has no knowledge here, but perhaps if we > had a named pipe from each child to master we could quickly post > current url down the pipe so we would have something to log when we > murder a url. > > Clearly an opt-in thing, but would be very handy for quick diagnostics > cause we can then avoid deeper log analysis and raise events just as > this happens. >
