publish가 멈춘 것처럼 보이고 memory alarm이 있으면 먼저 어느 노드의 어떤 자원 알람인지 확인합니다. 큐 메시지가 많다는 사실과 메모리의 주요 사용 주체가 큐라는 사실은 다릅니다. disk alarm과 transient flow control도 같은 이름으로 기록하지 않습니다.
rabbitmq-diagnostics alarms
rabbitmq-diagnostics memory_breakdown
rabbitmqctl list_queues -p example-vhost name messages_ready messages_unacknowledged consumers자신의 vhost로 바꿔 조회하고 같은 간격의 스냅샷을 두 번 이상 비교합니다. 알람 문서는 발행 연결의 back pressure와 클러스터 범위를 설명합니다. 소비 전용 연결은 계속 처리할 수 있지만 publish와 consume을 같은 연결에 섞으면 영향을 단순하게 분리하기 어렵습니다.
세 관찰 조합은 서로 다른 질문을 만든다
ready가 증가하고 consumers가 0이면 consumer 배포·연결부터 확인합니다. consumers가 있는데 unacked가 계속 증가하면 처리 시간·ACK 누락·prefetch를 비교합니다. ready와 unacked가 안정적인데 연결 수와 connection 메모리가 증가하면 연결 생성·재사용·종료 정책을 봅니다. 이 조합은 진단 가설이며 실제 브로커에서 측정한 수치가 아닙니다.
메모리 분석 문서의 항목별 분포를 큐 수치와 함께 읽어야 합니다. RSS나 queue length 하나로 누수라고 판단하거나 watermark부터 높이면 실제 사용 증가를 가릴 수 있습니다. 큐 종류와 버전별 저장 동작도 확인해야 합니다.
수정 후에는 알람 해제뿐 아니라 소비율·unacked 추이·발행 confirm 결과를 확인합니다. 연결 복구는 메시지 처리의 정확히 한 번 수행을 보장하지 않으므로 재시도와 중복 처리 정책도 별도로 검토합니다. 이 글은 실제 브로커 복구 결과를 주장하지 않습니다.