Skip to content

Remove noreuse flag from the shared zone #26

@bavshin-f5

Description

@bavshin-f5

Currently the shared zone is marked as noreuse and a new set of pages is allocated on each configuration reload.

This is not optimal, because

  • all the still relevant data needs to be manually transferred from the previous configuration cycle
  • active challenge data is lost on reload
  • noreuse is broken on certain platforms

At the same time, it is the only viable memory management strategy within the NGINX architecture, because we are unable to schedule a cleanup for a data no longer owned by any active worker.
Some important details:

  • Master process destroys the old ngx_cycle_t as soon as the next configuration cycle is parsed and applied. Old worker processes may remain active for a while.
  • Shared zones that are no longer referenced from the configuration will be unmapped before invoking the cycle cleanup handlers. With the approach we taken to the destruction of ngx_pool_t-allocated configuration objects, this mean that a reference-counted pointer (Arc) will attempt to deallocate from an already unmapped page, crashing the master process.
  • At the time of ngx_shm_zone_t.init invocation, we don't know yet if the configuration will be applied. It can fail at one of the subsequent initialization steps and be reverted. See the previous point for cleanup of shared data created by failed config.
  • Crashed workers obviously will not decrement any reference counters. The replacements spawned by the master process will increment the counters though.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions