INADA Naoki <songofaca...@gmail.com> added the comment: > So my understand is that gc frees some objects and makes some memory pages > becomes available to allocate in child process. Allocation on the shared > memory pages will cause the copy-on-write even without gc. > > Though this behavior may have better name?
OK, now I got what you're talking. I don't know proper name about it. I call it as "memory hole" for now. But I don't think "memory hole" is big problem, because we already has refcount. Say there are 100 function objects in one page, and 99 of them are never used. But when 1 of them are called, the page is unshared. Solving memory hole issue is easy: just stop allocating new object from existing pages. But I don't think it's worth enough because of refcount issue. Instead of trying "share most data", I recommend to "use small number of processes" approach. In my company, we don't use "prefork", but "--lazy-app" option of uWSGI for graceful reloading. (e.g. "afterfork") But since we use nginx in front of uWSGI, # of uWSGI worker is just 2* CPU cores. We can serve to massive clients from only 16~32 processes. So I prefer optimizing normal memory usage. It is good for all applications, not only "prefork" applications. In this case, I'm +1 to gc.freeze() proposal because it can be used for single process applications. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31558> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
