Host Guidance

AMPS can run on physical hardware, virtual machines, or containers. The right hosting model depends on the performance, latency, and deployment flexibility needed by the application.

Use the Capacity Planning section to size memory, storage, CPU, and network resources for an AMPS deployment. Use this section to plan how those resources are provided by the host environment.

Physical Servers, Virtual Machines, Containers

Although AMPS is designed to be highly adaptive to hardware on which it runs, AMPS does not require a dedicated physical server. AMPS can be successfully deployed on physical hardware, virtual machines, or containers. In any deployment model, 60East recommends tuning Linux for best performance rather than accepting the distribution defaults, which are typically tuned for interactive use rather than for a high performance server.

Typically, installations that require the highest level of performance and lowest levels of latency deploy on physical hardware, with a single AMPS instance per server. Installations that are willing to trade predictable performance for ease and flexibility of deployment often use virtual machines or containers.

Virtual machines and containers both add a layer between AMPS and the physical host resources. Plan capacity, monitoring, and performance testing for the underlying host as well as for the virtual machine or container that runs AMPS.

Physical Servers

For deployments that require the highest throughput, most consistent latency, or the greatest isolation from other workloads, 60East recommends running one AMPS instance on a dedicated physical server.

Choose the server configuration for the expected workload. A processor with the largest available core count is not necessarily the best processor for every AMPS deployment.

Primary workload	Hardware characteristics to prioritize
SOW queries, views, joins, aggregations, and content filtering	Strong sustained per-core performance, high memory bandwidth, and enough physical cores for the expected concurrent workload
High-rate publishing, replication, queue delivery, and transaction log replay	More physical cores, sufficient network bandwidth, and high sustained sequential storage performance
Large SOW topics, views, indexes, or large query result sets	Memory capacity, memory bandwidth, and fast random-access storage
Low and predictable latency	Dedicated resources, strong sustained CPU frequency, fully populated memory channels, local low-latency storage, network interfaces capable of kernel bypass, and performance-oriented Linux tuning

CPU Selection

Consider both physical core count and sustained clock frequency when selecting a CPU.

Higher core counts help AMPS process independent work concurrently, including simultaneous queries, publishers, subscribers, replication connections, and transaction log readers. However, increasing core count often reduces the processor's base or sustained all-core frequency. A high-core-count processor with a relatively low sustained frequency may perform well as a publishing, replication, or replay server while providing less desirable response times for CPU-intensive queries, views, and aggregations.

Do not make sizing decisions using maximum turbo frequency alone. Compare the sustained frequency the processor can maintain while the expected number of cores is active. Validate the processor using the actual server power, cooling, firmware, and BIOS configuration that will be used in production. When comparing different CPU SKUs of the same generation, the model with the highest CPU core count to frequency product ($\text{CPUCount} \times \text{Frequency}$) typically offers a good initial comparison metric, subject to workload validation.

60East recommends enabling simultaneous multithreading, such as Intel Hyper-Threading or AMD SMT, when available. AMPS benefits from SMT because many workloads alternate between CPU execution and waiting for memory, storage, or networking. Logical CPUs can provide additional throughput, but they do not provide the same capacity as an equal number of physical cores. Base capacity planning on physical cores and treat SMT capacity as additional headroom.

For multi-socket systems, install CPUs and memory symmetrically. Leave AMPS NUMA tuning enabled when the server is dedicated to one AMPS instance and performance testing confirms the expected topology and performance.

Memory Selection

First calculate the required memory capacity using the Capacity Planning guidance. Include SOW topics, views, indexes, journal files, queue state, client message buffers, the operating system, monitoring and security software, and expected growth.

When selecting the physical configuration:

• Populate all available memory channels (in a vendor-approved configuration) before increasing DIMM capacity within only a subset of channels.
• Install matching DIMMs symmetrically across sockets and memory channels.
• Compare memory speed and aggregate memory bandwidth, not only total capacity.
• As a practical minimum for a balanced physical server, provide at least 4GB of RAM per physical core. This is only a hardware configuration floor. Use the workload-derived estimate whenever it requires more memory.
• Preserve the production headroom recommended in the Capacity Planning section. AMPS should not depend on swapping to support its normal workload.

