“50% memory usage and rising — is this normal?” is a question I get a lot, usually preceded by “We’ve had the appliance for six months and we’ve never seen it this high.” The answer is almost always “it depends” — but “it depends” is not a satisfying answer when you’re looking at a DataPower at 2am and trying to decide whether to open a severity-1 with IBM.

The Abu Dhabi Islamic Bank case was a good example of why comparing raw memory percentages between HA pair appliances is misleading. Their secondary appliance showed consistently higher memory usage than the primary — same firmware, same firmware version, same traffic pattern, same configuration. They had screenshots of both appliances’ memory dashboards and were preparing to open a ticket about the secondary. When we looked at it properly, both appliances were within normal parameters for their firmware version and traffic load. The apparent difference was because the secondary had been running for a longer period since its last restart, while the primary had been restarted during a recent maintenance window. The baseline was simply different.

This article is about knowing what normal looks like for your specific environment, so you can tell the difference between expected growth and a genuine problem.

1. How DataPower Allocates Memory

DataPower’s memory is divided into several regions:

  • Firmware-reserved memory: The operating system and DataPower firmware services reserve a portion of total memory. This is not available for application use.
  • Domain memory: Each DataPower domain has its own memory allocation. Domains process API traffic and run configurations.
  • Application buffers: DataPower uses buffers for XML parsing, JSON processing, HTTP connection handling, and XSLT transformations. These are allocated from a shared buffer pool.
  • Compilation cache: GatewayScript and XSLT compiled code is cached. More traffic means more compiled code in cache, which means more memory used.

What this means for comparing HA pairs: The raw percentage reported by show memory on each appliance is the percentage of the firmware-reserved pool, not total system memory. Because the two appliances in an HA pair may have different uptime (and therefore different cache/buffer fill levels), their reported percentages will naturally differ even under identical traffic loads. The Abu Dhabi case demonstrated this exactly.

Key metrics from show memory (DataPower CLI):

DataPower# show memory

System Memory: 8192 MB (8 GB)
Application Memory Available: 4123 MB
Firmware Memory: 2048 MB
Domain Memory Usage:
  default-domain: 1203 MB
  payment-domain: 876 MB
  b2b-domain: 412 MB

The number to watch is Application Memory Available trending over time. If it decreases consistently day-over-day without corresponding traffic growth, you may have a memory leak.

2. Normal Memory Growth vs. Genuine Memory Leak

Memory growth in DataPower is expected in three scenarios:

Expected growth:

  • New APIs deployed → new domain configurations loaded → more domain memory
  • Traffic growth → more application buffers allocated
  • Longer uptime → larger compilation cache

Leak indicators:

  • Application Memory Available decreases by more than 10% per day with no change in traffic or configuration
  • A specific domain’s memory allocation grows continuously without plateauing
  • After restarting the domain (without restarting the appliance), memory does not return to baseline

Diagnosing with error report:

The DataPower error report contains system status objects that track memory over time:

# In DataPower CLI — generate an error report
# This captures system status objects over a time window
generate error-report

# The error report is saved to /irmware:/var/log/errlog/ or similar
# Look for: SystemStatusObject, DomainStatusObject
# These show memory allocated to each domain over the capture window

Key metrics to compare over 24-48 hours:

DomainStatusObject for domain: payment-domain
  Memory allocated (bytes):        922,746,880  (baseline: ~880MB at start of window)
  Request count:                  1,204,521
  Average response time (ms):     12.4
  Current connection count:        345

If the memory allocated is growing with no plateau and request count is stable, you likely have a leak in that domain’s configuration or GatewayScript code.

3. CPU Spikes: Three Most Common Causes

Cause 1: Burst traffic

A sudden increase in API traffic — a batch job starting, a traffic spike from a partner system — will cause CPU to spike as DataPower processes the incoming requests. This is expected behaviour.

Diagnosis: Correlate the CPU spike with request logs showing increased traffic volume. If the spike lasts exactly as long as the burst and then subsides, this is normal.

Cause 2: Large payload processing

