Я только что выполнил множество обновлений и решил, что самый простой способ устранить ошибки памяти — просто увеличить размер файла подкачки до 4 ГБ. Минус в том, что на дроплете с 1 ГБ ОЗУ всего 25 ГБ SSD, поэтому отвести 4 ГБ подкачки — это существенная потеря места, а при объёме всего в 25 ГБ пространство уже и так ограничено.
Так стоит ли изменить discourse-setup, чтобы по умолчанию устанавливать 3 ГБ?
Что вы думаете, @Falco?
Если это решит проблему, я только за.
Могу ли я настоятельно рекомендовать, чтобы скрипт установки также настраивал два параметра ядра, влияющих на управление памятью? Было бы хорошо знать, что каждый, у кого, по-видимому, возникли проблемы, как минимум имеет хорошую отправную точку в виде правильной настройки ядра.
Мне это кажется разумной идеей. Я не могу представить, где THP могут быть полезны на выделенном экземпляре Discourse, а переопределение может помочь избежать нехватки памяти (OOM).
Стоит рассмотреть возможность предложить выполнить каждую из этих операций отдельно, установив их как ответ по умолчанию, с возможностью отключения через неосновной параметр?
Кроме того, скрипт может использовать sysctl, чтобы определить, нужно ли вообще менять настройки, прежде чем вносить изменения. Если кто-то уже внес эти изменения с помощью других файлов, создание дублирующих переопределений может вызвать путаницу. Я считаю, что не все дистрибутивы Linux по умолчанию отключают переопределение памяти.
Хотя это может размыть важный посыл о настройках ядра, стоит учесть ещё один момент: текущий скрипт создаёт своп только на машинах с малым объёмом оперативной памяти. Я считаю, что это ошибка, поскольку своп всё ещё полезен для максимизации эффективности использования RAM, но, что ещё важнее, это может создать проблемы, если кто-то развернёт Discourse на машине с большим объёмом памяти ради скорости или удобства, а затем уменьшит её до малого объёма.
Настройка должна создавать своп во всех случаях (если его уже недостаточно). Наличие нескольких файлов подкачки допустимо и иногда полезно.
Я не тот, кто принимает решения, и я настраиваю эти параметры на машинах, которые разворачиваю, но это оболочечный скрипт, который запускается (в основном) всеми, кто устанавливает Discourse. Он должен быть максимально простым. Мы уверены, что эти настройки работают на Raspberry Pi, Mac и на любых других «экзотических» сценариях, которые люди пытаются реализовать? И что любой метод проверки их наличия работает на всех этих платформах? Кажется, это сложно.
Я написал discourse-setup, и мне немного страшно вносить в него изменения.
Всегда предлагать создание swap-файла — не плохая идея. Возможно, просто всегда предлагать настроить 3 или 4 ГБ swap-памяти? Но тогда какой объём выбрать? Я помню одно эмпирическое правило: размер swap должен быть равен объёму ОЗУ. А сейчас, если вы не создадите swap, у вас останется только одно решение — прервать выполнение нажатием Ctrl+C. Либо мы заставим всех создавать swap, либо добавим ещё один вопрос «Да/Нет» (что заставит меня модифицировать мои скрипты, запускающие discourse-setup 
). О! Или мы можем сделать это управляемым через флаг --skip-swap. Мне это кажется приемлемым. Если вы достаточно умны, чтобы знать о swap, вы сможете найти этот флаг для его пропуска; мы можем добавить примечание о флаге в то сообщение с ПРЕДУПРЕЖДЕНИЕМ.
И, возможно, также добавить примечание о --skip-connection-test, когда тест соединения не удаётся.
Я считаю, что если swap уже настроен, можно с уверенностью предположить, что пользователь знает, что делает.
Спасибо! Да, всё полностью понятно, я бы чувствовал то же самое. Это, безусловно, требует тщательного обдумывания и тестирования. И это должно быть проверено как минимум на нескольких дешёвых машинах хостинг-провайдеров, а также на Raspberry Pi. Не уверен насчёт Windows или macOS — если ожидается их поддержка, то, полагаю, да. Я бы скорее ожидал, что их будут использовать как машины для разработки, но это уже другая история.
Действительно. Вероятно, всё, что кажется необходимым в данный момент. Кажется, требования немного возросли. Но меня очень огорчает то, что я не знаю, включают ли эти отчёты настройку перераспределения памяти (overcommit) или нет. Я почти уверен, что из предыдущих обсуждений мы знаем, что перераспределение памяти имеет значение.
И мы точно знаем, что на экземпляре с 25 ГБ и особенно с 20 ГБ место на диске ограничено. Я работаю на таких машинах: 25 ГБ диска и 1 ГБ ОЗУ, где уже требуется 2 ГБ подкачки, а сейчас, вероятно, ещё больше; и 20 ГБ диска с 2 ГБ ОЗУ, где у меня сейчас 1 ГБ подкачки.
Я бы не рекомендовал больше вопросов типа «да/нет». Варианты командной строки кажутся лучшим решением.
Если мы всё же собираемся менять этот скрипт, я бы порекомендовал создать несколько файлов подкачки по 1 ГБ, так как это максимизирует гибкость, ничего не тратит впустую, и это самое подходящее время для такого решения.
Я не так уверен в этом. Если на самом маленьком экземпляре с «чистым» Ubuntu или Debian уже есть какая-то подкачка — это нужно проверить — то у нас возникнут проблемы, если её недостаточно. Гораздо лучше измерить ОЗУ + подкачку с помощью утилиты free, скорректировать значения, как обычно, для конфигураций с менее чем 1 ГБ ОЗУ (полагаю, это AWS, возможно, Oracle), а затем добавить файлы подкачки по 1 ГБ до какого-то согласованного количества, каково бы оно ни было на данный момент. Надеюсь, что в сумме 4 ГБ будет достаточно, при условии правильной настройки перераспределения памяти в ядре.
Я с радостью помогу.
Хм. Да. Жаль, что я не подумал проверить это на тех, которые я только что настроил.
Хм. Я склоняюсь к тому, что один файл лучше, но несколько действительно добавляют гибкости. Тогда можно будет настроить discourse-setup так, чтобы он добавлял ещё один файл подкачки, если потребуется больше памяти. Это позволит всем запускать discourse-setup, чтобы «исправить» проблему с подкачкой. Возможно, это также решит и вопрос с перераспределением памяти — хотя, наверное, стоит делать это явно только для Linux, поскольку нас интересует только он.
Я не согласен. Swap — не всегда благо. Раньше он был важен для выравнивания работы кода виртуальной машины, даже когда в определённых условиях подкачка не происходила, но алгоритмы виртуальной машины изменились.
Это правило основывалось на устаревших эвристиках ядра, которые больше не актуальны.
Кроме того, при рассмотрении вопроса мониторинга: я даже не знаю, что именно следует измерять для swap и памяти, если используется zswap. Вероятно, в данном случае действует принцип «прежде всего — не навреди».
Я вполне уверен, что единственный недостаток «слишком большого файла подкачки» — это использование большего объема дискового пространства, чем абсолютно необходимо. Одна из причин, по которой предпочтительнее иметь несколько файлов подкачки умеренного размера, заключается в том, что при необходимости освободить место на диске можно последовательно отключать и удалять их. Кроме того, я считаю, что Linux достаточно разумно использует их по очереди:
NAME TYPE SIZE USED PRIO
/var/local/swap/swapfile.1 file 1024M 863.6M -2
/var/local/swap/swapfile.0 file 1024M 4.6M -3
Ситуация, в которой мы оказались, такова: дешевые экземпляры сильно ограничены как по объему оперативной памяти, так и по дисковому пространству, а Discourse требует всё больше ресурсов по мере развития огромного количества входящих в него пакетов. Тем не менее, я считаю, что существуют способы разумно справиться с этим, чтобы помочь тем, кто не может просто махнуть рукой и удвоить или учетверить свой ежемесячный счет.
Свопинг происходит достаточно медленно, поэтому я бы не стал считать фразу «почти нет места» основанием для увеличения рекомендуемого значения по умолчанию более чем на 1 ГБ на данном этапе. Каждый дополнительный гигабайт — это значительный объём свопинга, что подтверждается опытом работы на выделенном экземпляре Discourse.
Да, по умолчанию Linux использует своп в порядке приоритета, и можно задать одинаковый приоритет для нескольких устройств, чтобы явно реализовать полосовое распределение своп-пространства. Однако, на мой взгляд, добавлять большое количество своп-пространства для небольших сайтов не особенно целесообразно.
Поэтому, если спустя примерно десять лет пользователи лишь изредка сталкиваются с лимитом в 2 ГБ, я бы предложил установить значение по умолчанию на 3 ГБ, а не на 4 ГБ. И необходимое количество своп-пространства для выделенного экземпляра Discourse не должно существенно возрастать вместе с объёмом памяти, поскольку данные, которые фактически выгружаются в своп, не меняются особенно сильно.
Идея увеличения своп-пространства вместе с ростом объёма памяти в основном относится к универсальным вычислительным системам и основана на обобщённом предположении, что чем больше оперативной памяти требуется, тем, вероятно, выше и общая нагрузка. Однако, по моему мнению, нагрузка на своп в специализированном экземпляре Discourse не будет следовать этой закономерности.
THP специфичны для платформ, поддерживающих огромные страницы, а это не все платформы. Общий способ обработки такой ситуации — проверить наличие поддержки. На одном из моих Raspberry Pi:
$ sysctl sys.kernel.mm.transparent_hugepage.enabled
sysctl: cannot stat /proc/sys/sys/kernel/mm/transparent_hugepage/enabled: No such file or directory
$ echo $?
255
В отличие от этого, overcommit — это общий параметр виртуальной памяти для Linux, существующий уже несколько десятилетий. На том же Raspberry Pi:
$ sysctl vm.overcommit_memory
vm.overcommit_memory = 0
Разбор вывода утилиты free в оболочке довольно неудобен. Говоря как автор оригинальной утилиты procps, в данном случае я бы просто искал строку SwapFree в файле /proc/meminfo. 
Я согласен с тем, что в современных условиях ограниченных ресурсов масштабирование swap-раздела в зависимости от размера оперативной памяти больше не является хорошей стратегией. Следующей исторической идеей было предположение, что оперативной памяти достаточно много, и swap не нужен. Затем пришло понимание, что некоторый swap полезен, поскольку позволяет эффективнее использовать оперативную память. (В мире без ограничений у нас просто огромные объемы оперативной памяти, но это нишевой случай.)
За последние несколько месяцев мы наблюдаем всё больше проблем с нехваткой памяти и сбоев при пересборке. Всё больше пользователей сталкиваются с неудачами при обновлении веб-интерфейса, хотя командная строка работает. С точки зрения простой поддержки и репутации продукта, я считаю, что нам необходимо изменить обычные рекомендации и стандартную конфигурацию. Я думаю, что 3 ГБ swap-раздела — это самое простое и минимальное изменение, которое стоит сделать, даже если мы не предпримем ничего другого.
Тем не менее, я по-прежнему считаю, что несколько небольших swap-файлов — более разумный выбор, и у нас уже есть темы в разделе поддержки, подтверждающие это. Также я убеждён, что лучше всего подбирать размер оперативной памяти и swap совместно, поскольку именно их совокупный объём является ограничивающим фактором, вызывающим проблемы у пользователей. Возможно, существуют разные способы выполнения такого расчёта. Применяются обычные оговорки относительно того, какие тактики легко поддерживать, понятны и обладают долгосрочной перспективой.
Что касается прозрачных больших страниц (transparent huge pages), то, насколько я понимаю, проблемы вызывает именно их «прозрачность»: ядро может тратить ресурсы на объединение и разделение страниц, что приводит к снижению производительности без существенной выгоды. Я почти уверен, что использование больших страниц не рекомендуется для систем с ограниченными ресурсами.
Дело скорее в характеристиках рабочей нагрузки, чем в размере системы. На системе с 1 ГБ ОЗУ, где работают относительно стабильные процессы с блоками памяти, огромные страницы по умолчанию размером 2 МБ могут уменьшить фрагментацию TLB и повысить производительность, поскольку TLB не успевает покрыть все отображения для 1 ГБ ОЗУ. В общем это компромисс между затратами ЦП на поиск памяти для объединения и промахами кэша TLB, и существует множество рабочих нагрузок на машинах с 1 ГБ ОЗУ, которые могут значительно выиграть от использования прозрачных огромных страниц (THP). (Многие рекомендации по её отключению относятся к раннему периоду её реализации; с тех пор она была существенно улучшена.) Рекомендация отключить THP для Discourse связана не с размером ОЗУ в 1 ГБ, а специфична для использования Redis с сохранением на диск, что применяется в Discourse:
https://redis.io/docs/management/optimization/latency/#latency-induced-by-transparent-huge-pages
К сожалению, когда в ядре Linux включены прозрачные огромные страницы, Redis испытывает значительные задержки после вызова
fork, используемого для сохранения данных на диск. Огромные страницы являются причиной следующей проблемы:
…