Сетевое соединение Redis работает крайне медленно

markersocial · 12.Декабрь.2024 22:26:44

Я постоянно вижу это в логах — значения варьируются от ~100 тыс. до ~1,35 млн, но показания около 100 тыс. встречаются довольно часто:

Ваше сетевое соединение Redis работает крайне плохо. Последние значения RTT: [97069, 103986, 98459, 100762, 381617]; в идеале они должны быть < 1000. Убедитесь, что Redis работает в той же зоне доступности (AZ) или дата-центре, что и Sidekiq. Если эти значения близки к 100 000, это может означать, что процесс Sidekiq исчерпал ресурсы процессора; уменьшите уровень параллелизма и/или обратитесь к https://github.com/mperham/sidekiq/discussions/5039

Это может указывать на то, что Redis не может использовать достаточное количество ресурсов процессора? Однако на самом сервере для процессора и оперативной памяти, похоже, есть значительный запас.

Также:
Sidekiq потребляет слишком много памяти (используется: 3570.19M) для 'www.example.com', выполняется перезапуск

Используется единый файл app.yml с версией Discourse stable 3.3.2.

Из app.yml:

UNICORN_SIDEKIQS: 9
DISCOURSE_SIDEKIQ_WORKERS: 5

Я также добавил эту конфигурацию на хост:

Michael K Johnson:

Конфигурация ядра

Redis (один из ключевых компонентов, на которых построен Discourse) настоятельно рекомендует отключить прозрачные большие страницы (transparent huge pages) при использовании персистентности на диске (что и делает Discourse), а также я разрешил переполнение памяти.
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

Информация из панели управления Sidekiq:

Кажется, что Redis не может превысить использование памяти в 1024 МБ.

Если у кого-то есть идеи, буду признателен!

markersocial · 19.Декабрь.2024 14:38:34

В дополнение к этому у меня возникла та же проблема с Jobs::PostAlert:

При текущих тестах время выполнения этих задач часто достигает 15 минут при использовании 4 процессов Sidekiq с 5 потоками каждый (по умолчанию). Похоже, скорость обработки задач в секунду для Sidekiq в основном зависит от того, сколько таких задач выполняется одновременно, и от количества свободных потоков для других задач.

Увеличение количества процессов Sidekiq до 6 и более (с 5 потоками) ускоряет очистку очереди, но PostgreSQL довольно регулярно падает (я предполагаю, из-за одновременного выполнения слишком большого количества задач Jobs::PostAlert).

Это происходит в версии Stable 3.3.2. Изменения и исправления из связанной темы, по-видимому, уже внедрены в 3.3.2, если я не ошибаюсь.

supermathie · 19.Декабрь.2024 16:11:59

Postgres никогда не должен падать, и это обычно указывает на ошибку в Postgres или какую-то более крупную проблему.

Есть ли у вас логи?

Ed_S · 19.Декабрь.2024 17:10:16

Перезагружали ли вы сервер после внесения изменений в конфигурацию ядра?

Ed S:

мой список стандартных мгновенных диагностических команд:
cat /etc/lsb-release
uptime
df -h /
free
vmstat 5 5
dmesg|egrep -i "memory|oom|kill"
ps auxrc

Возможно, также будет полезно выполнить

lscpu

Falco · 19.Декабрь.2024 17:21:45

Никогда не устанавливайте UNICORN_SIDEKIQS на такое высокое значение, увеличивая только количество воркеров, но

Такого никогда не должно происходить.

Возможные причины:

Ограничение ресурсов, потому что либо
a) Ваш сайт вырос больше, чем позволяют ресурсы сервера
b) Вы неправильно распределяете ресурсы
Где-то в стеке есть ошибка

Я бы начал с настройки:

UNICORN_SIDEKIQS: 1
DISCOURSE_SIDEKIQ_WORKERS: 20

что должно освободить часть оперативной памяти на вашем сервере.

Для получения дополнительной информации вам нужно будет запустить проблемные задачи в консоли PostgreSQL и сообщить, в чём заключается узкое место.

markersocial · 16.Февраль.2026 07:10:20

Приношу извинения за исчезновение и благодарю за ответы.

Я считаю, что основной причиной медленной работы Redis было то, что THP всё ещё был включён (хотя я думал иначе):

Для решения проблемы с падением PostgreSQL главным решением для меня стало добавление этого в app.yml:

