Reading a DPACK
-
@hobbit666 said in Reading a DPACK:
We already have a IPOD set-up what I want to know is how do I determine that architecture and design I "should" be running if I don't know what my current set-up is preforming like?
That depends on your business needs, not your capacity. The DPACK is not part of that process.
-
@hobbit666 said in Reading a DPACK:
We run Dynamics GP and SQL server. If I don't know the current load how to I know what solution to look at?
That's the DPACK that will help you with the capacity planning. But again, capacity doesn't tell you anything about your architectural needs.
-
Think of the design of your system as getting an architect to design your house. The DPACK only does capacity, so all you know is how many bedrooms you have used in the past. The architect will certainly want to know how many bedrooms should be included in his design, but the style of the house, the materials used, the weather conditions it must withstand... none of those are influenced by the number of bedrooms. The capacity only tells you how big to make it, not what to make.
-
@hobbit666 said in Reading a DPACK:
@scottalanmiller said in Reading a DPACK:
DPACK tells you nothing about what you can run, only how much of it to run. No details in the DPACK will ever give you any insight at all into if an IPOD is acceptable to use or not.
We already have a IPOD set-up what I want to know is how do I determine that architecture and design I "should" be running if I don't know what my current set-up is preforming like?
We run Dynamics GP and SQL server. If I don't know the current load how to I know what solution to look at?
Architecture has nothing (or at least little) to do with performance.
From my offline conversations yesterday, you need to determine what your requirements are - i.e. do you need HA? do you need FT?
For example, if you don't need HA or FT then you start with an architecture of a single server. Then knowing the info from DPACK, you can determine if you can reasonable get that into a single server.
-
@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.
