-
Notifications
You must be signed in to change notification settings - Fork 835
haproxy2.4 up to 3.1.6 cpu up 10% #2968
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Honestly, only 10% increase when switching from independent processes that share nothing to threads doesn't seem much at all. In exchange for this you gain a lot more nice stuff, like sharing the outgoing idle connections between all threads, a per-server maxconn that really works (no longer one per process), same for leastconn, stick-tables which are always known by all threads, consistent health checks, common stats, reduced memory usage when updating certs/maps/acls, and many others things that don't immediately come to my mind. Synchronizing states between threads necessarily causes a bit 8000 of overhead, which depends on the subsystems. If you're interested, you can run "perf top" and see the outliers. Maybe some of them are already known, maybe some have already been addressed or maybe what you're seeing is already the best we can do. Also what CPU are you running on ? Could you please issue |
Okay, that means upgrading to a new version is expected to result in CPU improvements, right |
What this means is that there is always a tradeoff between CPU efficiency and scalability. The previous model (nbproc) had long reached its limits by no longer being observable, monitorable, reliable, manageable, and absolutely needed to be reintegrated in a consistent way. This does necessarily cost a bit of CPU, there's no way around this, but our efforts since 1.8 have been mainly focused on diminishing this CPU impact while keeping the features. For example in the nbproc model, if you needed to delete a server, you would have had to create 36 sockets, iterate on all of them to check if the server still had traffic, then iterate on all of them to turn the server down, then iterate again on all of them to delete the server, etc. You really had 36 totally independent processes. For sure this has zero CPU cost but this is impractical for any serious use. And for example peers were not usable with nbproc. Now all of this is totally addressed at the expense of a little CPU cost (depending on which features, for the vast majority most there's zero cost). And a number of features benefit from the new model (e.g. connection reuse) and will even increase performance. Total RAM usage is way better as well (stick tables, ACLs, maps are no longer multiplied by the number of processes). 3.2 further reduces the cost (e.g. certain LB algos like leastconn still had an impact in threads). So in a sense, yes, new versions improve CPU usage. But there's inevitably a CPU cost from switching from the old nbproc to nbthread. If you're in a rare case where you're not monitoring your processes, you're not doing health checks, using stick-tables nor peers, doing nothing dynamic etc, you could still work in the old model by starting 36 times the program using the same |
Okay, I understand. Thank you very much for your answer and reply |
Detailed Description of the Problem
when i up haproxy 2.4 to haproxy 3.1.6, the cpu use is up 10%
Expected Behavior
I think new haproxy version performance is good than old ,but the cpu is using to up . I don't know if this is normal or not
Steps to Reproduce the Behavior
my haproxy2.4 is using nbproc 36, but harproxy3.1.6 is using nbthread 36
Do you have any idea what may have caused this?
I don't know
Do you have an idea how to solve the issue?
No response
What is your configuration?
Output of
haproxy -vv
Last Outputs and Backtraces
Additional Information
No response
The text was updated successfully, but these errors were encountered: