Hello,
I am a Progress and VMware novice who is the IT caretaker for a small business using an Openedge application. We have no specific performance issues at present.
I am simply curious from an academic viewpoint about the '-spin' parameter and how the optimum setting is determined for virtualised guest OS with vCPU resources provisioned in different permutations:
I read that the recommended starting point for the -spin parameter for a multicore CPU is 8000 per CPU
(progress KB P23850), and various advice on this forum recommend a much higher level on 'modern' CPUs.
For "CPU" I read "socket" - I infer from the Progress recommendation that DB performance will scale with an increased number of sockets as we can increase the -spin parameter - at least if 'resource waits' were a factor constraining DB performance.
In ESXi 4.x + we can provision vCPUs with more than one core per vCPU:
Imagine we have host hardware consisting of 2x4core physical CPUs (2 sockets populated, 4 cores per socket) that hosts multiple guest VMs, and we have 4 physical core resources to assign to our Openedge DB guest OS,
1) I assume we would benefit therefore from provisioning the DB guest OS with 4x vCPU of one core each, instead of 1xvCPU of 4 cores? (our OS license allows for 4 physical processors), as it allows us to scale '-spin' accordingly?
2) If the trick above is valid, is the affect negated if the vCPUs are actually provisioned from the same physical CPU on the host (for example if the host vm was a single socket, multi-core physical CPU); despite dispatching requests to separate vCPUs, each request would still 'wait' for the resource as the physical CPU is busy?
3) perhaps this is all a moot point if there are no issues with 'resource waits' under the Promon utility, and one should only adjust -spin if necessary? (to put it into perspective we are getting ~600 resource waits per day with spin of 16,000 on 2x vCPU VM at 2.4GHz, which by my calculation is only an extra, ooh, 4ms delay? )
I welcome any comments.
Steve
For the curious:
Openedge 10.2B 32bit on Windows Server 2008R2 running virtualised under VMWare ESXi4, 2 vCPU assigned
DB size ~ 25GB. 100 concurrent users.
Openedge trained by Google.
I am a Progress and VMware novice who is the IT caretaker for a small business using an Openedge application. We have no specific performance issues at present.
I am simply curious from an academic viewpoint about the '-spin' parameter and how the optimum setting is determined for virtualised guest OS with vCPU resources provisioned in different permutations:
I read that the recommended starting point for the -spin parameter for a multicore CPU is 8000 per CPU
(progress KB P23850), and various advice on this forum recommend a much higher level on 'modern' CPUs.
For "CPU" I read "socket" - I infer from the Progress recommendation that DB performance will scale with an increased number of sockets as we can increase the -spin parameter - at least if 'resource waits' were a factor constraining DB performance.
In ESXi 4.x + we can provision vCPUs with more than one core per vCPU:
Imagine we have host hardware consisting of 2x4core physical CPUs (2 sockets populated, 4 cores per socket) that hosts multiple guest VMs, and we have 4 physical core resources to assign to our Openedge DB guest OS,
1) I assume we would benefit therefore from provisioning the DB guest OS with 4x vCPU of one core each, instead of 1xvCPU of 4 cores? (our OS license allows for 4 physical processors), as it allows us to scale '-spin' accordingly?
2) If the trick above is valid, is the affect negated if the vCPUs are actually provisioned from the same physical CPU on the host (for example if the host vm was a single socket, multi-core physical CPU); despite dispatching requests to separate vCPUs, each request would still 'wait' for the resource as the physical CPU is busy?
3) perhaps this is all a moot point if there are no issues with 'resource waits' under the Promon utility, and one should only adjust -spin if necessary? (to put it into perspective we are getting ~600 resource waits per day with spin of 16,000 on 2x vCPU VM at 2.4GHz, which by my calculation is only an extra, ooh, 4ms delay? )
I welcome any comments.
Steve
For the curious:
Openedge 10.2B 32bit on Windows Server 2008R2 running virtualised under VMWare ESXi4, 2 vCPU assigned
DB size ~ 25GB. 100 concurrent users.
Openedge trained by Google.