Account defaults, overrides and runtime reconciliation
Know the limit.
Know where it came from.
Resolve account overrides against package and server defaults, apply the resulting policy, then inspect synchronization and runtime evidence. Capacity is easier to manage when the value and its source remain visible.
Compare configured policy, synchronization outcome and observed usage. Each answers a different operating question.
Swipe to inspect · tap the image for full context
- Account override
- Package value
- Server fallback
- Effective policy
One effective value per field
Account override → package → server default.
The resolver evaluates each resource independently. It reports the configured override, package default, server fallback, effective value and source. One custom value does not require replacing the whole package.
Account override
An explicit account value takes precedence. Use it for a deliberate exception, not to duplicate every package field unnecessarily. Resetting the field removes that exception.
Package value
Without an account override, a configured package resource becomes effective. Future package changes can therefore affect inherited fields while explicit overrides remain separate.
Server default
If neither layer supplies a value, the resolver uses its host-derived/default policy. A blank field means inheritance—not unlimited CPU, memory or I/O.
Controls that solve different problems
Read the unit before changing the number.
- CPU ceiling and weight
- CPU quota is a ceiling expressed in systemd percentages: 100% represents one core’s worth of CPU time. CPU weight is relative priority under contention, not a dedicated-core reservation.
- Account memory and tasks
- Memory is an account-boundary ceiling. Process/task limits bound concurrent tasks, not the number of websites or login sessions. The current helper writes these controls into the account user slice.
- PHP-FPM capacity
- Worker count limits concurrent PHP execution capacity. PHP memory_limit is a per-request PHP allocation limit, not reserved RAM for each worker. Request timeout bounds the configured request duration; it does not optimize slow application code.
- Storage and I/O
- Disk quota concerns stored capacity; bandwidth and IOPS controls concern traffic to the underlying block device. I/O weight is priority, not throughput. The helper emits device limits only when it resolves a supported block-device path.
- MySQL connections
- The policy is applied through the tenant’s database-user limits. It is not a global MySQL capacity setting, and does not establish one aggregate ceiling across every database user combined.
- Object Cache memory
- Redis memory is reconciled through the Object Cache manager. The resolver rejects cache memory greater than the account memory limit. Cache availability and the memory allocation are separate facts.
Validation before application
Separate invalid combinations from capacity warnings.
Rejected combinations
The resolver requires the process limit to be at least the PHP-FPM worker count and Object Cache memory not to exceed account memory. Fields also have server-side ranges: CPU and memory maxima depend on the host, while request timeout accepts 30–900 seconds.
Do not bypass a validation failure by assuming a larger number is always better. A value must fit the workload and the host’s available capacity.
Risk estimates
Workers multiplied by the PHP memory limit can exceed the account ceiling. The resolver reports that potential overcommit as a warning. This calculation is a risk estimate, not measured resident memory.
The accepted worker range accommodates retained large legacy overrides. An accepted value is not a sizing recommendation; review actual demand and memory pressure before increasing concurrency.
From desired policy to applied state
Saving and enforcing are separate steps.
- Resolve
- The engine computes effective values from account, package and server policy, preserving the source of each value.
- Apply host controls
- The resource helper generates account-slice and PHP-FPM configuration, validates the configuration and applies the tenant service path. Synchronization can restart affected tenant PHP services; this is not a zero-impact promise.
- Reconcile dependencies
- After the primary helper succeeds, Object Cache and tenant MySQL connection policy are reconciled. Their failures remain relevant even when earlier host controls were applied.
- Record the outcome
- The account stores synchronization time, an ok or warning status and messages. The resource overview also offers individual and bulk synchronization. Read the result per account rather than relying on a generic completion banner.
A shared account slice is the intended aggregate boundary for its attached workloads. Verifying that every relevant PHP, terminal, SSH and cron process actually joins that boundary on a particular host remains a runtime check.
Configured, applied, observed
Three kinds of evidence—not three names for the same number.
Configured policy
The resolver explains what should apply and why. This is the right view for understanding an override or package change, but it cannot alone establish that the operating system accepted it.
Synchronization outcome
The helper and service results explain application attempts. A missing helper or dependency failure produces a warning path. Inspect the message and timestamp before retrying.
Runtime usage
Server Health and account telemetry show observed consumption and available limits. Check freshness and capability availability. Missing data is not proof of zero consumption or successful isolation.
For a useful handover, record the intended field, its previous and new source, the synchronization outcome and current runtime evidence. This makes a future investigation more reliable than a screenshot of one green badge.
Change and recovery boundaries
Reset deliberately. Verify after a failure.
Technical details
Modify Account and the account-policy API support updating overrides, resetting one field and resetting all resource overrides. Resetting changes the source of the value and can reduce capacity. The per-account API checks root/owner access and CSRF for writes; that does not imply every legacy bulk-management route has identical scope.
Failed synchronization can leave a multi-service operation partially applied. The engine attempts to restore previous values in several update paths, but a restoration attempt is not a guarantee of atomic rollback across Linux, PHP, Redis and MySQL. Inspect effective policy and runtime state before repeating broad synchronization.
Does a blank limit mean unlimited resources?
Not for these resolver fields. It allows the package or server default to supply the effective value.
Is CPU weight the same as CPU quota?
No. Quota is a ceiling; weight is relative priority under contention. Neither should be described as a dedicated physical core.
Does a saved I/O value prove disk throttling is active?
No. The helper needs a supported resolved block-device path, and runtime enforcement still needs verification.
Does the worker-memory warning show actual RAM usage?
No. It estimates a potential ceiling from workers and per-request PHP memory. Use fresh runtime telemetry for measured consumption.