Reading a DPACK
-
@dashrender said in Reading a DPACK:
...you can determine if you can reasonable get that into a single server.
And how big that server is. The size of a single server ranges from a single low end quad core processor to something like eight, high end, twenty core processors. Small servers to big servers can be a workload difference of around one hundred fold, just within the AMD64 space and not getting into weird gear with more than eight sockets! Add in ARM and Power systems and those numbers more to thousands of fold differences.
-
How long should you run a DPACK for 48hrs a week?
-
@hobbit666 said in Reading a DPACK:
How long should you run a DPACK for 48hrs a week?
The longer you run it, the more chances you'll run into occasional processes that run in your environment that might put more strain on your system.
-
@dashrender that's what I'm thinking.
Might just set it off tomorrow then start a new thread about reviewing the data and designing a new setup.
-
@scottalanmiller said in Reading a DPACK:
There is no trivial way to measure CPU performance. The simple means used here is cores times speed. This is misleading as an Intel G6 core is not the same as an Intel G8 core is not the same as an AMD core. So this can be pretty misleading. But as long as you are getting faster core architectures in the future, you know that meeting or beating the coreXspeed calc of the past is more than enough.
So you have 22GHz of cumulative performance here. Likely this means that dual quad core procs in a new server will be plenty.
Scott - Looking at this DPACK, assuming the architecture is good, would there be any reason to upgrade this system, assuming nothing is being added (load wise)?
-
@dashrender said in Reading a DPACK:
@scottalanmiller said in Reading a DPACK:
There is no trivial way to measure CPU performance. The simple means used here is cores times speed. This is misleading as an Intel G6 core is not the same as an Intel G8 core is not the same as an AMD core. So this can be pretty misleading. But as long as you are getting faster core architectures in the future, you know that meeting or beating the coreXspeed calc of the past is more than enough.
So you have 22GHz of cumulative performance here. Likely this means that dual quad core procs in a new server will be plenty.
Scott - Looking at this DPACK, assuming the architecture is good, would there be any reason to upgrade this system, assuming nothing is being added (load wise)?
From a capacity perspective, not at all. You are way over provisioned.
-
@scottalanmiller said in Reading a DPACK:
@dashrender said in Reading a DPACK:
@scottalanmiller said in Reading a DPACK:
There is no trivial way to measure CPU performance. The simple means used here is cores times speed. This is misleading as an Intel G6 core is not the same as an Intel G8 core is not the same as an AMD core. So this can be pretty misleading. But as long as you are getting faster core architectures in the future, you know that meeting or beating the coreXspeed calc of the past is more than enough.
So you have 22GHz of cumulative performance here. Likely this means that dual quad core procs in a new server will be plenty.
Scott - Looking at this DPACK, assuming the architecture is good, would there be any reason to upgrade this system, assuming nothing is being added (load wise)?
From a capacity perspective, not at all. You are way over provisioned.
Agreed, unless you want more room to expand. Looking at the DPACK you only have 2.58% of storage left available. If the VMs have plenty of room you could take space back to put in to 'available'. But, if the VMs are full, and you cant take any back... 2.58% sounds low to me...
-
Memory and CPU are fine. Network throughput looks pretty much fine. Remaining space may/may not be depending on if you want to use more than 250 GB or so.
-
@jimmy9008 said in Reading a DPACK:
@scottalanmiller said in Reading a DPACK:
@dashrender said in Reading a DPACK:
@scottalanmiller said in Reading a DPACK:
There is no trivial way to measure CPU performance. The simple means used here is cores times speed. This is misleading as an Intel G6 core is not the same as an Intel G8 core is not the same as an AMD core. So this can be pretty misleading. But as long as you are getting faster core architectures in the future, you know that meeting or beating the coreXspeed calc of the past is more than enough.
So you have 22GHz of cumulative performance here. Likely this means that dual quad core procs in a new server will be plenty.
Scott - Looking at this DPACK, assuming the architecture is good, would there be any reason to upgrade this system, assuming nothing is being added (load wise)?
From a capacity perspective, not at all. You are way over provisioned.
Agreed, unless you want more room to expand. Looking at the DPACK you only have 2.58% of storage left available. If the VMs have plenty of room you could take space back to put in to 'available'. But, if the VMs are full, and you cant take any back... 2.58% sounds low to me...
Free Space for the sake of free space outside of the VMs seems wasteful, unless, as you mentioned, there is expected use of that space in the nearish future.
-
@scottalanmiller said in Reading a DPACK:
@dashrender said in Reading a DPACK:
@scottalanmiller said in Reading a DPACK:
There is no trivial way to measure CPU performance. The simple means used here is cores times speed. This is misleading as an Intel G6 core is not the same as an Intel G8 core is not the same as an AMD core. So this can be pretty misleading. But as long as you are getting faster core architectures in the future, you know that meeting or beating the coreXspeed calc of the past is more than enough.
So you have 22GHz of cumulative performance here. Likely this means that dual quad core procs in a new server will be plenty.
Scott - Looking at this DPACK, assuming the architecture is good, would there be any reason to upgrade this system, assuming nothing is being added (load wise)?
From a capacity perspective, not at all. You are way over provisioned.
I felt the same way, but considering it's the first DPACK I've ever read, I wanted to be sure.
-
@dashrender said in Reading a DPACK:
@jimmy9008 said in Reading a DPACK:
@scottalanmiller said in Reading a DPACK:
@dashrender said in Reading a DPACK:
@scottalanmiller said in Reading a DPACK:
There is no trivial way to measure CPU performance. The simple means used here is cores times speed. This is misleading as an Intel G6 core is not the same as an Intel G8 core is not the same as an AMD core. So this can be pretty misleading. But as long as you are getting faster core architectures in the future, you know that meeting or beating the coreXspeed calc of the past is more than enough.
So you have 22GHz of cumulative performance here. Likely this means that dual quad core procs in a new server will be plenty.
Scott - Looking at this DPACK, assuming the architecture is good, would there be any reason to upgrade this system, assuming nothing is being added (load wise)?
From a capacity perspective, not at all. You are way over provisioned.
Agreed, unless you want more room to expand. Looking at the DPACK you only have 2.58% of storage left available. If the VMs have plenty of room you could take space back to put in to 'available'. But, if the VMs are full, and you cant take any back... 2.58% sounds low to me...
Free Space for the sake of free space outside of the VMs seems wasteful, unless, as you mentioned, there is expected use of that space in the nearish future.
Indeed. Agreed. So the question would be, does that space meet the realistic needs of the business in the coming 6 - 12 months? If not, you need more kit. Hence, saying what I said
"
-
I think your backup and recovery strategy is part of the architecture @scottalanmiller described above as well. Maybe it's more like selecting the type of house insurance you need based on the way the house was architected, the area in which you live and the environmental risks, how much coverage you need, and how difficult you want the process to be to get the house rebuilt in a disaster. That was the best analogy I could come up with off the top of my head, so let me know if there's a better way to state it.
DPACK gives you insight as to whether your backups are negatively impacting the overall system performance and if you need more performance out of your production systems to account for it. So if your RPO has become a bit tighter, you will need to run backups more frequently to account for this. Can the system you have architected handle that load so your applications run well, and can you both backup and restore to hit your RTO with your current backup infrastructure's performance?
-
Great points @NetworkNerd
-
-
@jimmy9008 said in Reading a DPACK:
@dashrender said in Reading a DPACK:
Great points @NetworkNerd
So, what are you going to do?
This wasn't my DPACK - I posted it for learning purposes only. The DPACK came from someone on SW.
-
@dashrender said in Reading a DPACK:
@jimmy9008 said in Reading a DPACK:
@dashrender said in Reading a DPACK:
Great points @NetworkNerd
So, what are you going to do?
This wasn't my DPACK - I posted it for learning purposes only. The DPACK came from someone on SW.
Ahhh, I see. No worries.