Processing multi-megabyte XML or JSON payloads (common in B2B integrations, file transfer APIs) causes brief CPU spikes as DataPower parses, validates, and transforms the content. The larger the payload, the more CPU consumed.

Diagnosis: Look at show statistics for the domain handling the spike. Large request sizes and response sizes will correlate with the spike. This is expected for large payloads but can become a problem if partners start sending payloads larger than your configured limits.

Cause 3: First-call XSLT/GatewayScript compilation

The first time an XSLT stylesheet or GatewayScript module is executed after a domain restart, it must be compiled. This compilation is CPU-intensive. Subsequent calls use the cached compiled version and are significantly faster.

Diagnosis: If CPU spikes correlate with a domain restart, an XSLT or GatewayScript deployment, or an API product publish, this is almost certainly first-call compilation. It should only happen once. If it happens repeatedly, the compilation cache may be too small.

Collecting CPU data for IBM support cases:

IBM support often asks for CPU screenshots — the pattern is well-established. The Abu Dhabi team attached screenshots of their HA pair CPU graphs showing sustained elevated CPU, which helped identify a genuine performance issue rather than burst traffic.

For a support case, collect:

# From DataPower CLI — capture system status with CPU metrics
show status

# Export system status history (if available in your firmware)
# For recent firmware versions:
# system-status-history <output-format>

# Capture statistics for the affected domain
show statistics domain <domain-name> format xml | head -200

4. Collecting Right Diagnostic Data for Performance Issues

Before opening a performance support case, collect:

Object and statistics from error report:

# Generate error report covering the problem period
generate error-report from "2026-07-12T00:00:00" to "2026-07-12T06:00:00"

# Look for:
# - SystemStatusObject: shows overall CPU and memory over time
# - DomainStatusObject: per-domain memory and request metrics
# - XMLProcessingUsage: XML buffer pool usage
# - HTTPConnectionStatus: connection counts by domain

Key DataPower CLI commands:

# Memory summary
show memory

# Per-domain memory detail
show domain-memory

# Active connections by domain
show connections

# CPU usage by domain
show cpu domain all

# XML manager buffer pools (if XML processing is suspected)
show xml-managers

5. Performance Tuning Levers

Document cache sizing:

// In DataPower domain configuration:
{
  "name": "default-domain",
  "document-cache": {
    "max-entries": 10000,      // Max cached documents — increase if cache evictions are high
    "max-size": 104857600,     // 100 MB max total cache size
    "ttl": 3600                // Time-to-live for cached entries in seconds
  }
}

Connection pool configuration:

// Multi-protocol gateway connection pool settings:
{
  "connection-pool": {
    "max-connections": 200,      // Per domain, per interface
    "min-connections": 10,       // Kept warm
    "connection-timeout": 30000, // ms
    "idle-timeout": 60000        // ms
  }
}

Thread count — caveat on defaults:

DataPower’s default thread count is tuned for a balanced workload. Increasing thread counts beyond firmware-recommended values can actually decrease performance by causing excessive context switching. Do not change thread count without IBM guidance.

6. Triage Checklist: Five Questions Before Opening a Support Case

Answer these before you call IBM:

  1. Is the appliance still processing traffic? If yes, is performance degraded or is it fully functional? Note exact response times before and after the issue started.
  2. What changed immediately before the issue started? New API deployed? Firmware upgraded? Configuration change? Traffic pattern change?
  3. Is the issue on one appliance or both in an HA pair? If only one, is it the primary or secondary? What does HA status show?
  4. Is Application Memory Available decreasing consistently day-over-day, or has it plateaued? Provide a graph of memory usage over at least 48 hours.
  5. What error messages appear in the DataPower logs? Export the relevant log entries for the problem period. Never describe errors — show them.

Having these five answers ready when you call IBM support will dramatically accelerate the case resolution. Screenshots of CPU and memory graphs (as IBM support asked for in the Abu Dhabi case) are worth more than written descriptions.

Next: “DataPower B2B Gateway: Surviving RAID Full and SFTP Regressions After a Firmware Upgrade” — RAID emergency procedures, SFTP key exchange regressions, and B2B partner connectivity testing.