docker_args:
  - "--shm-size=34g"

Значение установлено как db_shared_buffers + 2 ГБ, где db_shared_buffers составляет 25% от общей оперативной памяти хост-машины.

Переопределение значения по умолчанию 512 МБ:

github.com/discourse/discourse_docker

launcher

4ae1f6914


      
               if [ -z "$SKIP_MAC_ADDRESS" ] ; then
                mac_address="--mac-address $($docker_path run $user_args -i --rm -a stdout -a stderr $image /bin/sh -c "echo $hostname | md5sum | sed 's/^\(..\)\(..\)\(..\)\(..\)\(..\).*$/02:\1:\2:\3:\4:\5/'")"
               fi
          
               if [ ! -z "$START_CMD_ONLY" ] ; then
                 docker_path="true"
               fi
          
               set -x
          
               $docker_path run --shm-size=512m $links $attach_on_run $restart_policy "${env[@]}" "${labels[@]}" -h "$hostname" \
                  -e DOCKER_HOST_IP="$docker_ip" --name $config -t "${ports[@]}" $volumes $mac_address $user_args \
                  $run_image $boot_command
          
             )
             exit 0
          
          }
          
          run_run() {
            set_template_info

github.com/discourse/discourse_docker

launcher

4ae1f6914


      
          
          }
          
          run_run() {
            set_template_info
            set_volumes
            set_links
            set_run_image
          
            unset ERR
            (exec $docker_path run --rm --shm-size=512m $user_args $links "${env[@]}" -e DOCKER_HOST_IP="$docker_ip" -i -a stdin -a stdout -a stderr $volumes $run_image \
              /bin/bash -c "$run_command") || ERR=$?
          
            if [[ $ERR > 0 ]]; then
              exit 1
            fi
          }
          
          run_bootstrap() {
            set_template_info

github.com/discourse/discourse_docker

launcher

4ae1f6914


      
              pups_command="$pups_command git pull && git checkout $pups_version &&"
            fi
            pups_command="$pups_command /pups/bin/pups --stdin"
          fi
          
          echo $pups_command
          
          declare -i BOOTSTRAP_EXITCODE
          rm -f $cidbootstrap
          
          echo "$input" | $docker_path run --shm-size=512m $user_args $links "${env[@]}" -e DOCKER_HOST_IP="$docker_ip" --cidfile "$cidbootstrap" -i -a stdin -a stdout -a stderr $volumes $image \
            /bin/bash -c "$pups_command"
          BOOTSTRAP_EXITCODE=$?
          
          CONTAINER_ID=$(cat "$cidbootstrap")
          rm -f "$cidbootstrap"
          
          # magic exit code that indicates a retry
          if [[ $BOOTSTRAP_EXITCODE -eq 77 ]]; then
            $docker_path rm "$CONTAINER_ID"
            exit 77

Ed_S · 16.Февраль.2026 12:13:37

markersocial:

Для устранения падения PG главным решением для меня было добавление этого в app.yml:
docker_args:
  - "--shm-size=34g"

Я просмотрел вашу историю сообщений и увидел в теме Очень медленный Sidekiq … огромное количество непрочитанных уведомлений пользователей, что вы используете сервер с 32 ядрами и 128 ГБ ОЗУ и имеете очень большую и активную базу пользователей. В таком контексте я понимаю, почему 34 ГБ — не такая уж большая цифра! Однако для контекста может быть полезно (и интересно) узнать масштаб вашей установки — возможно, здесь или даже в вашем профиле? (например, количество ежедневных и ежемесячных активных пользователей, размер резервных копий базы данных, конфигурация сервера: ОЗУ, swap, диск, процессоры). Может быть, даже создать тему, где мы просто будем делиться своей статистикой — как для больших, так и для малых установок.

Тема		Ответов	Просм.
Redis used_memory limited to 1024mb? Support	2	178	16.02.2026
Could sidekiq queue be reason for 500 errors? Self-hosting server-resources	31	4020	13.07.2018
Sidekiq is consuming too much memory, restarting Self-hosting	40	9006	13.10.2020
Redis connection timed out Self-hosting	30	9713	08.06.2024
Locks up while running Sidekiq after migration Self-hosting	6	2400	24.12.2017

Сетевое соединение Redis работает крайне медленно

Связанные темы