“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오후

이어서 말씀드리자면, Jobs::PostAlert에서도 동일한 문제를 겪고 있습니다:

현재 테스트 환경에서 사이드킥 4개와 기본 5개 스레드를 사용할 때 해당 잡들이 15분까지 걸리는 경우가 잦습니다. 사이드킥의 초당 처리 속도는 동시에 실행되는 잡의 수와 다른 잡을 위해 사용 가능한 스레드 수에 크게 의존하는 것 같습니다.

사이드킥을 6개 이상(스레드 5개)으로 늘리면 큐 처리 속도는 빨라지지만, Postgres가 비교적 자주 충돌합니다(동시에 실행되는 Jobs::PostAlert 잡이 너무 많아서 그런 것으로 추정됩니다).

현재 Stable 3.3.2 버전을 사용하고 있습니다. 제가 아는 한, 링크된 스레드의 변경 사항 및 수정 내용은 3.3.2에 이미 구현된 것으로 보입니다.

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

Postgres는 절대 충돌해서는 안 되며, 일반적으로 postgres의 버그나 더 큰 문제를 나타냅니다.

로그가 있으신가요?

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

커널 설정을 변경한 후 서버를 재시작하셨나요?

아마도

lscpu

명령도 도움이 될 것 같습니다

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

UNICORN_SIDEKIQS를 그렇게 높게 올리는 것은 절대 하지 않아야 하며, 워커만 늘리는 것은

이러한 일은 절대 일어나서는 안 됩니다.

가능한 원인은 다음과 같습니다:

리소스에 제약이 있는 경우
a) 사이트가 서버 리소스를 초과하여 성장한 경우
b) 리소스를 잘못 할당하고 있는 경우
스택 어딘가에 버그가 있는 경우

다음과 같이 설정을 변경하는 것으로 시작해 보세요.

UNICORN_SIDEKIQS: 1
DISCOURSE_SIDEKIQ_WORKERS: 20

이렇게 하면 서버의 RAM 일부를 해제할 수 있습니다.

자세한 정보를 얻으려면 문제 있는 작업(PostgreSQL 콘솔에서 실행)을 실행하고 병목 현상이 무엇인지 보고해야 합니다.

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	241	2월 16, 2026
Could sidekiq queue be reason for 500 errors? Self-hosting server-resources	30	4196	6월 13, 2018
Sidekiq is consuming too much memory, restarting Self-hosting	38	9313	10월 13, 2020
Redis connection timed out Self-hosting	29	9977	7월 2, 2018
Locks up while running Sidekiq after migration Self-hosting	6	2470	12월 24, 2017

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

Related topics