Using cost reports

The cost reports on the platform help you understand and optimize your compute costs. This page assumes you are familiar with the Overview of cost optimization; read it first if you have not. To view the cost reports, select Costs in the left-hand navigation. The reports are organized into three views: Historical spend, Nodes, and Flows. Click a view to open it.

​

Historical spend

The Historical spend view shows an estimate of compute costs incurred by the platform over the past 30 days: Use this view to get a quick overview of whether costs are within the expected range and to decide if further optimization is needed. If costs are within an acceptable range, you do not need to do anything else. The view updates daily. Use the date picker to choose the end date of the 30-day window. Note the following about the cost estimate:

• The dollar amounts are based on the cloud’s on-demand list pricing, not your negotiated pricing. The amounts do not include discounts such as reserved instances or savings plans, so your actual compute costs are likely lower.
• The amounts indicate the variable cost component driven by compute on the platform. They do not include the platform’s total cost, which also includes data storage and database costs. Data costs are typically small compared to compute costs and grow slowly relative to the number of workloads.
• All amounts are quoted in US dollars, even if your account is set to use another currency.

​

Instance usage

To understand the daily costs shown in the historical view in detail, open the Nodes view and use the date picker to choose a day, such as a day with a cost spike in the historical view. The table on the left lists the instances that ran that day, with each instance’s duration, cost, and type. The estimated daily cost at the top matches the amount shown in the historical view for that day. On the right, a timeline chart shows the number of nodes in the cluster over the day, with each instance’s span showing its utilization over time. In the screenshot above, three m8a.2xlarge instances ran for most of the day and account for most of the daily cost, while shorter-lived instances came and went as demand changed.

​

Why an instance was provisioned

A natural follow-up question is why the instance was provisioned. Click an instance’s span or its entry in the list to open a detailed view showing the steps and workstations assigned to the instance. In this case, the instance is a g5.4xlarge GPU instance that ran for about half an hour, provisioned for the embedding and robustness steps of ComplaintTriageCalibrationFlow.

​

Resource utilization

To check whether tasks are using their requested resources efficiently, open the Flows view. This view shows resource utilization for each step in your flows. The list on the left, Most resource consuming steps across flows, shows the steps with the highest total runtime over the reporting window, which are typically the highest cost drivers and natural targets for optimization. Use the Filter steps by flow field to narrow the list to a specific flow. Select a step to see its resource utilization charts. On the right, charts show the selected step’s resource utilization. Note the following about the charts:

• One chart shows CPU utilization and the other shows memory utilization.
• The X axis shows seconds since the task started. A task often exhibits distinct behavior during its lifetime, such as higher memory consumption after data has been loaded.
• The charts aggregate resource consumption for the selected step over the past 30 days, so you see multiple time series overlaid. This shows the overall behavior while also revealing outliers.
• A gray horizontal bar shows the amount of CPU or memory requested through the @resources decorator. A second bar shows the maximum resources used when it differs from the amount requested.

In the screenshot above, the step requested four CPUs, but its tasks used up to 16.3 CPUs at peak. Tasks that use more than they request contend for CPU time and run slower, so increasing the CPU request would let them run at full speed. The step’s memory usage peaks at about 10GB against the requested 16GB, leaving room to reduce the memory request as well.

​

Observing resource utilization in real time

The cost reporting views aggregate information over longer periods and update daily. Anaconda recommends against optimizing resource requirements based on a single data point, especially for tasks that consume changing data. During development, however, it is useful to check whether resource requirements are in the right ballpark. You can see resource usage in real time while a run executes: select the run in the Runs view, select a task, and scroll to the Compute section, which shows CPU, memory, and network utilization charts: In the screenshot above, the task requested four CPUs (the red line) and regularly burst above six CPUs (the blue line) during execution. Brief excursions above the request are normal for bursty workloads, so there is no need to chase every spike with a larger request. Memory consumption, by contrast, stays flat around 7.5GB against a requested 16GB. This task is a candidate for a lower memory request, but check the aggregated cost report before right-sizing: a single task might not show the peak usage of every run.

​

Identifying resource underutilization

This example highlights a case of resource underutilization: The step requests two CPUs, but its tasks never use more than about 0.3 CPUs. Similarly, it requests 8GB of memory but peaks below 400MB. You could right-size this step to @resources(cpu=1, memory=2000) without an adverse effect. This frees resources on the instance, allowing other tasks to be scheduled simultaneously, which increases utilization and lowers total compute costs.