# Конфигурация развертывания Discourse по мнению MKJ

**URL:** https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355
**Category:** Sysadmins
**Tags:** explanation, install
**Created:** [09.Июнь.2021 23:34:00 UTC](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355 "2021-06-09T23:34:00Z")
**Posts on this page:** 20
**Page:** 2

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [12.Январь.2023 17:37:29 UTC](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/21 "2023-01-12T17:37:29Z")

</div>

> [@rahim123](#):
>
> Уведомляет ли панель управления Discourse конкретно о таком необходимом обновлении?

Если вы выполняете обновления через интерфейс, в конечном итоге вы получите сообщение о том, что необходимо выполнить обновление через командную строку. Это зависит не от Debian, а от базового образа Discourse.

---

<div class="post-metadata">

### Author: ![rahim123](https://avatars.discourse-cdn.com/v4/letter/r/df705f/32.png) [@rahim123](https://meta.discourse.org/u/rahim123)
#### Post date: [12.Январь.2023 17:38:55 UTC](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/22 "2023-01-12T17:38:55Z")

</div>

И при методе с двумя контейнерами кнопки обновления GUI вообще не будет, верно?

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [12.Январь.2023 17:40:19 UTC](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/23 "2023-01-12T17:40:19Z")

</div>

Обновление графического интерфейса поступает из плагина `discourse_docker`. Если у вас установлен этот плагин, у вас есть обновление графического интерфейса.

---

<div class="post-metadata">

### Author: ![mcdanlj](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mcdanlj/32/131829_2.png) [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [12.Январь.2023 17:44:21 UTC](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/24 "2023-01-12T17:44:21Z")

</div>

> [@rahim123](#):
>
> Типичная уязвимость или вектор атаки, приводящий к компрометации реальных веб-сайтов, почти всегда кроется в коде веб-приложения или в одном из его фреймворков веб-разработки.

Когда обнаруживаются уязвимости в инструментах обработки изображений, в прошлом точно случались исключения при удаленном выполнении кода, что означает: вам достаточно загрузить одно изображение, чтобы система была скомпрометирована.

> [@rahim123](#):
>
> Короткая рекомендация в пользу Clear Linux.

Clear Linux задала стандарт скорости загрузки на Linux. Это потрясающая работа, полностью поддерживаю.

---

<div class="post-metadata">

### Author: ![rahim123](https://avatars.discourse-cdn.com/v4/letter/r/df705f/32.png) [@rahim123](https://meta.discourse.org/u/rahim123)
#### Post date: [12.Январь.2023 17:48:33 UTC](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/25 "2023-01-12T17:48:33Z")

</div>

> [@pfaffman](#):
>
> Обновление GUI поступает из плагина `discourse_docker`. Если у вас установлен этот плагин, у вас есть обновление GUI.

О, тогда это немного меняет дело. По какой-то причине я думал, что обновлятор GUI не будет работать с нестандартной установкой на 2 контейнера. В таком случае, если администратор обладает достаточными техническими навыками, у установки на 2 контейнера, похоже, нет особых недостатков. Мне определённо нужны обновления GUI; например, если я в поездке только с телефоном и выходит крупное обновление безопасности Discourse, я смогу хотя бы применить его без доступа по SSH.

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [12.Январь.2023 17:57:50 UTC](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/26 "2023-01-12T17:57:50Z")

</div>

> [@rahim123](#):
>
> Пока администратор обладает технической компетенцией, похоже, что у установки в 2 контейнера не так много недостатков

Это моя позиция. Вам в основном нужно просто достаточно внимательно следить за обновлениями Postgres или Redis, которые требуют пересборки контейнера с данными. Также нужно знать, как выполнить `./launcher bootstrap web_only && ./launcher destroy web_only; ./launcher start web_only`, но это не так уж сложно. Можно просто сделать `./launcher rebuild web_only`, но в этом случае сайт будет недоступен во время пересборки.

---

<div class="post-metadata">

### Author: ![mcdanlj](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mcdanlj/32/131829_2.png) [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [12.Январь.2023 18:23:27 UTC](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/27 "2023-01-12T18:23:27Z")

</div>

Для полноты картины: сборка веб-интерфейса обычно не вызывает простоя; процесс bootstrap/destroy/start всё же подразумевает минимальный простой, и выполнять его следует как обычно — с внешней страницей обслуживания, как описано в документации для внешнего nginx. В любом случае это хорошая практика, даже если только для получения IPv6-адресов внутри контейнера.

---

<div class="post-metadata">

### Author: ![rahim123](https://avatars.discourse-cdn.com/v4/letter/r/df705f/32.png) [@rahim123](https://meta.discourse.org/u/rahim123)
#### Post date: [12.Январь.2023 18:27:18 UTC](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/28 "2023-01-12T18:27:18Z")

</div>

Отлично, спасибо. А при установке с двумя контейнерами вы всё ещё получаете уведомления из панели управления Discourse о необходимости пересборки контейнера? И в таком случае я мог бы решить, пересобирать только контейнер приложения или также и контейнер данных?

---

<div class="post-metadata">

### Author: ![mcdanlj](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mcdanlj/32/131829_2.png) [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [12.Январь.2023 19:58:44 UTC](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/29 "2023-01-12T19:58:44Z")

</div>

Да. Я вижу это прямо сейчас, потому что не применил обновление 3.1.0.beta1 с пометкой «изменилась только версия». 🙂

---

<div class="post-metadata">

### Author: ![mcdanlj](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mcdanlj/32/131829_2.png) [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [25.Январь.2023 21:36:01 UTC](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/30 "2023-01-25T21:36:01Z")

</div>

Это классический случай «всё хорошо, пока не становится плохо» — люди паникуют, когда обновление в интерфейсе не удаётся, и не знают, что нужно выполнить `git pull; ./launcher rebuild app`, чтобы обойти проблему. Мне кажется, это происходит каждый раз, когда вносится изменение, делающее обновление GUI неактуальным. Так случилось и на этот раз:

> [@Failed upgrade from 2.9.0.beta14 to 3.1.0.beta](https://meta.discourse.org/t/failed-upgrade-from-2-9-0-beta14-to-3-1-0-beta/252551?u=mcdanlj):
>
> I upgrade every month, always on a few development systems first, then production. During this month’s cycle, the upgrade failed on the 1st development system. docker\_manager upgraded fine but the discourse upgrade failed with: Sorry, there was an error upgrading Discourse. Please check the logs below. The Discourse app is completely down (it’s displaying the “Oops” error 500 page). Here’s what the on-screen log contains: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* \*\*\* Please …

Мне кажется, эта паника подчёркивает ценность наличия последовательного, стандартного механизма обновлений, который позволяет избежать подобного опыта.

В то же время я столкнулся с ещё одним, тоже редким случаем: запуск (bootstrap) ломает работающую систему. Обновления с почти нулевым временем простоя иногда дают сбои подобным образом, возможно, один-два раза в год в среднем? Поэтому не делайте задержку между этапами bootstrap и destroy/start.

> [@Self-hosted upgrade to 3.1.0.beta2 with typical multi-container install requires extra downtime](https://meta.discourse.org/t/problems-with-self-hosted-upgrade-to-3-1-0-beta2/252916?u=mcdanlj):
>
> I updated my sites from 3.1.0.beta1 to 3.1.0.beta2, and after bootstrapping the new version, but before destroying the old app containers and starting new ones, at least one of those sites started giving the generic error page to users. I didn’t notice it on my test site or the other sites I run, but it’s possible that it happened and I didn’t see it. In any case, for me in at least one case, the “zero downtime” update process did not succeed.

Мне стоит обновить текст, чтобы это стало понятнее, поэтому я займусь этим следующим.

---

<div class="post-metadata">

### Author: ![mcdanlj](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mcdanlj/32/131829_2.png) [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [23.Март.2024 18:38:55 UTC](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/31 "2024-03-23T18:38:55Z")

</div>

Я ещё не развернул LibreTranslate, но рассматриваю эту возможность, чтобы сделать свой сайт доступнее для международной аудитории.

> [@LibreTranslate Plugin -- Free and Open Source Translation API](https://meta.discourse.org/t/libretranslate-plugin-free-and-open-source-translation-api/207891):
>
> Continuing the discussion from [Discourse Translator](https://meta.discourse.org/t/discourse-translator/32630): LibreTranslate - [Github project page](https://github.com/LibreTranslate/LibreTranslate) Project discussion at [https://community.libretranslate.com/](https://community.libretranslate.com/) Free and Open Source Machine Translation API. 100% self-hosted, offline capable and easy to setup. Powered by the open source [Argos Translate](https://github.com/argosopentech/argos-translate)[API Docs](https://libretranslate.com/docs)Discourse Installation copy-pasted from the Github readme You can use this [discourse translator plugin](https://github.com/LibreTranslate/discourse-translator) to translate [Discourse](https://discourse.org) topics. To install it simply modify /var/discourse/containers/app.…

Если мне это удастся, я добавлю эту информацию в исходный пост. ☺

---

<div class="post-metadata">

### Author: ![stephtara](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/stephtara/32/517827_2.png) [@stephtara](https://meta.discourse.org/u/stephtara)
#### Post date: [15.Декабрь.2025 23:05:26 UTC](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/32 "2025-12-15T23:05:26Z")

</div>

Многое из этого мне не совсем понятно, но я хочу сказать спасибо, потому что несколько настроек, которые вы упомянули вместе с рекомендациями по их изменению и объяснением последствий для работы сообщества, уже были для меня чрезвычайно ценны!

---

<div class="post-metadata">

### Author: ![mcdanlj](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mcdanlj/32/131829_2.png) [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [15.Декабрь.2025 23:56:28 UTC](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/33 "2025-12-15T23:56:28Z")

</div>

Рад, что это оказалось полезным даже для тех, кто не входит в мою целевую аудиторию. 🎉 Я использовал это пару дней назад, чтобы развернуть новый экземпляр Discourse, и это помогло и мне, так как я сам не помню всех этих деталей. 😃

---

<div class="post-metadata">

### Author: ![markersocial](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/markersocial/32/170136_2.png) [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [15.Февраль.2026 15:11:18 UTC](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/34 "2026-02-15T15:11:18Z")

</div>

> [@mcdanlj](#):
>
> ```plaintext
> echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
> echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
> sysctl --system
> 
> ```

Похоже, в вики есть ошибка в настройке THP.

У меня возникли проблемы с Redis на Ubuntu:

```plaintext
Ваше сетевое соединение Redis работает крайне медленно. Последние показания RTT: [96585, 101554, 97189, 99769, 94618], в идеале они должны быть < 1000. Убедитесь, что Redis запущен в той же AZ или дата

```

Я считал, что THP уже отключен (следуя вики), но оказалось, что он всё ещё включён 😅. Отключение THP, насколько я помню, решило проблему в конце прошлого года.

* * *

Ubuntu 24.04 LTS (следуя текущей вики):

```plaintext
cat /sys/kernel/mm/transparent_hugepage/enabled
# вывод:
# [always] madvise never

echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf

cat /etc/sysctl.d/10-huge-pages.conf
# вывод:
# sys.kernel.mm.transparent_hugepage.enabled=never

sudo sysctl --system
# вывод:
* Applying /usr/lib/sysctl.d/10-apparmor.conf ...
* Applying /etc/sysctl.d/10-bufferbloat.conf ...
* Applying /etc/sysctl.d/10-console-messages.conf ...
* Applying /etc/sysctl.d/10-huge-pages.conf ...
* Applying /etc/sysctl.d/10-ipv6-privacy.conf ...
* Applying /etc/sysctl.d/10-kernel-hardening.conf ...
* Applying /etc/sysctl.d/10-magic-sysrq.conf ...
* Applying /etc/sysctl.d/10-map-count.conf ...
* Applying /etc/sysctl.d/10-network-security.conf ...
* Applying /etc/sysctl.d/10-ptrace.conf ...
* Applying /etc/sysctl.d/10-zeropage.conf ...
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
* Applying /etc/sysctl.d/99-cloudimg-ipv6.conf ...
* Applying /usr/lib/sysctl.d/99-protect-links.conf ...
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.conf ...
kernel.apparmor_restrict_unprivileged_userns = 1
net.core.default_qdisc = fq_codel
kernel.printk = 4 4 1 7
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
kernel.kptr_restrict = 1
kernel.sysrq = 176
vm.max_map_count = 1048576
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
kernel.yama.ptrace_scope = 1
vm.mmap_min_addr = 65536
kernel.pid_max = 4194304
net.ipv6.conf.all.use_tempaddr = 0
net.ipv6.conf.default.use_tempaddr = 0
fs.protected_fifos = 1
fs.protected_hardlinks = 1
fs.protected_regular = 2
fs.protected_symlinks = 1

cat /sys/kernel/mm/transparent_hugepage/enabled
# вывод:
# [always] madvise never

```

* * *

AlmaLinux 10 (следуя текущей вики):

```plaintext
cat /sys/kernel/mm/transparent_hugepage/enabled
# вывод:
# [always] madvise never

echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf

cat /etc/sysctl.d/10-huge-pages.conf
# вывод:
# sys.kernel.mm.transparent_hugepage.enabled=never

sudo sysctl --system
# вывод:
* Applying /usr/lib/sysctl.d/10-default-yama-scope.conf ...
* Applying /etc/sysctl.d/10-huge-pages.conf ...
* Applying /usr/lib/sysctl.d/10-map-count.conf ...
* Applying /usr/lib/sysctl.d/50-coredump.conf ...
* Applying /usr/lib/sysctl.d/50-default.conf ...
* Applying /usr/lib/sysctl.d/50-libkcapi-optmem_max.conf ...
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
* Applying /usr/lib/sysctl.d/50-redhat.conf ...
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.conf ...
kernel.yama.ptrace_scope = 0
vm.max_map_count = 1048576
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
kernel.core_pipe_limit = 16
fs.suid_dumpable = 2
kernel.sysrq = 16
kernel.core_uses_pid = 1
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.rp_filter = 2
net.ipv4.conf.lo.rp_filter = 2
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.eth0.accept_source_route = 0
net.ipv4.conf.eth1.accept_source_route = 0
net.ipv4.conf.lo.accept_source_route = 0
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.eth0.promote_secondaries = 1
net.ipv4.conf.eth1.promote_secondaries = 1
net.ipv4.conf.lo.promote_secondaries = 1
net.ipv4.ping_group_range = 0 2147483647
net.core.default_qdisc = fq_codel
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_regular = 1
fs.protected_fifos = 1
net.core.optmem_max = 81920
kernel.pid_max = 4194304
kernel.kptr_restrict = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.eth1.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1

cat /sys/kernel/mm/transparent_hugepage/enabled
# вывод:
# [always] madvise never

```

* * *

Возможно, это подойдёт для вики? На Ubuntu 24.04 и AlmaLinux 10 это сработало при тестировании:

```plaintext
echo 'w /sys/kernel/mm/transparent_hugepage/enabled - - - - never' | sudo tee /etc/tmpfiles.d/10-huge-pages.conf
sudo systemd-tmpfiles --create /etc/tmpfiles.d/10-huge-pages.conf

```

Для подтверждения:

```plaintext
cat /sys/kernel/mm/transparent_hugepage/enabled

```

Ожидаемый вывод:

```plaintext
always madvise [never]

```

---

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [15.Февраль.2026 15:19:57 UTC](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/35 "2026-02-15T15:19:57Z")

</div>

> [@markersocial](#):
>
> Отключение THP в итоге решило проблему для меня

Хорошо это слышать — если мы не знаем, помогает ли это, мы можем просто подражать друг другу!

---

<div class="post-metadata">

### Author: ![mcdanlj](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mcdanlj/32/131829_2.png) [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [15.Февраль.2026 22:00:03 UTC](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/36 "2026-02-15T22:00:03Z")

</div>

Я не думаю, что /etc/sysctl.d устарел. Посмотрите, пожалуйста, другие файлы в этом каталоге и выясните, какой из них переопределяет /etc/sysctl.d/10-huge-pages.conf. Возможно, это один из файлов с приоритетом 50?

Более правильное решение, вероятно, — изменить приоритет настройки huge-pages так, чтобы она имела преимущество. Однако я в данный момент не использую ни одну из этих версий на своих системах.

Также проверьте, не переопределяет ли эту настройку tuned.

---

<div class="post-metadata">

### Author: ![markersocial](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/markersocial/32/170136_2.png) [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [16.Февраль.2026 04:37:29 UTC](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/37 "2026-02-16T04:37:29Z")

</div>

У меня возникла проблема только с применением конфигурации THP, тогда как vm.overcommit.memory применился как ожидалось через /etc/sysctl.d. Это было замечено и устранено на сервере в конце прошлого года. Поэтому вчера я решил проверить это на нескольких микро-VPS.

Только что попробовал это на свежем микро-VPS с AlmaLinux 9, чтобы понять, влияют ли какие-либо файлы конфигурации по умолчанию на конфигурацию THP:

```plaintext
echo always | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
# вывод:
# always

cat /sys/kernel/mm/transparent_hugepage/enabled
# вывод:
# [always] madvise never

sysctl --system
# вывод:
* Applying /usr/lib/sysctl.d/10-default-yama-scope.conf ...
* Applying /usr/lib/sysctl.d/50-coredump.conf ...
* Applying /usr/lib/sysctl.d/50-default.conf ...
* Applying /usr/lib/sysctl.d/50-libkcapi-optmem_max.conf ...
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
* Applying /usr/lib/sysctl.d/50-redhat.conf ...
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.conf ...
kernel.yama.ptrace_scope = 0
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
kernel.core_pipe_limit = 16
fs.suid_dumpable = 2
kernel.sysrq = 16
kernel.core_uses_pid = 1
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.rp_filter = 2
net.ipv4.conf.lo.rp_filter = 2
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.eth0.accept_source_route = 0
net.ipv4.conf.eth1.accept_source_route = 0
net.ipv4.conf.lo.accept_source_route = 0
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.eth0.promote_secondaries = 1
net.ipv4.conf.eth1.promote_secondaries = 1
net.ipv4.conf.lo.promote_secondaries = 1
net.ipv4.ping_group_range = 0 2147483647
net.core.default_qdisc = fq_codel
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_regular = 1
fs.protected_fifos = 1
net.core.optmem_max = 81920
kernel.pid_max = 4194304
kernel.kptr_restrict = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.eth1.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1

cat /sys/kernel/mm/transparent_hugepage/enabled
# вывод:
# [always] madvise never

```

```plaintext
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
# вывод:
# never

cat /sys/kernel/mm/transparent_hugepage/enabled
# вывод:
# always madvise [never]

sysctl --system
# вывод:
* Applying /usr/lib/sysctl.d/10-default-yama-scope.conf ...
* Applying /usr/lib/sysctl.d/50-coredump.conf ...
* Applying /usr/lib/sysctl.d/50-default.conf ...
* Applying /usr/lib/sysctl.d/50-libkcapi-optmem_max.conf ...
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
* Applying /usr/lib/sysctl.d/50-redhat.conf ...
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.conf ...
kernel.yama.ptrace_scope = 0
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
kernel.core_pipe_limit = 16
fs.suid_dumpable = 2
kernel.sysrq = 16
kernel.core_uses_pid = 1
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.rp_filter = 2
net.ipv4.conf.lo.rp_filter = 2
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.eth0.accept_source_route = 0
net.ipv4.conf.eth1.accept_source_route = 0
net.ipv4.conf.lo.accept_source_route = 0
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.eth0.promote_secondaries = 1
net.ipv4.conf.eth1.promote_secondaries = 1
net.ipv4.conf.lo.promote_secondaries = 1
net.ipv4.ping_group_range = 0 2147483647
net.core.default_qdisc = fq_codel
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_regular = 1
fs.protected_fifos = 1
net.core.optmem_max = 81920
kernel.pid_max = 4194304
kernel.kptr_restrict = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.eth1.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1

cat /sys/kernel/mm/transparent_hugepage/enabled
# вывод:
# always madvise [never]

```

---

<div class="post-metadata">

### Author: ![mcdanlj](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mcdanlj/32/131829_2.png) [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [16.Февраль.2026 13:02:02 UTC](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/38 "2026-02-16T13:02:02Z")

</div>

> [@markersocial](#):
>
> У меня была проблема только с применением конфигурации THP; vm.overcommit.memory применился как ожидалось через /etc/sysctl.d

Вот почему я прошу вас проверить _фактические файлы_, чтобы найти, что переопределяет эту настройку, чтобы я мог внести обоснованное изменение в приоритет, который я рекомендую для переопределения.

---

<div class="post-metadata">

### Author: ![markersocial](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/markersocial/32/170136_2.png) [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [16.Февраль.2026 15:22:08 UTC](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/39 "2026-02-16T15:22:08Z")

</div>

Мое текущее (ограниченное) понимание таково, что команды/выводы из моего предыдущего поста указывают на отсутствие переопределения.

Просматривая файлы на свежем экземпляре AlmaLinux 9:

Эти команды ничего не нашли:

```plaintext
grep -r "transparent_hugepage" /usr/lib/sysctl.d/ /etc/sysctl.d/ /etc/sysctl.conf
grep -r "transparent" /usr/lib/sysctl.d/ /etc/sysctl.d/ /etc/sysctl.conf
grep -r "huge" /usr/lib/sysctl.d/ /etc/sysctl.d/ /etc/sysctl.conf
grep -r "page" /usr/lib/sysctl.d/ /etc/sysctl.d/ /etc/sysctl.conf

```

Значения по умолчанию в файлах конфигурации:

```plaintext
/usr/lib/sysctl.d/50-redhat.conf:kernel.kptr_restrict = 1
/usr/lib/sysctl.d/50-redhat.conf:net.ipv4.conf.default.rp_filter = 1
/usr/lib/sysctl.d/50-redhat.conf:net.ipv4.conf.*.rp_filter = 1
/usr/lib/sysctl.d/50-redhat.conf:-net.ipv4.conf.all.rp_filter
/usr/lib/sysctl.d/10-default-yama-scope.conf:kernel.yama.ptrace_scope = 0
/usr/lib/sysctl.d/50-libkcapi-optmem_max.conf:net.core.optmem_max = 81920
/usr/lib/sysctl.d/50-coredump.conf:kernel.core_pattern=|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
/usr/lib/sysctl.d/50-coredump.conf:kernel.core_pipe_limit=16
/usr/lib/sysctl.d/50-coredump.conf:fs.suid_dumpable=2
/usr/lib/sysctl.d/50-default.conf:kernel.sysrq = 16
/usr/lib/sysctl.d/50-default.conf:kernel.core_uses_pid = 1
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.default.rp_filter = 2
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.*.rp_filter = 2
/usr/lib/sysctl.d/50-default.conf:-net.ipv4.conf.all.rp_filter
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.default.accept_source_route = 0
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.*.accept_source_route = 0
/usr/lib/sysctl.d/50-default.conf:-net.ipv4.conf.all.accept_source_route
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.default.promote_secondaries = 1
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.*.promote_secondaries = 1
/usr/lib/sysctl.d/50-default.conf:-net.ipv4.conf.all.promote_secondaries
/usr/lib/sysctl.d/50-default.conf:-net.ipv4.ping_group_range = 0 2147483647
/usr/lib/sysctl.d/50-default.conf:-net.core.default_qdisc = fq_codel
/usr/lib/sysctl.d/50-default.conf:fs.protected_hardlinks = 1
/usr/lib/sysctl.d/50-default.conf:fs.protected_symlinks = 1
/usr/lib/sysctl.d/50-default.conf:fs.protected_regular = 1
/usr/lib/sysctl.d/50-default.conf:fs.protected_fifos = 1
/usr/lib/sysctl.d/50-pid-max.conf:kernel.pid_max = 4194304

```

---

<div class="post-metadata">

### Author: ![mcdanlj](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mcdanlj/32/131829_2.png) [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [16.Февраль.2026 19:56:58 UTC](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355/40 "2026-02-16T19:56:58Z")

</div>

> [@markersocial](#):
>
> Просматривая файлы на свежем экземпляре AlmaLinux 9:

Я использую AlmaLinux 9 для своих экземпляров Discourse, и предоставленная мною конфигурация успешно отключила THP на всех из них. Если отключение THP через sysctl.d не работает при отсутствии переопределений, и tuned не переопределяет его, я бы подумал, что это ошибка.

Мне показалось, что вы говорили, что это больше не работает в AlmaLinux 10, поэтому я и спрашивал, что мешает его применению там.

[Предыдущая страница](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355.md?page=1)

[Следующая страница](https://meta.discourse.org/t/mkjs-opinionated-discourse-deployment-configuration/193355.md?page=3)
