Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
  
[+] Expand All
[-] Collapse All

Understanding the Memory Utilization Levels

This section provides information on the memory utilization levels for SBRC standalone and SBRC SSR cluster setups. It explains:

Memory Utilization on Standalone

Table 10 describes the memory utilization levels for the SBRC standalone setup. Remember, SBR standalone is limited to a maximum of 4G of memory utilization, in which the CurrentSessions as well as the operating memory for SBR transaction processing must be maintained.

Table 10: Memory Utilization on Standalone

Parameter

Data Memory

SA Overhead Bytes per Record (BpR)

SA Maximum BpR

SA Reasonable BpR

Current Sessions

Memory for data (per session)

688

5294

1116

IP Addresses

Memory (per IP)

14 + (#ips*24/256)

14 + (#ips*24/256)

CDR Acct Records

Memory (per session)

LDAP CDR server for SS7, separate memory space, possibly separate machine, similar to cluster sizing

LDAP CDR server for SS7, separate memory space, possibly separate machine, similar to cluster sizing

SimAkaPseudonymKeys

Memory (per key)

64

64

64

SimAkaReauthCache

Data memory (per cache)

228

1514

1514

SMSAccounts

Data memory (per Acct)

N/A

TtlsResumptionAttrs

Data memory (per TTLS session)

104

8152

Reasonable values vary widely with attribute stored

TtlsResumptionCache

Data memory (per TTLS session)

132

7620

Reasonable values vary with key size and other items

UserConcurrency

Data memory (per concurrency entry)

N/A

WiMaxDHCPRootKeys

Data memory (per DHCP root key)

208

208

208

WiMaxHaRootKeys

Data memory (per HA root key)

208

208

208

WimaxMobilityKeys

Data memory (per WiMAX session)

604

2394

Varies widely

Memory Utilization on SSR Cluster

Table 11 describes the memory utilization levels for the SSR cluster setup.

Table 11: Memory Utilization on SSR Cluster

Parameter

Data/Index Memory

NDB Overhead Bytes per Record (BpR)

NDB Maximum BpR

NDB Reasonable BpR

Current Sessions

Data memory (per session)

344

4684

772

Data memory for unique indexes (per session)

324

968

472

Index memory (per session)

192

192

192

IP Addresses

Data memory (per IP)

104

104

104

Index memory (per IP)

32

32

32

CDR Acct Records

Data memory (per session)

296

2320

764

Index memory (per session)

16

16

16

SimAkaPseudonymKeys

Data memory (per key)

72

72

Index memory (per key)

32

32

32

SimAkaReauthCache

Data memory (per cache)

600

1888

Index memory (per cache)

16

16

16

SMSAccounts

Data memory (per Acct)

360

1824

Index memory (per Acct)

16

16

16

TtlsResumptionAttrs

Data memory (per TTLS session)

104

8152

~3800

Index memory (per TTLS session)

16

16

16

TtlsResumptionCache

Data memory (per TTLS session)

120

7604

~4800

Index memory (per TTLS session)

16

16

16

UserConcurrency

Data memory (per concurrency entry)

116

200

200

Index memory (per concurrency entry)

16

16

16

WiMaxDHCPRootKeys

Data memory (per DHCP root key)

56

120

120

Index memory (per DHCP root key)

48

48

48

WiMaxHaRootKeys

Data memory (per HA root key)

112

112

112

Index memory (per HA root key)

16

16

16

WimaxMobilityKeys

Data memory (per WiMAX session)

5760

5760

Varies widely

Index memory (per WiMAX session)

128

128

128

  • Overhead—In standard model, this column includes zero-length data for each variable-length field.
  • Reasonable—Include the most used AVPs with expected and usual length fields. In certain cases, adding customer-defined fields can increase the memory utilization for a particular use case over the defined reasonable values.
  • Maximum—In certain cases, this column is entirely filled with data, and might go over this with customer-defined fields.

Note: The data memory and index memory mentioned in Table 11 for the SSR cluster refer to settings in the /opt/JNPRhadm/config.ini file.

You can accurately determine the reasonable values by examining a few instances of the live RADIUS traffic and determining the actual lengths of typical data in the fields that are stored in the SSR. Add the actual length of data to the overhead column to construct a reasonable model of a session for your case. You can increase the data by 10 to 20 percent, as a margin of safety and for future expandability, and calculate the total usage.

The SSR memory requirement per D node for a system is calculated as follows:

  1. Add the data memory and index memory values together for the expected values of sessions/addresses and other rows.
  2. Multiply the value by the maximum number of concurrent sessions that will be supported.
  3. Divide the value by the number of stripes (1, 2, or 3 for 2-, 4-, or 6-node SSRs, respectively).
  4. Add 2G for the system overhead.
  5. Round up to the next multiple of memory sizing (usually 2G or 4G increments).

Modified: 2017-09-26