목차

소개

문제

문제 해결

솔루션

소개

이 문서에서는 많은 수의 HTTP 흐름으로 인해 WARN 상태가 되는 sessmgr의 문제를 설명합니다.이 문제는 Cisco ASR(Aggregated Service Router) 5x00에서 보고됩니다.

문제

Sessmgr 상태는 WARN 및 메모리 사용률이 높습니다.

******** show task resources *******

Thursday July 24 17:44:58 IST 2014

task   cputime        memory     files      sessions

cpu facility      inst used allc   used  alloc used allc  used  allc S status

----------------------- --------- ------------- --------- ------------- ------

4/0 sessmgr          3  26% 100%  1.86G  1.86G   34  500  1766 28160 I   warn

이러한 오류 로그는 프로세스에서 생성됩니다. 이 오류 로그로 인해 구독자에 영향을 주지 않습니다.WARN 상태에 있는 sessmgr에서 통화가 거부되면 설계에 따라 시스템이 다른 sessmgrs에서 시도하고 통화가 연결됩니다.

[sessmgr 10018 error] [4/0/6812 <sessmgr:3> sessmgr_func.c:44683] [software internal system syslog] Sessmgr-3 full (35200 effective number of calls, 1777 calllines in use, 51146 free flows, 31221 free aaa_sessions, 1777 used-mem-credits, 1777 used-sess-credits, 1948360 mem-usage, 1945600 mem-limit, 0 ecs-queue-usage, 70400 ecs-queue-limit, 16850 ecs-num-flows, 400000 ecs-max-flows, 2334720 ecs-mem-limit[ecs-flow/mem-values:valid], 0x86 limit-flags) - call rejected

문제 해결

show support details 출력을 캡처하고 추가 트러블슈팅을 위해 명령 출력을 확인합니다.

메모리 문제는 sessmgr에서 처리하는 흐름의 양과 관련이 있습니다.메모리 소비량이 높고 플로우가 많은 sessmgr 간에 상관관계가 나타날 수 있습니다.

******** debug acsmgr show memory usage *******

Thursday July 24 17:50:06 IST 2014

------------------------------------------------------------------------------

!                !               Caches Count              !

Instance Memory !      Flows     !   Callline    Data-Session  TCP OOO     !

! Current    Max ! Total   Free  Total   Free  Total   Free!

--------------------------------------------------------------------------------

1 865.68M  43365  64360     5500   1178  56140  12775   1102   1064

2 852.05M  43879  64767     5500   1178  60150  16271   1102   1067

3 1902.68M  17252 276519    4400   2631  44110  26858    551    541

영향을 받는 sessmgrs(그리고 영향을 받지 않는 한 개의 경우)의 경우 이러한 명령 출력을 수집합니다. 여기서 x는 Sessmgr 인스턴스입니다.

show messenger proclet facility sessmgr instance <x> heap

show messenger proclet facility sessmgr instance <x> system heap

task core facility sessmgr instance <x>

show active-charging flows instance <x>

show profile facility sessmgr active depth 8 head 201

show task resources faciltity sessmgr instance <x> max

최적화되지 않은 규칙과 규칙 그룹이 많은 메모리를 사용하는지 확인합니다.

debug acsmgr show rule-optimization-information

debug acsmgr show grp-of-rdef-optimization-information

가장 높은 메모리 소비량은 명령 출력을 기반으로 하는 이러한 함수 때문입니다.

acs_http_pkt_inspection()

acsmgr_alloc_buffer()

snx_add_dbufs()

sn_aaa_alloc_session_block()

sgx_imsa_bind_user()

또한 Max No of Simultaneous HTTP Flows from Calls lines(통화 라인에서 얻은 최대 동시 HTTP 흐름 수)를 선택할 수도 있습니다

******** debug acsmgr show flow-stats max-simultaneous-flows http *******

Thursday July 24 17:50:04 IST 2014

Histogram of Max No of Simultaneous HTTP Flows attained by Calllines

No Of Flows             No Of Calllines

1 to 10                 964712518

11 to 20                384105002

21 to 40                232987189

41 to 100               148938918

101 to 200              115919586

201 to 500              86729303

501 to 1000             69975385

1001 to 2000            59635906

2001 to 5000            50743511

