4 ms·

When exactly is this new GC behavior useful? When forking processes? Is it something we'd see used in the multiprocessing or concurrent modules?

• bpicolo 9y ago
  Memory is typically the scaling bottleneck for Python workers for web servers. One way to cut back drastically on this is to load as much as possible in startup and then fork for request serving processes. The problem is that python refcounting causes a lot of copy-on-writes for data that's really just used as read-only data. This change allows you to run more workers with less memory. Instagram has had a few good posts about how they've approached this problem, here's another: https://engineering.instagram.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172 https://engineering.instagram.com/dismissing-python-garbage-...
  • sametmax 9y ago
    > Memory is typically the scaling bottleneck for Python workers for web servers. Wut ? When I have performances problems, my RAM is full with varnish cache, redis stored objects and postgres buffer. Python is like, low, low on the list. Again, most people are NOT instagram or Google. They have a very atypical load.
    • bpicolo 9y ago
      That's latency, not bandwidth. This is to help scale out concurrent request counts per box, rather than time to serve a single request (though obviously with request queuing, failure to serve requests fast enough makes concurrency a latency bottleneck). And sure, most people aren't instagram. This is a python-at-big-scale problem, when the cost benefits of fitting more requests onto fewer servers actually matter. One of the biggest reasons this actually makes a difference is that, in SoA, internal API scaling against your monolith can become expensive.
    • ComputerGuru 9y ago
      > Again, most people are NOT Instagram or Google And, again, can we stop with these pointless comparisons? Past 1 front end server the only cost that matters is how many requests your one node can handle and how much that one node costs. If you’re not a VPS and you have your frontend http cache correctly configured, then it doesn’t matter how much smaller than Google you are, comparisons are valid (although, of course, the fewer servers you have the more you can afford to spend on them; though you probably aren’t making as much money as IG/FB/Google either...).
      • sametmax 9y ago
        The only metrics is economic. The question is how much does those performance constrains cost you ?
• ot 9y ago
  Yes, when you fork all the pages in the address space are referenced, and copied when modified. However if you have a GC it will go around touching objects in the child process, and there's a good chance it will end up touching a few bytes in each page, nullifying the benefits of COW.
  • rurban 9y ago
    Exactly. That's why you normally don't call refcounting a GC, as it writes to objects on referencing, and thereby destroys COW. With Perl it's even more stupid, they write to the const strings also, not just the refcount. And still call it COW. I call it write on assign, WOA. A normal GC leaves it alone and does not force fresh memory maps for these.
    • ot 9y ago
      It's not just refcounting, GCs also normally have some sort of bookkeeping that is updated in the background, for example a mark&sweep GC will need to mark the objects. See the comment about the object header in the OP.
      • rurban 9y ago
        This GC bookkeeping cannot be compared to the refcounting madness. A GC needs 1-2 bits during the GC, but does not disturb COW pages at all during run-time. It also has no word overhead, these 2 bits easily fit into every object. Also a GC compacts the live heap, which makes all upcoming accesses much faster. Well, not Mark & Sweep, but a compacting GC.
• masklinn 9y ago
  > When exactly is this new GC behavior useful? When forking processes? When forking a process and performing lots of allocations in the parent process (e.g. lots of imports & objects creation before forking) and doing so on a CoW-forking OS (but I'm guessing that's most modern POSIX systems).