Skip to content

Commit fd01970

Browse files
American-DipperAmerican-Dipper
authored
Merge pull request #251127 from iamwilliew/patch-25
Update sizes-b-series-burstable.md
2 parents 542e07d + afc2472 commit fd01970

File tree

2 files changed

+14
-107
lines changed

2 files changed

+14
-107
lines changed

‎articles/mysql/flexible-server/concepts-service-tiers-storage.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -101,7 +101,7 @@ To get more details about the compute series available, refer to Azure VM docume
101101

102102

103103
>[!NOTE]
104-
>For [Burstable (B-series) compute tier](../../virtual-machines/sizes-b-series-burstable.md) if the VM is started/stopped or restarted, the credits may be lost. For more information, see [Burstable (B-Series) FAQ](../../virtual-machines/sizes-b-series-burstable.md#q-why-is-my-remaining-credit-set-to-0-after-a-redeploy-or-a-stopstart).
104+
>For [Burstable (B-series) compute tier](../../virtual-machines/sizes-b-series-burstable.md) if the VM is started/stopped or restarted, the credits may be lost. For more information, see [Burstable (B-Series) FAQ](../../virtual-machines/sizes-b-series-burstable.md).
105105
106106
## Storage
107107

‎articles/virtual-machines/sizes-b-series-burstable.md

Lines changed: 13 additions & 106 deletions
Original file line numberDiff line numberDiff line change
@@ -33,117 +33,24 @@ The B-series comes in the following VM sizes:
3333
<br>
3434
<br>
3535

36-
| Size | vCPU | Memory: GiB | Temp storage (SSD) GiB | Base CPU Perf of VM | Max CPU Perf of VM | Initial Credits | Credits banked/hour | Max Banked Credits | Max data disks | Max uncached disk throughput: IOPS/MBps | Max burst uncached disk throughput: IOPS/MBps<sup>1</sup> |Max NICs |
37-
|---|---|---|---|---|---|---|---|---|---|---|---|---|
38-
| Standard_B1ls<sup>2</sup> | 1 | 0.5 | 4 | 5% | 100% | 30 | 3 | 72 | 2 | 160/10 | 4000/100 | 2 |
39-
| Standard_B1s | 1 | 1 | 4 | 10% | 100% | 30 | 6 | 144 | 2 | 320/10 | 4000/100 | 2 |
40-
| Standard_B1ms | 1 | 2 | 4 | 20% | 100% | 30 | 12 | 288 | 2 | 640/10 | 4000/100 | 2 |
41-
| Standard_B2s | 2 | 4 | 8 | 40% | 200% | 60 | 24 | 576 | 4 | 1280/15 | 4000/100 | 3 |
42-
| Standard_B2ms | 2 | 8 | 16 | 60% | 200% | 60 | 36 | 864 | 4 | 1920/22.5 | 4000/100 | 3 |
43-
| Standard_B4ms | 4 | 16 | 32 | 90% | 400% | 120 | 54 | 1296 | 8 | 2880/35 | 8000/200 | 4 |
44-
| Standard_B8ms | 8 | 32 | 64 | 135% | 800% | 240 | 81 | 1944 | 16 | 4320/50 | 8000/200 | 4 |
45-
| Standard_B12ms | 12 | 48 | 96 | 202% | 1200% | 360 | 121 | 2909 | 16 | 4320/50 | 16000/400 | 6 |
46-
| Standard_B16ms | 16 | 64 | 128 | 270% | 1600% | 480 | 162 | 3888 | 32 | 4320/50 | 16000/400 | 8 |
47-
| Standard_B20ms | 20 | 80 | 160 | 337% | 2000% | 600 | 203 | 4860 | 32 | 4320/50 | 16000/400 | 8 |
36+
| Size | vCPU | Memory: GiB | Temp storage (SSD) GiB | Base CPU Performance of VM (%) | Initial Credits | Credits banked/hour | Max Banked Credits | Max data disks | Max uncached disk throughput: IOPS/MBps | Max burst uncached disk throughput: IOPS/MBps1 | Max NICs |
37+
|----------------|------|-------------|------------------------|--------------------------------|-----------------|---------------------|--------------------|----------------|-----------------------------------------|------------------------------------------------|----------|
38+
| Standard_B1ls2 | 1 | 0.5 | 4 | 10 | 30 | 3 | 72 | 2 | 160/10 | 4000/100 | 2 |
39+
| Standard_B1s | 1 | 1 | 4 | 20 | 30 | 6 | 144 | 2 | 320/10 | 4000/100 | 2 |
40+
| Standard_B1ms | 1 | 2 | 4 | 40 | 30 | 12 | 288 | 2 | 640/10 | 4000/100 | 2 |
41+
| Standard_B2s | 2 | 4 | 8 | 40 | 60 | 24 | 576 | 4 | 1280/15 | 4000/100 | 3 |
42+
| Standard_B2ms | 2 | 8 | 16 | 60 | 60 | 36 | 864 | 4 | 1920/22.5 | 4000/100 | 3 |
43+
| Standard_B4ms | 4 | 16 | 32 | 45 | 120 | 54 | 1296 | 8 | 2880/35 | 8000/200 | 4 |
44+
| Standard_B8ms | 8 | 32 | 64 | 33 | 240 | 81 | 1944 | 16 | 4320/50 | 8000/200 | 4 |
45+
| Standard_B12ms | 12 | 48 | 96 | 36 | 360 | 121 | 2909 | 16 | 4320/50 | 16000/400 | 6 |
46+
| Standard_B16ms | 16 | 64 | 128 | 40 | 480 | 162 | 3888 | 32 | 4320/50 | 16000/400 | 8 |
47+
| Standard_B20ms | 20 | 80 | 160 | 40 | 600 | 203 | 4860 | 32 | 4320/50 | 16000/400 | 8 |
4848

4949
<sup>1</sup> B-series VMs can [burst](./disk-bursting.md) their disk performance and get up to their bursting max for up to 30 minutes at a time.
5050

5151
<sup>2</sup> B1ls is supported only on Linux
5252

5353

54-
## Workload example
55-
56-
Consider an office check-in/out application. The application needs CPU bursts during business hours, but not a lot of computing power during off hours. In this example, the workload requires a 16vCPU virtual machine with 64GiB of RAM to work efficiently.
57-
58-
The table shows the hourly traffic data and the chart is a visual representation of that traffic.
59-
60-
B16 characteristics:
61-
62-
Max CPU perf: 16vCPU * 100% = 1600%
63-
64-
Baseline: 270%
65-
66-
![Chart of hourly traffic data](./media/b-series-burstable/office-workload.png)
67-
68-
| Scenario | Time | CPU usage (%) | Credits accumulated<sup>1</sup> | Credits available |
69-
| --- | --- | --- | --- | --- |
70-
| B16ms Deployment | Deployment | Deployment | 480 (Initial Credits) | 480 |
71-
| No traffic | 0:00 | 0 | 162 | 642 |
72-
| No traffic | 1:00 | 0 | 162 | 804 |
73-
| No traffic | 2:00 | 0 | 162 | 966 |
74-
| No traffic | 3:00 | 0 | 162 | 1128 |
75-
| No traffic | 4:00 | 0 | 162 | 1290 |
76-
| No traffic | 5:00 | 0 | 162 | 1452 |
77-
| Low Traffic | 6:00 | 270 | 0 | 1452 |
78-
| Employees come to office (app needs 80% vCPU) | 7:00 | 1280 | -606 | 846 |
79-
| Employees continue coming to office (app needs 80% vCPU) | 8:00 | 1280 | -606 | 240 |
80-
| Low Traffic | 9:00 | 270 | 0 | 240 |
81-
| Low Traffic | 10:00 | 100 | 102 | 342 |
82-
| Low Traffic | 11:00 | 50 | 132 | 474 |
83-
| Low Traffic | 12:00 | 100 | 102 | 576 |
84-
| Low Traffic | 13:00 | 100 | 102 | 678 |
85-
| Low Traffic | 14:00 | 50 | 132 | 810 |
86-
| Low Traffic | 15:00 | 100 | 102 | 912 |
87-
| Low Traffic | 16:00 | 100 | 102 | 1014 |
88-
| Employees checking out (app needs 100% vCPU) | 17:00 | 1600 | -798 | 216 |
89-
| Low Traffic | 18:00 | 270 | 0 | 216 |
90-
| Low Traffic | 19:00 | 270 | 0 | 216 |
91-
| Low Traffic | 20:00 | 50 | 132 | 348 |
92-
| Low Traffic | 21:00 | 50 | 132 | 480 |
93-
| No traffic | 22:00 | 0 | 162 | 642 |
94-
| No traffic | 23:00 | 0 | 162 | 804 |
95-
96-
<sup>1</sup> Credits accumulated/credits used in an hour is equivalent to: `((Base CPU perf of VM - CPU Usage) / 100) * 60 minutes`.
97-
98-
For a D16s_v3 which has 16 vCPUs and 64 GiB of memory the hourly rate is $0.936 per hour (monthly $673.92) and for B16ms with 16 vCPUs and 64 GiB memory the rate is $0.794 per hour (monthly $547.86). <b> This results in 15% savings!</b>
99-
100-
## Q & A
101-
102-
### Q: What happens when my credits run out?
103-
**A**: When the credits are exhausted, the VM returns to the baseline performance.
104-
105-
### Q: How do you get 135% baseline performance from a VM?
106-
107-
**A**: The 135% is shared amongst the 8 vCPU’s that make up the VM size. For example, if your application uses 4 of the 8 cores working on batch processing and each of those 4 vCPU’s are running at 30% utilization the total amount of VM CPU performance would equal 120%. Meaning that your VM would be building credit time based on the 15% delta from your baseline performance. But it also means that when you have credits available that same VM can use 100% of all 8 vCPU’s giving that VM a Max CPU performance of 800%.
108-
109-
### Q: How can I monitor my credit balance and consumption?
110-
111-
**A**: The **Credit** metric allows you to view how many credits your VM have been banked and the **ConsumedCredit** metric will show how many CPU credits your VM has consumed from the bank. You will be able to view these metrics from the metrics pane in the portal or programmatically through the Azure Monitor APIs.
112-
113-
For more information on how to access the metrics data for Azure, see [Overview of metrics in Microsoft Azure](../azure-monitor/data-platform.md).
114-
115-
### Q: How are credits accumulated and consumed?
116-
117-
**A**: The VM accumulation and consumption rates are set such that a VM running at exactly its base performance level will have neither a net accumulation or consumption of bursting credits. A VM will have a net increase in credits whenever it is running below its base performance level and will have a net decrease in credits whenever the VM is utilizing the CPU more than its base performance level.
118-
119-
**Example**: I deploy a VM using the B1ms size for my small time and attendance database application. This size allows my application to use up to 20% of a vCPU as my baseline, which is 0.2 credits per minute I can use or bank.
120-
121-
My application is busy at the beginning and end of my employees work day, between 7:00-9:00 AM and 4:00 - 6:00PM. During the other 20 hours of the day, my application is typically at idle, only using 10% of the vCPU. For the non-peak hours, I earn 0.2 credits per minute but only consume 0.1 credits per minute, so my VM will bank 0.1 x 60 = 6 credits per hour. For the 20 hours that I am off-peak, I will bank 120 credits.
122-
123-
During peak hours my application averages 60% vCPU utilization, I still earn 0.2 credits per minute but I consume 0.6 credits per minute, for a net cost of 0.4 credits a minute or 0.4 x 60 = 24 credits per hour. I have 4 hours per day of peak usage, so it costs 4 x 24 = 96 credits for my peak usage.
124-
125-
If I take the 120 credits I earned off-peak and subtract the 96 credits I used for my peak times, I bank an additional 24 credits per day that I can use for other bursts of activity.
126-
127-
### Q: How can I calculate credits accumulated and used?
128-
129-
**A**: You can use the following formula:
130-
131-
(Base CPU perf of VM - CPU Usage) / 100 = Credits bank or use per minute
132-
133-
e.g in above instance your baseline is 20% and if you use 10% of the CPU you are accumulating (20%-10%)/100 = 0.1 credit per minute.
134-
135-
### Q: Does the B-Series support Premium Storage data disks?
136-
137-
**A**: Yes, all B-Series sizes support Premium Storage data disks.
138-
139-
### Q: Why is my remaining credit set to 0 after a redeploy or a stop/start?
140-
141-
**A** : When a VM is redeployed and the VM moves to another node, the accumulated credit is lost. If the VM is stopped/started, but remains on the same node, the VM retains the accumulated credit. Whenever the VM starts fresh on a node, it gets an initial credit, for Standard_B8ms it is 240.
142-
143-
### Q: What happens if I deploy an unsupported OS image on B1ls?
144-
145-
**A** : B1ls only supports Linux images and if you deploy any another OS image you might not get the best customer experience.
146-
14754
## Other sizes and information
14855

14956
- [General purpose](sizes-general.md)
@@ -155,7 +62,7 @@ e.g in above instance your baseline is 20% and if you use 10% of the CPU you are
15562

15663
Pricing Calculator: [Pricing Calculator](https://azure.microsoft.com/pricing/calculator/)
15764

158-
More information on Disks Types : [Disk Types](./disks-types.md#ultra-disks)
65+
More information on Disks Types: [Disk Types](./disks-types.md#ultra-disks)
15966

16067
## Next steps
16168

0 commit comments

Comments
 (0)