Before changing an Apache limit, I confirm which configuration the running service actually reads. A plausible setting in an unused include can send an investigation in the wrong direction, and a successful reload does not prove that the file I edited was loaded.
I trace the service to its executable, startup arguments and include chain, then check the effective setting before and after the change. This gives me a useful starting point for memory, worker and static-file investigations.
Start with the running service
I check the service definition, the executable it starts and any command-line arguments. A bundled web stack can have its own Apache installation alongside the operating system’s copy. Running the first apachectl in my shell’s path may inspect the wrong one.
Once I have the matching wrapper and its configuration arguments, these checks are useful:
apachectl -V
apachectl -S
apachectl configtest-V reports build information, -S shows parsed virtual-host settings, and the configuration test checks syntax. None replaces checking how the running service was started: an explicit -f can select a different configuration file. The Apache command reference explains those distinctions.
Follow the includes before editing
I trace the main file through its enabled includes, conditional sections and site configuration. I look for later definitions of the same setting and record where the effective choice comes from. A commented include or an unused example file is useful background, but changing it will not change the running service.
The useful handover is a short map: service, executable, main configuration, relevant include and reload command. It also needs an owner, otherwise a control panel or deployment can quietly regenerate the file later. I cover that separately in deployment configuration needs one clear owner.
Separate fresh workers from a lasting fix
Replacing old workers can make memory use fall immediately. I record that as the result of replacing those workers. If I also change a setting, the same before-and-after screenshot cannot tell me how much each action contributed.
I compare similar request workloads after the new workers have been running for a while. I also distinguish virtual address space from resident memory and swap. A large virtual-memory figure alone does not establish how much physical memory a process is holding; the Linux process documentation describes the separate counters.
Keep static-file settings tied to the storage
EnableMMAP and EnableSendfile deserve particular care. Apache documents situations where the operating system or filesystem makes either unsuitable. I check the actual storage and test the files the site serves, including partial requests for large downloads. I do not copy a setting from one server and assume it is a universal improvement. See Apache’s memory-mapping and sendfile guidance.
I finish with a syntax check, a controlled reload and another check of the running service. That leaves a change I can explain and reverse, with evidence gathered from the configuration the site actually uses.