Understanding the Problem

PHP-FPM is responsible for handling PHP requests. In a Kubernetes environment, it typically runs inside a container within a pod. Throttling occurs when the PHP-FPM process tries to consume more CPU resources than the Kubernetes scheduler allows it to use.

When a container exceeds its allocated CPU limits, Kubernetes (specifically, the Linux kernel’s Completely Fair Scheduler (CFS) bandwidth control) throttles its CPU usage. This means the container is artificially slowed down, preventing it from monopolizing the node’s resources. While this protects other pods on the same node, it severely impacts the performance of your PHP application.

Why Does This Happen in EKS?

Several factors contribute to PHP-FPM throttling in EKS:

1. Inadequate CPU Limits: The most common cause is setting CPU limits too low for the demands of your application. If a burst of traffic hits your PHP-FPM container, it quickly hits the ceiling and gets throttled.
2. Incorrect PHP-FPM Configuration: Settings like pm.max_children, pm.start_servers, and pm.min_spare_servers directly impact how many PHP-FPM processes are running. If these aren’t tuned to your workload and available resources, you can easily exhaust CPU allocations.
3. Noisy Neighbors: If other resource-intensive pods are running on the same EKS node, they might be competing for CPU cycles. Even if your PHP-FPM pod hasn’t reached its absolute limit, the overall node contention can lead to performance degradation that mimics throttling.

How to Identify Throttling

Before fixing the problem, you need to confirm it’s actually happening. You can monitor CPU throttling using metrics like:

• container_cpu_cfs_throttled_seconds_total: This Prometheus metric tracks the total time a container has been throttled.
• container_cpu_cfs_throttled_periods_total: This metric shows the number of periods where throttling occurred.

If these metrics show significant spikes or a steady increase, your PHP-FPM containers are definitely being throttled.

The Solution: Banishing the Throttle

Resolving PHP-FPM throttling requires a multi-pronged approach:

1. Optimize Resource Requests and Limits

The first step is to accurately define the CPU resources your PHP-FPM containers need.

• Set Realistic Requests: The requests value ensures the pod is scheduled on a node with enough available CPU. Set this to the baseline CPU usage of your application during normal operation.
• Carefully Tune Limits: The limits value is the hard ceiling. If you set it too low, you’ll get throttled during spikes. If you set it too high (or remove it entirely), you risk a runaway process crashing the entire node. A common strategy is to set the CPU limit significantly higher than the request (e.g., Request: 200m, Limit: 1000m) to allow for bursts, but monitor closely.

Example Pod Spec snippet:

resources:
  requests:
    cpu: "250m"
    memory: "512Mi"
  limits:
    cpu: "1000m"
    memory: "1Gi"

2. Fine-Tune PHP-FPM Configuration

The PHP-FPM process manager needs to be configured to handle your traffic volume efficiently without spawning unnecessary processes that consume CPU.

• Process Manager (pm): Choose the right process manager. dynamic is usually the best choice for variable workloads, as it scales processes up and down based on demand. ondemand is good for very low-traffic sites, while static might be appropriate for highly predictable, high-traffic applications.
• pm.max_children: This is the most crucial setting. It defines the absolute maximum number of PHP-FPM processes that can exist simultaneously. Set this high enough to handle your peak concurrent requests, but low enough that the combined CPU usage of all these processes doesn’t exceed your container’s CPU limit. Calculate this carefully based on the average memory/CPU consumption of a single PHP request.
• pm.start_servers, pm.min_spare_servers, pm.max_spare_servers: If using the dynamic process manager, tune these to ensure you have enough idle processes ready to handle sudden spikes, but not so many that they waste resources when idle.

3. Horizontal Pod Autoscaling (HPA)

Instead of relying on a single large pod with high CPU limits, it’s often more effective to use Kubernetes Horizontal Pod Autoscaling (HPA).

HPA automatically increases the number of PHP-FPM pods when CPU utilization (or another metric) reaches a certain threshold. This distributes the load across multiple nodes, preventing any single pod from being throttled.

Example HPA configuration:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-fpm-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-fpm-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

4. Optimize Your Application Code

Often overlooked, the most effective way to reduce CPU usage is to optimize the PHP application itself.

• Database Queries: Inefficient database queries are a major CPU drain. Optimize queries, add indexes, and use caching mechanisms (like Redis or Memcached).
• Code Profiling: Use tools like Xdebug or Blackfire to identify CPU-intensive bottlenecks in your code.
• Opcache: Ensure PHP Opcache is enabled and properly configured. This drastically reduces the CPU overhead of compiling PHP scripts on every request.

Conclusion

PHP-FPM throttling in AWS EKS is a manageable challenge. By understanding the interaction between Kubernetes resource limits and PHP-FPM process management, and by implementing proper autoscaling and code optimization, you can ensure your PHP applications run smoothly and efficiently, no matter how much traffic they receive.

The post Combating PHP-FPM Throttling in AWS EKS appeared first on Sergey Lysenko.

If you want to view only your AWS costs in New Relic without leaking unnecessary infrastructure data, you need a strict, custom IAM approach using API Polling. Here is the step-by-step guide to setting it up securely.

Step 1: Get Your New Relic Identifiers

First, we need to generate unique connection IDs from New Relic.

1. Log into your New Relic account and navigate to Infrastructure -> AWS.
2. Click Add an AWS account and choose the API polling method.
3. Keep this tab open. You will see an Account ID and an External ID. You need both for the next step.

Step 2: Create a Strict AWS IAM Policy

We will create a policy that restricts New Relic to only reading Cost Explorer and AWS Budgets data.

1. Open your AWS Management Console and go to the IAM dashboard.
2. Navigate to Policies and click Create policy.
3. Switch to the JSON tab and paste the following exact configuration:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowNewRelicBillingOnly",
      "Effect": "Allow",
      "Action": [
        "budgets:ViewBudget",
        "ce:GetCostAndUsage",
        "ce:GetCostForecast",
        "ce:GetReservationUtilization",
        "ce:GetDimensionValues",
        "ce:GetTags"
      ],
      "Resource": "*"
    }
  ]
}

4. Click through to the end, name the policy NewRelicBillingOnlyPolicy, and save it.

Step 3: Create the IAM Role

Now, attach this policy to a dedicated role for New Relic.

1. In the AWS IAM console, go to Roles and click Create role.
2. Select AWS account as the trusted entity, then choose Another AWS account.
3. Paste the Account ID you got from New Relic in Step 1.
4. Check the Require external ID box and paste the External ID from New Relic.
5. Click Next, search for your newly created NewRelicBillingOnlyPolicy, and select it.
6. Name the role NewRelicBillingIntegrationRole and click Create role.
7. Open the role you just created and copy its ARN (Amazon Resource Name).

Step 4: Finalize the New Relic Setup

1. Go back to your open New Relic tab.
2. In the AWS account name field, enter a clear alias like AWS-Billing-Only so your team knows exactly what this integration does.
3. Paste your Role ARN.
4. On the next screen, uncheck every service except for Billing.
5. Save the integration.

Step 5: Verify Your Data

AWS Cost Explorer data is not real-time; it updates a few times a day. Wait about 15-30 minutes, then head to the New Relic Query Builder and run this NRQL query to see your total spend for the current month:

SELECT max(provider.estimatedCharges.Maximum) FROM FinanceSample SINCE 1 month ago TIMESERIES 1 day

If you see a rising chart, your cost data is successfully flowing into New Relic without exposing your sensitive infrastructure metrics!

The post How to Safely Send AWS Billing Data to New Relic (Cost Data Only) appeared first on Sergey Lysenko.