Memory bandwidth can become limiting before either CPU utilization or total memory capacity is exhausted. Avoid pairing a large number of CPU cores with a memory configuration that does not populate the processor's available memory channels.

note

With current server-memory pricing, reducing installed memory capacity can materially lower the cost of a physical server. When reducing capacity, continue to populate every memory channel supported by each installed CPU, following the server manufacturer's population guidelines. Prefer smaller DIMMs distributed across all channels over fewer large DIMMs that leave channels unused. A server may have sufficient memory capacity but substantially reduced memory bandwidth when channels are not fully populated.

Do not reduce installed memory below the workload-derived capacity and headroom requirements described in the Capacity Planning section.

Storage Selection

Storage should be sized for both capacity and performance. Capacity depends on SOW size, transaction log retention, queue state, logging, statistics, and the amount of data that must be retained while another replicated instance is unavailable.

Performance requirements depend on how AMPS uses each device:

• Transaction logs primarily require predictable sequential write performance and low write latency. Replay, replication, and queue delivery also require sequential read performance.
• SOW topics and persisted queue metadata perform random reads, writes, and updates.
• Error logs and the statistics database can create additional I/O that competes with message persistence (depending on configuration).

For high-performance deployments that persist messages, direct-attached enterprise NVMe storage is generally the best starting point. Where storage activity is substantial, place the transaction log and SOW data on separate devices or storage resources so that random SOW activity cannot interfere with transaction log writes. Place error logs and the statistics database away from latency-sensitive message storage when practical.

Do not select storage based only on an advertised maximum throughput or IOPS rating. Long or inconsistent write latencies can stall the persisted message path even when average throughput appears sufficient. Shared, network-attached, or remote storage should be tested under the competing load and failure conditions expected in production.

Run amps_bio_perf_test against the actual filesystem and device configuration planned for the transaction log on a server with no other usage during the test. Evaluate sustained throughput and the distribution of write latency, including high-percentile and maximum latency. Since this utility models transaction log access, also run a representative AMPS workload to validate SOW and mixed-I/O performance.

Choose device redundancy and RAID configuration according to the durability and recovery requirements of the deployment. Striping can increase throughput but does not replace AMPS replication, backups, or an appropriate recovery plan.

Validate the Complete Server

Before selecting a production configuration, test the complete workload on representative hardware. Include expected peak and burst rates, concurrent queries, subscriptions, SOW updates, transaction logging, replication, queue backlog recovery, and the monitoring and security software that will run in production.

The most useful comparison is not between processor or storage specifications. It is between complete server configurations running the expected AMPS workload with sufficient headroom to meet the deployment's service-level requirements.

Virtual Machines

When deploying in a virtual machine, it is important to consider the capacity of both the virtual machine itself and the underlying host hardware. In other words, the total memory needed by all virtual machines -- with all applications hosted by those machines running at peak traffic simultaneously -- should not exceed the physical memory of the hardware. Likewise, the total number of CPUs specified in all of the virtual machines on the host should not exceed the number of CPUs on the host hardware, the network bandwidth needed should not exceed the bandwidth allocated to the host, the traffic to the storage device should not exceed the throughput that the storage device is capable of, and so on. In an enterprise environment, it is not unusual for a wide variety of applications to all see peak loads at the same time, so the system should be provisioned to provide enough capacity that every hosted application can meet peak throughput requirements at the same time.

For x86-64 cloud deployments, the best starting point is a balanced general-purpose instance.

Cloud provider	Recommended starting point	Alternatives and notes
AWS EC2	M-family x86-64 instances, such as M8i or M8a where available.	Use M7i or M7a where M8 instances are not available.
Google Cloud	General-purpose C4 standard machines.	Use N4 standard or N2 standard based on regional availability and storage or network requirements.
Azure	D-family x86-64 instances, such as Dsv7 or Ddsv7 where available.	Use Dsv5 or Dv5 where Dsv7 or Ddsv7 instances are not available.