5001 to 10000           44566999

> 10000                 1044671491

******** debug acsmgr show flow-stats cumulative http *******

Thursday July 24 17:50:03 IST 2014

Histogram of Total Cumulative HTTP Flows by Calllines

No Of Flows             No Of Calllines

1 to 10                 964712485

11 to 20                384104980

21 to 40                232987175

41 to 100               148938911

101 to 200              115919583

201 to 500              86729297

501 to 1000             69975377

1001 to 2000            59635907

2001 to 5000            50743509

5001 to 10000           44567004

> 10000                 1044671452

많은 수의 HTTP 세션이 할당되고 있으며 이는 HTTP 트래픽이 많기 때문일 수 있다고 결론지을 수 있습니다.또한 거의 104671491 Calllines가 있으며, 이 통화는 한 번에 10000개가 넘는 HTTP 플로우를 가집니다.이로 인해 메모리 사용량이 증가합니다.

솔루션

가입자당 플로우 수를 제한하는 CLI가 있습니다.

flow limit-across-applications

Cisco는 많은 HTTP 트래픽을 볼 수 있는 영향을 받는 모든 Rule-Base에서 흐름 제한-애플리케이션을 5000으로 구성하는 것이 좋습니다.

명령을 구성하는 절차입니다.

In local context under Global configuration.

# active-charging service ECS

(config-acs)# rulebase GOLIVE

(config-rule-base)# flow limit-across-applications 5000

이 명령에 대한 자세한 정보.

흐름 애플리케이션 간 제한

이 명령을 사용하면 흐름 유형에 관계없이 규칙 기반으로 전송되는 가입자/APN당 동시 흐름의 총 수를 제한하거나 세션 제어 기능의 프로토콜 유형을 기반으로 플로우를 제한할 수 있습니다.

제품:

ACS

권한:

보안 관리자, 관리자

모드:

Exec > ACS Configuration> Rulebase Configuration

active-charging service service_name > rulebase rulebase_name

Entering the above command sequence results in the following prompt:

[local]host_name(config-rule-base)#

구문

flow limit-across-applications { limit | non-tcp limit | tcp limit }no flow limit-across-applications [ non-tcp | tcp ] no

이전에 구성한 경우 현재 규칙에서 flow-limit-across-applications 컨피그레이션을 삭제합니다.

흐름 애플리케이션 간 제한

규칙에 대한 모든 애플리케이션에서 최대 플로우 수를 지정합니다.

limit는 1부터 4000000000 사이의 정수여야 합니다.

기본값:제한 없음

비 TCP 제한

비 TCP 유형 흐름의 최대 제한을 지정합니다.

limit는 1부터 4000000000 사이의 정수여야 합니다.

기본값:제한 없음

tcp 제한

TCP 흐름의 최대 제한을 지정합니다.

limit는 1부터 4000000000 사이의 정수여야 합니다.

기본값:제한 없음

사용법:

이 명령을 사용하여 흐름 유형에 관계없이 규칙에 허용되는 총 플로우 수를 제한하거나 프로토콜(비TCP(연결 없음) 또는 TCP(연결 지향)에 따라 흐름을 제한합니다.

가입자가 이러한 제한을 초과하려고 하면 새 흐름의 패킷이 삭제됩니다.이 명령의 제한 처리에는 UDP, TCP, ICMP 및 일부 제외된 흐름에 대해 다음과 같은 측면이 있습니다.

- UDP/ICMP:시스템은 플로우 시간 초과를 기다렸다가 카운터를 업데이트하고 흐름 개수에서 제거합니다.

- TCP:TCP 흐름이 종료된 후 시스템은 한 끝에서 누락된 패킷의 재전송을 수용하기 위해 짧은 시간 동안 기다립니다.종료되었지만 대기 중인 TCP 흐름은 이 제한 처리에 대해 시간 초과가 면제됩니다.

- 제외된 플로우:ACS Charging Action Configuration Mode(ACS 충전 작업 컨피그레이션 모드)에서 flow limit-for-flow-type 명령으로 지정된 다른 모든 흐름은 no(no)로 예외됩니다.

예:

이 명령은 규칙에 대한 최대 200000 흐름 수를 정의합니다.

flow limit-across-applications 200000