| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
When `pipeline(callback)` or `transaction(callback)` is called repeatedly in a long-lived coroutine (e.g. while(true) loop), each call registers a new `defer` closure via `__call()`, but the outer `executeMultiExec()` finally block immediately clears the context connection. Since `Context::has()` uses `isset()` which returns false for null values, the next call sees no existing connection and registers yet another defer. These defer closures accumulate indefinitely because the coroutine never terminates, causing a slow memory leak. Fix: Move the `Context::has()` check into the finally block so it evaluates after `__call()` has stored the connection. This way the connection stays in context and is reused on subsequent calls, with only one defer ever registered per coroutine. Made-with: Cursor
|
此改动 如果是一个while true协程 多次调用 transaction/pipeline 没有问题,在defer才释放redis;不会多次注册defer函数; |
Sorry, something went wrong.
确实存在这个问题。 我看了单测的代码,3个连接,但是启动了20个协程并发,因为连接的释放是在defer中才释放,而不是在每次命令执行完成之后释放,所以连接池会耗尽。 看了下连接复用是想要在 pipeline 和 multi 等场景中使用同一个链接,Redis::__call 内部的复用应该放到外层来。 我先看看代码,大佬们看下有没有什么建议。 |
Sorry, something went wrong.
Sorry, something went wrong.
|
我想了一下,如果还是放 defer 释放,那么只要连接复用生效,那么多个协程并发仍然会出现连接池耗尽的情况。之前之所以能通过测试用例,就是每次命令执行完毕之后,链接都释放了。 如此说来,需要在每次执行完毕后,立即归还链接。但是我没想好怎么改,以及影响范围。 顺便mark下,defer泄漏由此次优化引入:#7394 |
Sorry, something went wrong.
|
使用 Context 标记了当前 pipeline 的执行方式,如果是 callback 方式执行的,则不需要设置 defer 来释放连接。 |
Sorry, something went wrong.
Made-with: Cursor
Made-with: Cursor
…e methods Made-with: Cursor
|
代码我合进来了,你测试下,我改了一行代码。 |
Sorry, something went wrong.
|
测试了下,没问题 |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
fix: #7733