Choose the initial VM size from the CPU, memory, network, and storage requirements identified during capacity planning. Start with a balanced instance type, then use workload testing to decide whether the AMPS use case benefits from moving to a more specialized instance family.

tip

Use workload testing to choose the next direction: expand toward compute-optimized instances when CPU is the limiting resource, memory-optimized instances when memory capacity or memory bandwidth is limiting, network-optimized instances when message throughput or replication traffic is limited by networking, and storage-optimized instances when persistence, transaction log, or SOW activity is limited by storage throughput or latency.

On virtual machines, disable AMPS-level NUMA tuning in the AMPS configuration file.

<AMPSConfig>
   ...
   <Tuning>
     <NUMA>
       <Enabled>disabled</Enabled>
     </NUMA>
   </Tuning>
   ...
</AMPSConfig>

For applications requiring low latency and predictable response times, 60East does not recommend using virtualization systems that dynamically move running virtual machines for load-balancing purposes. Although these systems work well for their intended purpose, a machine migration will cause a period where AMPS isn't delivering messages or responding to queries, while also having a gap in observability (Galvanometer, Admin statistics, or logging).

Containers

When deploying in a container, ensure that the host system has the capacity to support all of the containers running on the host at peak capacity. This capacity includes CPU, memory, networking, storage capacity, and storage throughput.

60East tests and certifies AMPS within Podman containers. Containers can provide density and compute-efficiency advantages by allowing multiple AMPS instances or related services to share host resources, provided that the host is sized and managed for the combined peak load of all containers.

AMPS can perform NUMA tuning within a container when the physical host is a NUMA system and the container has access to the relevant host topology. This section provides guidance for AMPS-level NUMA tuning in containers. Leave AMPS-level NUMA tuning enabled in a container only when all of the following are true:

• The AMPS container is the only significant CPU-intensive workload on the host. This is typically a dedicated host, but a host that also runs lightweight supporting containers or processes can qualify when they do not materially compete for CPU or memory locality.
• The host NUMA topology is visible inside the container.
• The container runtime or orchestrator is not using CPU pinning, CPU quotas, memory limits, or memory placement policies that conflict with the topology AMPS detects.
• Performance testing of the complete container and host environment shows that AMPS NUMA tuning improves or preserves the required performance for the workload.

Disable AMPS-level NUMA tuning when any of these conditions is not true. This includes hosts that run multiple significant AMPS instances, containers, tenants, or CPU-intensive applications, and containers where the runtime restricts CPU or memory placement. In these deployments, the host and container runtime are responsible for allocating CPU and memory resources across workloads. Before leaving AMPS-level NUMA tuning enabled in a container, verify the topology visible from inside the container, review the runtime CPU and memory constraints, and compare workload performance with AMPS NUMA tuning enabled and disabled.

AMPS supports a wide variety of use cases with different CPU, networking, storage, and memory profiles. For high-performance computing (HPC) use cases, test the complete container and host environment for acceptable performance for each AMPS workload, rather than assuming that results from one workload or host configuration apply to another.

For best networking performance in a container, 60East recommends using host networking to remove network address translation (NAT) and virtual bridge interfaces from the message path.

warning

Host networking makes AMPS listeners use the host network namespace. Use host networking only with intended bind addresses configured for Transports and the Admin interface, host firewalls or cloud security groups limiting access to the required peers, and Securing AMPS controls such as TLS, authentication, and entitlement configured before the container is exposed.

Monitoring and Virtualization Considerations

For virtualized hosting or deployment in a container, develop a plan for monitoring the physical hardware as well as the environment that runs AMPS. If possible, the monitoring plan should include a method for correlating the activity in a virtualized or containerized environment with the activity on the physical host. For example, it is important to be able to correlate CPU saturation on a virtual machine to CPU saturation on the physical host.