Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Try some more tuning #293

Merged
merged 1 commit into from
Oct 12, 2023
Merged

Try some more tuning #293

merged 1 commit into from
Oct 12, 2023

Conversation

jaymzh
Copy link
Member

@jaymzh jaymzh commented Oct 8, 2023

  • Log the state of apache processes when we restart so we can continue
    to understand the problem
  • Restart slightly less often
  • Update MaxConnectionsPerChild to 50, which is probably a bit more
    reasonable than 5
  • Update server limit (see below)
  • Turn off KeepAlive (see below)

From scale-infra, explanation on the last two above.

This is a confirmed bug in Apache with no configuration workaround:

https://bz.apache.org/bugzilla/show_bug.cgi?id=53555

There's a pretty good description of the details, which match our behavior here:

https://serverfault.com/questions/516373/what-is-the-meaning-of-ah00485-scoreboard-is-full-not-at-maxrequestworkers

One thing that some people seem to have had success with is turning keepalive off.

ServerLimit, for the event MPM (what we use), the recommendation is:

With event, increase this directive if the process number defined by your MaxRequestWorkers and ThreadsPerChild settings, plus the number of gracefully shutting down processes, is more than 16 server processes (default).

Our MaxRequestWorkers is 50. We don't define ThreadsPerChild which defaults to 25. So if I read that correctly (and I haven't tuned Apache for a living in a looonnnggg time), we want something like 50+25=75 plus some more for shutting down processes, so like... 80? I can prep a diff for that plus keepalive and see how that goes.

All continuing socallinuxexpo/scale-drupal#79

Signed-off-by: Phil Dibowitz [email protected]

* Log the state of apache processes when we restart so we can continue
  to understand the problem
* Restart slightly less often
* Update MaxConnectionsPerChild to 50, which is probably a bit more
  reasonable than 5
* Update server limit (see below)
* Turn off KeepAlive (see below)

From scale-infra, explanation on the last two above.

```
This is a confirmed bug in Apache with no configuration workaround:

https://bz.apache.org/bugzilla/show_bug.cgi?id=53555

There's a pretty good description of the details, which match our behavior here:

https://serverfault.com/questions/516373/what-is-the-meaning-of-ah00485-scoreboard-is-full-not-at-maxrequestworkers

One thing that some people seem to have had success with is turning keepalive off.

ServerLimit, for the event MPM (what we use), the recommendation is:

With event, increase this directive if the process number defined by your MaxRequestWorkers and ThreadsPerChild settings, plus the number of gracefully shutting down processes, is more than 16 server processes (default).

Our MaxRequestWorkers is 50. We don't define ThreadsPerChild which defaults to 25. So if I read that correctly (and I haven't tuned Apache for a living in a looonnnggg time), we want something like 50+25=75 plus some more for shutting down processes, so like... 80? I can prep a diff for that plus keepalive and see how that goes.
```

All continuing socallinuxexpo/scale-drupal#79

Signed-off-by: Phil Dibowitz <[email protected]>
@irabinovitch
Copy link
Contributor

Interesting finds re the scoreboard bug. Should we move to pre-fork? Have we tried any of these settings out in prod yet?

@@ -10,13 +10,22 @@
include_recipe 'scale_apache::common'
include_recipe 'fb_apache'

apache_debug_log = '/var/log/apache_status.log'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we have datadog collect this as well?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't htink it's necessary in this case...

# to 25. So if I read that correctly (and I haven't tuned Apache for a living
# in a looonnnggg time), we want something like 50+25=75 plus some more for
# shutting down processes, so like... 80?
node.default['fb_apache']['extra_configs']['ServerLimit'] = 80
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing to keep in mind is our httpd/php processes are often at around 100Mb of memory, 256 or higher when speakers are uploading large slide decks, etc. At least one issue we were having this summer was that httpd was often having more prefork workers than we had memory on the system to handle. Reducing the number of allowed workers alleviated it quite a bit.

All this to say, I think these settings are reasonable - but without docs access right now I'm not sure what the resulting impact on memory usage might be. Will try to read them next stop I have.


# see if this helps with hung processes...
node.default['fb_apache']['extra_configs']['KeepAlive'] = 'off'

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems reasonable based on the list posts you linked.

@davide125
Copy link
Member

I think this is generally reasonable but I can't speak for the actual tunable settings here

@jaymzh jaymzh merged commit ae58860 into socallinuxexpo:main Oct 12, 2023
@jaymzh jaymzh deleted the moreturning branch October 12, 2023 01:57
jaymzh added a commit to jaymzh/scale-chef that referenced this pull request Oct 12, 2023
Part of socallinuxexpo#293 was
supposed to drop restarts to hourly, but a rebase dropped that because
those lines were changed by Ilan to fix a bug I had introduced.

This drops us down to hourly. While we may run into issues, if we do
at least now we have logging, and at worst will be down for less than an
hour.

Signed-off-by: Phil Dibowitz <[email protected]>
jaymzh added a commit that referenced this pull request Oct 12, 2023
Part of #293 was
supposed to drop restarts to hourly, but a rebase dropped that because
those lines were changed by Ilan to fix a bug I had introduced.

This drops us down to hourly. While we may run into issues, if we do
at least now we have logging, and at worst will be down for less than an
hour.

Signed-off-by: Phil Dibowitz <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants