#Tuning Profiles

The enterprise runtime exposes three tuning profiles. A profile is a request, not a guarantee. Use doctor to verify what the host actually honored.

#Profiles

#Profile Behavior

The runtime distinguishes between four states for each tuning request:

This split matters for operations. A malformed request and an under-provisioned host are different problems and should not be debugged the same way.

#The doctor Verb

Always validate the requested posture on the target host with doctor before treating it as production-ready.

doctor checks:

• Memory-lock availability and limits
• CPU isolation and pinning capabilities
• RT scheduling permissions
• SHM placement and permissions
• Available CPU headroom

#Effective Tuning in Cloud

Cloud deployments surface the effective tuning record in the deployment details view:

• Requested settings from the config bundle
• Applied settings reported by the agent
• Degraded settings with reasons
• Failure reasons
• Host observations

This gives operators a single view of what was asked for and what actually happened on the target host.

#Operational Guidance

• Start with default during development and testing
• Use low-latency when the host has privilege but full isolation is not guaranteed
• Reserve isolated-core for production hosts that pass doctor validation
• Always run doctor on new hosts before assuming production readiness
• Monitor the degraded/failed split in Cloud deployment details to catch host configuration drift