“Redis 네트워크 연결이 극도로 불안정합니다”

markersocial · 12월 12, 2024, 10:26오후

로그에 이 메시지가 지속적으로 출력되고 있습니다. 값은 약 10만에서 약 135만 사이를 오가지만, 10만 근처의 값이 꽤 자주 나타나는 것 같습니다:

Your Redis network connection is performing extremely poorly. Last RTT readings were [97069, 103986, 98459, 100762, 381617], ideally these should be < 1000. Ensure Redis is running in the same AZ or datacenter as Sidekiq. If these values are close to 100,000, that means your Sidekiq process may be CPU-saturated; reduce your concurrency and/or see https://github.com/mperham/sidekiq/discussions/5039

이것은 Redis가 충분한 CPU를 사용하지 못하고 있다는 것을 시사할 수 있습니다. 하지만 서버 자체에는 CPU와 RAM에 여유가 충분한 것으로 보입니다.

또한:
Sidekiq is consuming too much memory (using: 3570.19M) for 'www.example.com', restarting

이는 Discourse stable 3.3.2의 올인원 app.yml을 사용하고 있습니다.

app.yml 내용:

UNICORN_SIDEKIQS: 9
DISCOURSE_SIDEKIQ_WORKERS: 5

호스트에도 다음 구성을 추가했습니다:

Michael K Johnson:

커널 구성

Redis(Discourse가 구축된 핵심 구성 요소 중 하나)는 디스크 기반 영속성을 사용할 때 투명 거대 페이지(transparent huge pages)를 비활성화할 것을 강력히 권장합니다(Discourse는 이를 수행합니다). 또한 메모리 오버커밋(memory overcommit)도 허용합니다.
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가 1024M 메모리 사용량을 넘어서지 못하는 것으로 보입니다.

혹시 아이디어가 있으신 분, 조언 부탁드립니다!

markersocial · 12월 19, 2024, 2:38오후

To follow up with this, I’m having this same issue with Jobs::PostAlert:

With those jobs often going up to 15 minutes when using 4 sidekiqs with 5 (default) threads with current testing. Seems like the jobs per second speed for Sidekiq is mostly dependent on how many of those jobs are being ran simultaneously and how many threads are free for the other jobs.

Increasing Sidekiqs to 6 or higher (5 threads) will increase the queue clearing speed, but postgres will crash fairly regularly (I am guessing from too many Jobs::PostAlert jobs being ran simultaneously.

This is on Stable 3.3.2. The changes and fixes from the linked thread seem to be already be implemented in 3.3.2, if I am not mistaken.

supermathie · 12월 19, 2024, 4:11오후

Postgres should never crash and generally indicates a postgres bug or some sort of larger problem.

Do you have logs?

Ed_S · 12월 19, 2024, 5:10오후

Have you rebooted the server since making those kernel config changes?

Maybe

lscpu

would also be helpful

Falco · 12월 19, 2024, 5:21오후

You should never bump UNICORN_SIDEKIQS that high, only increasing workers but

This should never happen.

The possibilities are:

You are constrained on resources because either
a) Your site has over grown the server resources
b) You are misallocating resources
There is a bug somewhere in the stack

I’d start making

UNICORN_SIDEKIQS: 1
DISCOURSE_SIDEKIQ_WORKERS: 20

which should release some RAM from your server.

For further information you will need to run the offending jobs in a PostgreSQL console and report what is the bottleneck.

markersocial · 2월 16, 2026, 7:10오전

갑자기 사라져서 죄송합니다. 답변해 주셔서 감사합니다.

Redis가 느린 주요 원인은 THP가 여전히 활성화되어 있었기 때문이라고 생각합니다(비활성화되어 있다고 생각했었거든요):

PG 크래시의 경우, 제게 주된 해결책은 app.yml에 다음 내용을 추가하는 것이었습니다:

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

값은 db_shared_buffers + 2GB로 설정했으며, db_shared_buffers는 호스트 머신의 총 RAM의 25%입니다.

기본값 512m를 오버라이드하는 부분:

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 · 2월 16, 2026, 12:13오후

질문자님의 게시글 히스토리를 다시 살펴보니, 매우 느린 Sidekiq 문제 … 대량의 읽지 않은 사용자 알림에서 32코어 128GB 서버를 매우 크고 활발한 사용자 기반과 함께 운영하고 계셨다는 것을 확인했습니다. 그런 맥락에서는 34GB가 그리 큰 수치가 아니라는 이유를 이해할 수 있습니다. 다만 맥락을 제공하기 위해, 설정의 규모를 아는 것이 도움이 될 수 있고(재미있을 수도 있습니다) - 여기에서 또는 심지어 프로필에서 그렇게 할 수 있을까요? (일일 및 월간 활성 사용자 수, 데이터베이스 백업 크기, RAM, 스왑, 디스크, CPU의 서버 구성 등.) 심지어 우리가 모두 통계 - 크고 작은 것들을 공유하는 스레드도 만들 수 있을지 모릅니다.

글		댓글	조회수
Redis used_memory limited to 1024mb? Support	2	233	2월 16, 2026
Could sidekiq queue be reason for 500 errors? Self-hosting server-resources	30	4169	6월 13, 2018
Sidekiq is consuming too much memory, restarting Self-hosting	38	9256	10월 13, 2020
Redis connection timed out Self-hosting	29	9918	7월 2, 2018
Locks up while running Sidekiq after migration Self-hosting	6	2458	12월 24, 2017

“Redis 네트워크 연결이 극도로 불안정합니다”

Related topics