Score:3

Vmware Esxi - Old 32bit software performance issue on multi core

cn flag

I've been going crazy for 2 days now and I'm asking for help.

I have a program developed in delphi (early 2000s about) that accesses a firebird v3 database, currently installed on the same machine (windows server 2016 x64 - db and program are x86).

The machine is a VM configured on vmware esxi, I come to the point: if I configure the VM with only 1 vCPU the program runs very well, if I also configure it with 2 vCPUs (1 socket and 2 cores) or more, the performance is halved.

The problem is that by leaving only one vCPU, the cpu is perpetually at 100% even just for windows server jobs (eg search for updates and other stuff).

Do you have any advice?

PS: I can't switch to firebird x64 because many libraries are x86.

PPS: The OS on the VM is Windows Server 2016 Standard ed

joeqwerty avatar
cv flag
**Do you have any advice?** - If the program runs very well with 1 vCPU then leave it at that and ignore the CPU utilization. Otherwise, rebuild your app.
vidarlo avatar
ar flag
Find out where the bottleneck is that leads to half performance. There's no simple fix to this problem.
cn flag
Try setting the processor affinity to CPU 0 in task manager or by using start /affinity
shodanshok avatar
ca flag
Have you tried to configure your guest with 2 sockets each having a single core?
cn flag
When using 1 vCPU, without your app running, you get 100% CPU utilization just from windows background services? Maybe that is where something is wrong. Not sure what your physical CPUs are, but that doesn't seem okay to me.
cn flag
Ok, this is an old software but what is the OS running on? The one in the VM?
MenInTheMiddle avatar
cn flag
The OS is Windows Server 2016 Standard edition
Score:5
cn flag

Leave the guest at one CPU. And document the reason in some notes about this guest in inventory.

Focus more on meeting application performance metrics, and less on misleading basic metrics like CPU utilization. Are interactive applications responsive? Do batch queries complete in an acceptable amount of time? If so, don't worry about CPU.

Edit: "Lock up" levels of poor performance was not in your original question, that is important context. Fixing that problem might be worth some extra effort:

  • Schedule maintenance times where the database is shut down, to apply updates and other tasks.
  • Increase CPUs, and apply the application level CPUAffinity configuration that other comments mentioned, to lock it to one.
MenInTheMiddle avatar
cn flag
I left the guest at 1 vCPU, everything is ok until windows server decided to install updates (Process Windows Modules Installer speeds up to 100% cpu causing completely lock of firebird process)
Score:2
ru flag

If you fix the process affinity to a single core the other core will stay free for other processes. Depending on the actual scheduling problem, it might be necessary to fix the Firebird server to the same or the other core as well.

However, since ESXi virtualizes CPU cores as well it'll keep moving the vCPU cores across your physical cores. You might need to fix the VMs affinity to specific cores as well.

You should be aware that this kind of tuning is caused by badly coded or severely outdated software. You should seriously look into updating the code.

ar flag
jpa
The [Firebird FAQ](https://www.firebirdfaq.org/faq52/) also suggests setting CPU affinity, though through their own config file.
Zac67 avatar
ru flag
That figures - however, due to CPU virtualization the VM probably requires fixing to certain cores as well.
MenInTheMiddle avatar
cn flag
I tried to set cpu affinity mask to first cpu (and I tried to set affinity mask to core #0 in vm specs, too) without noteworthy results. The last version of firebird seems to have an issue on cpu affinity mask parameter in config file reported at [Let use 64-bit int for CPU affinity mask](https://github.com/FirebirdSQL/firebird/commit/188c1c6176c63cff6eedd85806bd266352df11f0), do you confirm that the bug can be the cause of the lack of results setting cpu affinity mask in firebird.conf ?
Zac67 avatar
ru flag
@MenInTheMiddle If there's a caching issue you need to fix the VM's affinity in ESXi/vSphere advanced settings as well.
Score:0
cn flag

This is a know problem of FireBird.

I did manage some customers which are on FireBird for various software, and multhreading stat are hard to configure with the .conf, but first you must install Firebird with the settings you need for multicpu's use, classic server.

enter image description here

Don't forget the client app need the multithreadin safe library too if you want to be sure.

Thread-safe Client Library

Thread-safe Client Library

Dmitry Yemanov
Vladyslav Khorsun
Alex Peshkov

Tracker reference CORE-707.

The client libraries, including the embedded one, can now be used in multi-threaded applications without any application-level

synchronization.

MenInTheMiddle avatar
cn flag
Thanks for your reply. Im using firebird 3 (superserver) , the version 3 seems optimized for multi core work (The primary goals for Firebird 3.0 were to unify the server architecture and to improve support for SMP and multiple-core hardware platforms - firebirdsql.org). I will try with classic server configuration anyway I will let you know
yagmoth555 avatar
cn flag
@MenInTheMiddle oh ok, I didnt seen version 3, then just make sure to use the affinity then if on superserver, by default classic you don't need it, but on superserver it work, but you need the settings set if I recall correctly
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.