upstream/haproxy
1
0
Fork 0
mirror of https://github.com/haproxy/haproxy.git synced 2026-04-29 10:11:49 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
haproxy/src/counters.c

152 lines
4.7 KiB
C
Raw Normal View History

MINOR: counters: add shared counters helpers to get and drop shared pointers create include/haproxy/counters.h and src/counters.c files to anticipate for further helpers as some counters specific tasks needs to be carried out and since counters are shared between multiple object types (ie: listener, proxy, server..) we need generic helpers. Add some shared counters helper which are not yet used but will be updated in upcoming commits.
2025-05-06 14:45:40 -04:00
/*
* objects counters management
*
* Copyright 2025 HAProxy Technologies
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
#include <stdlib.h>
MEDIUM: stats-file/counters: store and preload stats counters as shm file objects This is the last patch of the shm stats file series, in this patch we implement the logic to store and fetch shm stats objects and associate them to existing shared counters on the current process. Shm objects are stored in the same memory location as the shm stats file header. In fact they are stored right after it. All objects (struct shm_stats_file_object) have the same size (no matter their type), which allows for easy object traversal without having to check the object's type, and could permit the use of external tools to scan the SHM in the future. Each object stores a guid (of GUID_MAX_LEN+1 size) and tgid which allows to match corresponding shared counters indexes. Also, as stated before, each object stores the list of users making use of it. Objects are never released (the map can only grow), but unused objects (when no more users or active users are found in objects->users), the object is automatically recycled. Also, each object stores its type which defines how the object generic data member should be handled. Upon startup (or reload), haproxy first tries to scan existing shm to find objects that could be associated to frontends, backends, listeners or servers in the current config based on GUID. For associations that couldn't be made, haproxy will automatically create missing objects in the SHM during late startup. When haproxy matches with an existing object, it means the counter from an older process is preserved in the new process, so multiple processes temporarily share the same counter for as long as required for older processes to eventually exit.
2025-08-27 11:23:42 -04:00
#include <stdio.h>
MEDIUM: counters: manage shared counters using dedicated helpers proxies, listeners and server shared counters are now managed via helpers added in one of the previous commits. When guid is not set (ie: when not yet assigned), shared counters pointer is allocated using calloc() (local memory) and a flag is set on the shared counters struct to know how to manipulate (and free it). Else if guid is set, then it means that the counters may be shared so while for now we don't actually use a shared memory location the API is ready for that. The way it works, for proxies and servers (for which guid is not known during creation), we first call counters_{fe,be}_shared_get with guid not set, which results in local pointer being retrieved (as if we just manually called calloc() to retrieve a pointer). Later (during postparsing) if guid is set we try to upgrade the pointer from local to shared. Lastly, since the memory location for some objects (proxies and servers counters) may change from creation to postparsing, let's update counters->last_change member directly under counters_{fe,be}_shared_get() so we don't miss it. No change of behavior is expected, this is only preparation work.
2025-05-07 17:42:04 -04:00
#include <haproxy/atomic.h>
#include <haproxy/clock.h>
MINOR: counters: add shared counters helpers to get and drop shared pointers create include/haproxy/counters.h and src/counters.c files to anticipate for further helpers as some counters specific tasks needs to be carried out and since counters are shared between multiple object types (ie: listener, proxy, server..) we need generic helpers. Add some shared counters helper which are not yet used but will be updated in upcoming commits.
2025-05-06 14:45:40 -04:00
#include <haproxy/counters.h>
MAJOR: counters: dispatch counters over thread groups Most fe and be counters are good candidates for being shared between processes. They are now grouped inside "shared" struct sub member under be_counters and fe_counters. Now they are properly identified, they would greatly benefit from being shared over thread groups to reduce the cost of atomic operations when updating them. For this, we take the current tgid into account so each thread group only updates its own counters. For this to work, it is mandatory that the "shared" member from {fe,be}_counters is initialized AFTER global.nbtgroups is known, because each shared counter causes the stat to be allocated lobal.nbtgroups times. When updating a counter without concurrency, the first counter from the array may be updated. To consult the shared counters (which requires aggregation of per-tgid individual counters), some helper functions were added to counter.h to ease code maintenance and avoid computing errors.
2025-05-15 13:55:11 -04:00
#include <haproxy/global.h>
MEDIUM: stats-file/counters: store and preload stats counters as shm file objects This is the last patch of the shm stats file series, in this patch we implement the logic to store and fetch shm stats objects and associate them to existing shared counters on the current process. Shm objects are stored in the same memory location as the shm stats file header. In fact they are stored right after it. All objects (struct shm_stats_file_object) have the same size (no matter their type), which allows for easy object traversal without having to check the object's type, and could permit the use of external tools to scan the SHM in the future. Each object stores a guid (of GUID_MAX_LEN+1 size) and tgid which allows to match corresponding shared counters indexes. Also, as stated before, each object stores the list of users making use of it. Objects are never released (the map can only grow), but unused objects (when no more users or active users are found in objects->users), the object is automatically recycled. Also, each object stores its type which defines how the object generic data member should be handled. Upon startup (or reload), haproxy first tries to scan existing shm to find objects that could be associated to frontends, backends, listeners or servers in the current config based on GUID. For associations that couldn't be made, haproxy will automatically create missing objects in the SHM during late startup. When haproxy matches with an existing object, it means the counter from an older process is preserved in the new process, so multiple processes temporarily share the same counter for as long as required for older processes to eventually exit.
2025-08-27 11:23:42 -04:00
#include <haproxy/guid.h>
#include <haproxy/stats-file.h>
MEDIUM: counters: manage shared counters using dedicated helpers proxies, listeners and server shared counters are now managed via helpers added in one of the previous commits. When guid is not set (ie: when not yet assigned), shared counters pointer is allocated using calloc() (local memory) and a flag is set on the shared counters struct to know how to manipulate (and free it). Else if guid is set, then it means that the counters may be shared so while for now we don't actually use a shared memory location the API is ready for that. The way it works, for proxies and servers (for which guid is not known during creation), we first call counters_{fe,be}_shared_get with guid not set, which results in local pointer being retrieved (as if we just manually called calloc() to retrieve a pointer). Later (during postparsing) if guid is set we try to upgrade the pointer from local to shared. Lastly, since the memory location for some objects (proxies and servers counters) may change from creation to postparsing, let's update counters->last_change member directly under counters_{fe,be}_shared_get() so we don't miss it. No change of behavior is expected, this is only preparation work.
2025-05-07 17:42:04 -04:00
#include <haproxy/time.h>
MINOR: counters: retrieve detailed errmsg upon failure with counters_{fe,be}_shared_prepare() counters_{fe,be}_shared_prepare now take an extra <errmsg> parameter that contains additional hints about the error in case of failure. It must be freed accordingly since it is allocated using memprintf
2025-08-27 08:51:48 -04:00
#include <haproxy/tools.h>
MINOR: counters: add shared counters helpers to get and drop shared pointers create include/haproxy/counters.h and src/counters.c files to anticipate for further helpers as some counters specific tasks needs to be carried out and since counters are shared between multiple object types (ie: listener, proxy, server..) we need generic helpers. Add some shared counters helper which are not yet used but will be updated in upcoming commits.
2025-05-06 14:45:40 -04:00
MAJOR: counters: dispatch counters over thread groups Most fe and be counters are good candidates for being shared between processes. They are now grouped inside "shared" struct sub member under be_counters and fe_counters. Now they are properly identified, they would greatly benefit from being shared over thread groups to reduce the cost of atomic operations when updating them. For this, we take the current tgid into account so each thread group only updates its own counters. For this to work, it is mandatory that the "shared" member from {fe,be}_counters is initialized AFTER global.nbtgroups is known, because each shared counter causes the stat to be allocated lobal.nbtgroups times. When updating a counter without concurrency, the first counter from the array may be updated. To consult the shared counters (which requires aggregation of per-tgid individual counters), some helper functions were added to counter.h to ease code maintenance and avoid computing errors.
2025-05-15 13:55:11 -04:00
static void _counters_shared_drop(void *counters)
{
struct counters_shared *shared = counters;
int it = 0;
if (!shared)
return;
MEDIUM: counters: Dynamically allocate per-thread group counters Instead of statically allocating the per-thread group counters, based on the max number of thread groups available, allocate them dynamically, based on the number of thread groups actually used. That way we can increase the maximum number of thread groups without using an unreasonable amount of memory.
2026-01-11 22:25:34 -05:00
while (it < global.nbtgroups && shared->tg && shared->tg[it]) {
MEDIUM: stats-file/counters: store and preload stats counters as shm file objects This is the last patch of the shm stats file series, in this patch we implement the logic to store and fetch shm stats objects and associate them to existing shared counters on the current process. Shm objects are stored in the same memory location as the shm stats file header. In fact they are stored right after it. All objects (struct shm_stats_file_object) have the same size (no matter their type), which allows for easy object traversal without having to check the object's type, and could permit the use of external tools to scan the SHM in the future. Each object stores a guid (of GUID_MAX_LEN+1 size) and tgid which allows to match corresponding shared counters indexes. Also, as stated before, each object stores the list of users making use of it. Objects are never released (the map can only grow), but unused objects (when no more users or active users are found in objects->users), the object is automatically recycled. Also, each object stores its type which defines how the object generic data member should be handled. Upon startup (or reload), haproxy first tries to scan existing shm to find objects that could be associated to frontends, backends, listeners or servers in the current config based on GUID. For associations that couldn't be made, haproxy will automatically create missing objects in the SHM during late startup. When haproxy matches with an existing object, it means the counter from an older process is preserved in the new process, so multiple processes temporarily share the same counter for as long as required for older processes to eventually exit.
2025-08-27 11:23:42 -04:00
if (shared->flags & COUNTERS_SHARED_F_LOCAL) {
/* memory was allocated using calloc(), simply free it */
free(shared->tg[it]);
}
else {
struct shm_stats_file_object *obj;
/* inside shared memory, retrieve associated object and remove
* ourselves from its users
*/
obj = container_of(shared->tg[it], struct shm_stats_file_object, data);
HA_ATOMIC_OR(&obj->users, (1 << shm_stats_file_slot));
}
MAJOR: counters: dispatch counters over thread groups Most fe and be counters are good candidates for being shared between processes. They are now grouped inside "shared" struct sub member under be_counters and fe_counters. Now they are properly identified, they would greatly benefit from being shared over thread groups to reduce the cost of atomic operations when updating them. For this, we take the current tgid into account so each thread group only updates its own counters. For this to work, it is mandatory that the "shared" member from {fe,be}_counters is initialized AFTER global.nbtgroups is known, because each shared counter causes the stat to be allocated lobal.nbtgroups times. When updating a counter without concurrency, the first counter from the array may be updated. To consult the shared counters (which requires aggregation of per-tgid individual counters), some helper functions were added to counter.h to ease code maintenance and avoid computing errors.
2025-05-15 13:55:11 -04:00
it += 1;
}
MEDIUM: counters: Dynamically allocate per-thread group counters Instead of statically allocating the per-thread group counters, based on the max number of thread groups available, allocate them dynamically, based on the number of thread groups actually used. That way we can increase the maximum number of thread groups without using an unreasonable amount of memory.
2026-01-11 22:25:34 -05:00
free(shared->tg);
MAJOR: counters: dispatch counters over thread groups Most fe and be counters are good candidates for being shared between processes. They are now grouped inside "shared" struct sub member under be_counters and fe_counters. Now they are properly identified, they would greatly benefit from being shared over thread groups to reduce the cost of atomic operations when updating them. For this, we take the current tgid into account so each thread group only updates its own counters. For this to work, it is mandatory that the "shared" member from {fe,be}_counters is initialized AFTER global.nbtgroups is known, because each shared counter causes the stat to be allocated lobal.nbtgroups times. When updating a counter without concurrency, the first counter from the array may be updated. To consult the shared counters (which requires aggregation of per-tgid individual counters), some helper functions were added to counter.h to ease code maintenance and avoid computing errors.
2025-05-15 13:55:11 -04:00
}
/* release a shared fe counters struct */
void counters_fe_shared_drop(struct fe_counters_shared *counters)
{
_counters_shared_drop(counters);
}
/* release a shared be counters struct */
void counters_be_shared_drop(struct be_counters_shared *counters)
{
_counters_shared_drop(counters);
}
MEDIUM: stats-file/counters: store and preload stats counters as shm file objects This is the last patch of the shm stats file series, in this patch we implement the logic to store and fetch shm stats objects and associate them to existing shared counters on the current process. Shm objects are stored in the same memory location as the shm stats file header. In fact they are stored right after it. All objects (struct shm_stats_file_object) have the same size (no matter their type), which allows for easy object traversal without having to check the object's type, and could permit the use of external tools to scan the SHM in the future. Each object stores a guid (of GUID_MAX_LEN+1 size) and tgid which allows to match corresponding shared counters indexes. Also, as stated before, each object stores the list of users making use of it. Objects are never released (the map can only grow), but unused objects (when no more users or active users are found in objects->users), the object is automatically recycled. Also, each object stores its type which defines how the object generic data member should be handled. Upon startup (or reload), haproxy first tries to scan existing shm to find objects that could be associated to frontends, backends, listeners or servers in the current config based on GUID. For associations that couldn't be made, haproxy will automatically create missing objects in the SHM during late startup. When haproxy matches with an existing object, it means the counter from an older process is preserved in the new process, so multiple processes temporarily share the same counter for as long as required for older processes to eventually exit.
2025-08-27 11:23:42 -04:00
/* prepare shared counters pointers for a given <shared> parent
* pointer and for <guid> object
* <is_be> hint is expected to be set to 1 when the guid refers to be_shared
* struct, else fe_shared stuct is assumed.
*
MEDIUM: counters: manage shared counters using dedicated helpers proxies, listeners and server shared counters are now managed via helpers added in one of the previous commits. When guid is not set (ie: when not yet assigned), shared counters pointer is allocated using calloc() (local memory) and a flag is set on the shared counters struct to know how to manipulate (and free it). Else if guid is set, then it means that the counters may be shared so while for now we don't actually use a shared memory location the API is ready for that. The way it works, for proxies and servers (for which guid is not known during creation), we first call counters_{fe,be}_shared_get with guid not set, which results in local pointer being retrieved (as if we just manually called calloc() to retrieve a pointer). Later (during postparsing) if guid is set we try to upgrade the pointer from local to shared. Lastly, since the memory location for some objects (proxies and servers counters) may change from creation to postparsing, let's update counters->last_change member directly under counters_{fe,be}_shared_get() so we don't miss it. No change of behavior is expected, this is only preparation work.
2025-05-07 17:42:04 -04:00
* if <guid> is not set, then sharing is disabled
MINOR: counters: retrieve detailed errmsg upon failure with counters_{fe,be}_shared_prepare() counters_{fe,be}_shared_prepare now take an extra <errmsg> parameter that contains additional hints about the error in case of failure. It must be freed accordingly since it is allocated using memprintf
2025-08-27 08:51:48 -04:00
* Returns the pointer on success or NULL on failure, in which case
MEDIUM: stats-file/counters: store and preload stats counters as shm file objects This is the last patch of the shm stats file series, in this patch we implement the logic to store and fetch shm stats objects and associate them to existing shared counters on the current process. Shm objects are stored in the same memory location as the shm stats file header. In fact they are stored right after it. All objects (struct shm_stats_file_object) have the same size (no matter their type), which allows for easy object traversal without having to check the object's type, and could permit the use of external tools to scan the SHM in the future. Each object stores a guid (of GUID_MAX_LEN+1 size) and tgid which allows to match corresponding shared counters indexes. Also, as stated before, each object stores the list of users making use of it. Objects are never released (the map can only grow), but unused objects (when no more users or active users are found in objects->users), the object is automatically recycled. Also, each object stores its type which defines how the object generic data member should be handled. Upon startup (or reload), haproxy first tries to scan existing shm to find objects that could be associated to frontends, backends, listeners or servers in the current config based on GUID. For associations that couldn't be made, haproxy will automatically create missing objects in the SHM during late startup. When haproxy matches with an existing object, it means the counter from an older process is preserved in the new process, so multiple processes temporarily share the same counter for as long as required for older processes to eventually exit.
2025-08-27 11:23:42 -04:00
* <errmsg> may contain additional hints about the error and must be freed accordingly
MINOR: counters: add shared counters helpers to get and drop shared pointers create include/haproxy/counters.h and src/counters.c files to anticipate for further helpers as some counters specific tasks needs to be carried out and since counters are shared between multiple object types (ie: listener, proxy, server..) we need generic helpers. Add some shared counters helper which are not yet used but will be updated in upcoming commits.
2025-05-06 14:45:40 -04:00
*/
MINOR: counters: retrieve detailed errmsg upon failure with counters_{fe,be}_shared_prepare() counters_{fe,be}_shared_prepare now take an extra <errmsg> parameter that contains additional hints about the error in case of failure. It must be freed accordingly since it is allocated using memprintf
2025-08-27 08:51:48 -04:00
static int _counters_shared_prepare(struct counters_shared *shared,
MEDIUM: stats-file/counters: store and preload stats counters as shm file objects This is the last patch of the shm stats file series, in this patch we implement the logic to store and fetch shm stats objects and associate them to existing shared counters on the current process. Shm objects are stored in the same memory location as the shm stats file header. In fact they are stored right after it. All objects (struct shm_stats_file_object) have the same size (no matter their type), which allows for easy object traversal without having to check the object's type, and could permit the use of external tools to scan the SHM in the future. Each object stores a guid (of GUID_MAX_LEN+1 size) and tgid which allows to match corresponding shared counters indexes. Also, as stated before, each object stores the list of users making use of it. Objects are never released (the map can only grow), but unused objects (when no more users or active users are found in objects->users), the object is automatically recycled. Also, each object stores its type which defines how the object generic data member should be handled. Upon startup (or reload), haproxy first tries to scan existing shm to find objects that could be associated to frontends, backends, listeners or servers in the current config based on GUID. For associations that couldn't be made, haproxy will automatically create missing objects in the SHM during late startup. When haproxy matches with an existing object, it means the counter from an older process is preserved in the new process, so multiple processes temporarily share the same counter for as long as required for older processes to eventually exit.
2025-08-27 11:23:42 -04:00
const struct guid_node *guid, int is_be, char **errmsg)
MINOR: counters: add shared counters helpers to get and drop shared pointers create include/haproxy/counters.h and src/counters.c files to anticipate for further helpers as some counters specific tasks needs to be carried out and since counters are shared between multiple object types (ie: listener, proxy, server..) we need generic helpers. Add some shared counters helper which are not yet used but will be updated in upcoming commits.
2025-05-06 14:45:40 -04:00
{
MEDIUM: stats-file/counters: store and preload stats counters as shm file objects This is the last patch of the shm stats file series, in this patch we implement the logic to store and fetch shm stats objects and associate them to existing shared counters on the current process. Shm objects are stored in the same memory location as the shm stats file header. In fact they are stored right after it. All objects (struct shm_stats_file_object) have the same size (no matter their type), which allows for easy object traversal without having to check the object's type, and could permit the use of external tools to scan the SHM in the future. Each object stores a guid (of GUID_MAX_LEN+1 size) and tgid which allows to match corresponding shared counters indexes. Also, as stated before, each object stores the list of users making use of it. Objects are never released (the map can only grow), but unused objects (when no more users or active users are found in objects->users), the object is automatically recycled. Also, each object stores its type which defines how the object generic data member should be handled. Upon startup (or reload), haproxy first tries to scan existing shm to find objects that could be associated to frontends, backends, listeners or servers in the current config based on GUID. For associations that couldn't be made, haproxy will automatically create missing objects in the SHM during late startup. When haproxy matches with an existing object, it means the counter from an older process is preserved in the new process, so multiple processes temporarily share the same counter for as long as required for older processes to eventually exit.
2025-08-27 11:23:42 -04:00
struct fe_counters_shared *fe_shared;
struct be_counters_shared *be_shared;
MAJOR: counters: dispatch counters over thread groups Most fe and be counters are good candidates for being shared between processes. They are now grouped inside "shared" struct sub member under be_counters and fe_counters. Now they are properly identified, they would greatly benefit from being shared over thread groups to reduce the cost of atomic operations when updating them. For this, we take the current tgid into account so each thread group only updates its own counters. For this to work, it is mandatory that the "shared" member from {fe,be}_counters is initialized AFTER global.nbtgroups is known, because each shared counter causes the stat to be allocated lobal.nbtgroups times. When updating a counter without concurrency, the first counter from the array may be updated. To consult the shared counters (which requires aggregation of per-tgid individual counters), some helper functions were added to counter.h to ease code maintenance and avoid computing errors.
2025-05-15 13:55:11 -04:00
int it = 0;
MEDIUM: counters: manage shared counters using dedicated helpers proxies, listeners and server shared counters are now managed via helpers added in one of the previous commits. When guid is not set (ie: when not yet assigned), shared counters pointer is allocated using calloc() (local memory) and a flag is set on the shared counters struct to know how to manipulate (and free it). Else if guid is set, then it means that the counters may be shared so while for now we don't actually use a shared memory location the API is ready for that. The way it works, for proxies and servers (for which guid is not known during creation), we first call counters_{fe,be}_shared_get with guid not set, which results in local pointer being retrieved (as if we just manually called calloc() to retrieve a pointer). Later (during postparsing) if guid is set we try to upgrade the pointer from local to shared. Lastly, since the memory location for some objects (proxies and servers counters) may change from creation to postparsing, let's update counters->last_change member directly under counters_{fe,be}_shared_get() so we don't miss it. No change of behavior is expected, this is only preparation work.
2025-05-07 17:42:04 -04:00
MEDIUM: guid: switch guid to more compact cebuis_tree The current guid struct size is 56 bytes. Once reduced using compact trees, it goes down to 32 (almost half). We're not on a critical path and size matters here, so better switch to this. It's worth noting that the name part could also be stored in the guid_node at the end to save 8 extra byte (no pointer needed anymore), however the purpose of this struct is to be embedded into other ones, which is not compatible with having a dynamic size. Affected struct sizes in bytes: Before After Diff server 4032 4032 0* proxy 3184 3160 -24 listener 752 728 -24 *: struct server is full of holes and padding (176 bytes) and is 64-byte aligned. Moving the guid_node elsewhere such as after sess_conn reduces it to 3968, or one less cache line. There's no point in moving anything now because forthcoming patches will arrange other parts.
2025-02-17 03:39:04 -05:00
if (!guid->key || !shm_stats_file_hdr)
MEDIUM: counters: manage shared counters using dedicated helpers proxies, listeners and server shared counters are now managed via helpers added in one of the previous commits. When guid is not set (ie: when not yet assigned), shared counters pointer is allocated using calloc() (local memory) and a flag is set on the shared counters struct to know how to manipulate (and free it). Else if guid is set, then it means that the counters may be shared so while for now we don't actually use a shared memory location the API is ready for that. The way it works, for proxies and servers (for which guid is not known during creation), we first call counters_{fe,be}_shared_get with guid not set, which results in local pointer being retrieved (as if we just manually called calloc() to retrieve a pointer). Later (during postparsing) if guid is set we try to upgrade the pointer from local to shared. Lastly, since the memory location for some objects (proxies and servers counters) may change from creation to postparsing, let's update counters->last_change member directly under counters_{fe,be}_shared_get() so we don't miss it. No change of behavior is expected, this is only preparation work.
2025-05-07 17:42:04 -04:00
shared->flags |= COUNTERS_SHARED_F_LOCAL;
MEDIUM: stats-file/counters: store and preload stats counters as shm file objects This is the last patch of the shm stats file series, in this patch we implement the logic to store and fetch shm stats objects and associate them to existing shared counters on the current process. Shm objects are stored in the same memory location as the shm stats file header. In fact they are stored right after it. All objects (struct shm_stats_file_object) have the same size (no matter their type), which allows for easy object traversal without having to check the object's type, and could permit the use of external tools to scan the SHM in the future. Each object stores a guid (of GUID_MAX_LEN+1 size) and tgid which allows to match corresponding shared counters indexes. Also, as stated before, each object stores the list of users making use of it. Objects are never released (the map can only grow), but unused objects (when no more users or active users are found in objects->users), the object is automatically recycled. Also, each object stores its type which defines how the object generic data member should be handled. Upon startup (or reload), haproxy first tries to scan existing shm to find objects that could be associated to frontends, backends, listeners or servers in the current config based on GUID. For associations that couldn't be made, haproxy will automatically create missing objects in the SHM during late startup. When haproxy matches with an existing object, it means the counter from an older process is preserved in the new process, so multiple processes temporarily share the same counter for as long as required for older processes to eventually exit.
2025-08-27 11:23:42 -04:00
MEDIUM: counters: Dynamically allocate per-thread group counters Instead of statically allocating the per-thread group counters, based on the max number of thread groups available, allocate them dynamically, based on the number of thread groups actually used. That way we can increase the maximum number of thread groups without using an unreasonable amount of memory.
2026-01-11 22:25:34 -05:00
if (!shared->tg) {
shared->tg = calloc(global.nbtgroups, sizeof(*shared->tg));
if (!shared->tg) {
memprintf(errmsg, "couldn't allocate memory for shared counters");
return 0;
}
}
MAJOR: counters: dispatch counters over thread groups Most fe and be counters are good candidates for being shared between processes. They are now grouped inside "shared" struct sub member under be_counters and fe_counters. Now they are properly identified, they would greatly benefit from being shared over thread groups to reduce the cost of atomic operations when updating them. For this, we take the current tgid into account so each thread group only updates its own counters. For this to work, it is mandatory that the "shared" member from {fe,be}_counters is initialized AFTER global.nbtgroups is known, because each shared counter causes the stat to be allocated lobal.nbtgroups times. When updating a counter without concurrency, the first counter from the array may be updated. To consult the shared counters (which requires aggregation of per-tgid individual counters), some helper functions were added to counter.h to ease code maintenance and avoid computing errors.
2025-05-15 13:55:11 -04:00
while (it < global.nbtgroups) {
MEDIUM: stats-file/counters: store and preload stats counters as shm file objects This is the last patch of the shm stats file series, in this patch we implement the logic to store and fetch shm stats objects and associate them to existing shared counters on the current process. Shm objects are stored in the same memory location as the shm stats file header. In fact they are stored right after it. All objects (struct shm_stats_file_object) have the same size (no matter their type), which allows for easy object traversal without having to check the object's type, and could permit the use of external tools to scan the SHM in the future. Each object stores a guid (of GUID_MAX_LEN+1 size) and tgid which allows to match corresponding shared counters indexes. Also, as stated before, each object stores the list of users making use of it. Objects are never released (the map can only grow), but unused objects (when no more users or active users are found in objects->users), the object is automatically recycled. Also, each object stores its type which defines how the object generic data member should be handled. Upon startup (or reload), haproxy first tries to scan existing shm to find objects that could be associated to frontends, backends, listeners or servers in the current config based on GUID. For associations that couldn't be made, haproxy will automatically create missing objects in the SHM during late startup. When haproxy matches with an existing object, it means the counter from an older process is preserved in the new process, so multiple processes temporarily share the same counter for as long as required for older processes to eventually exit.
2025-08-27 11:23:42 -04:00
if (shared->flags & COUNTERS_SHARED_F_LOCAL) {
size_t tg_size;
tg_size = (is_be) ? sizeof(*be_shared->tg[0]) : sizeof(*fe_shared->tg[0]);
shared->tg[it] = calloc(1, tg_size);
if (!shared->tg[it])
memprintf(errmsg, "memory error, calloc failed");
}
else if (!shared->tg[it]) {
struct shm_stats_file_object *shm_obj;
shm_obj = shm_stats_file_add_object(errmsg);
if (shm_obj) {
BUG/MINOR: counters: fix unexpected 127 char GUID truncation for shm-stats-file objects As reported by GH @phihos on GH #3320, using the shm-stats-file feature with objects exceeding 127 chars would result in object name being unexpectedly truncated, while GUID API supports up to 128 chars. Indeed, with the config below, and shm-stats-file enabled: server s1 127.0.0.1:1 guid srv:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:SRV_1 disabled server s10 127.0.0.1:1 guid srv:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:SRV_10 disabled haproxy would store the second server object with the same id as the first one, but upon reload, only the first one would be restored, which would eventually cause shm-stats-file slot exhaustion with repetitive reloads. @phihos, found out the underlying issue, in counters.c we used snprintf() with sizeof(shm_obj->guid) - 1 as <size> parameter, while we should have use sizeof(shm_obj->guid) instead since shm_obj->guid already takes the terminating NULL byte into account. So we simply apply the fix suggested by @phihos, and hopefully this should solve the shm-stats-file slot leak that was observed. Unfortunately, for now, we cannot warn the user that a duplicate shm-stats-file object was found, because we accept duplicate objects by design for 2 reasons. The first one is for a new process to be able to change the object type for a previously known GUID while allowing previous processes to use the old object as long as they are alive. The second reason is that upon startup we cannot afford to scan the whole object list, as soon as we find a match (type + GUID), we bind the object, and this way we avoid unnecessary lookup time. Perhaps we have room for improvement in the future, but for now let's keep it this way. It should be backported to 3.3 Big thanks to @phihos for the bug description, analysis and suggestions.
2026-04-03 10:12:46 -04:00
snprintf(shm_obj->guid, sizeof(shm_obj->guid), "%s", guid_get(guid));
MEDIUM: stats-file/counters: store and preload stats counters as shm file objects This is the last patch of the shm stats file series, in this patch we implement the logic to store and fetch shm stats objects and associate them to existing shared counters on the current process. Shm objects are stored in the same memory location as the shm stats file header. In fact they are stored right after it. All objects (struct shm_stats_file_object) have the same size (no matter their type), which allows for easy object traversal without having to check the object's type, and could permit the use of external tools to scan the SHM in the future. Each object stores a guid (of GUID_MAX_LEN+1 size) and tgid which allows to match corresponding shared counters indexes. Also, as stated before, each object stores the list of users making use of it. Objects are never released (the map can only grow), but unused objects (when no more users or active users are found in objects->users), the object is automatically recycled. Also, each object stores its type which defines how the object generic data member should be handled. Upon startup (or reload), haproxy first tries to scan existing shm to find objects that could be associated to frontends, backends, listeners or servers in the current config based on GUID. For associations that couldn't be made, haproxy will automatically create missing objects in the SHM during late startup. When haproxy matches with an existing object, it means the counter from an older process is preserved in the new process, so multiple processes temporarily share the same counter for as long as required for older processes to eventually exit.
2025-08-27 11:23:42 -04:00
if (is_be) {
shm_obj->type = SHM_STATS_FILE_OBJECT_TYPE_BE;
be_shared = (struct be_counters_shared *)shared;
be_shared->tg[it] = &shm_obj->data.be;
}
else {
shm_obj->type = SHM_STATS_FILE_OBJECT_TYPE_FE;
fe_shared = (struct fe_counters_shared *)shared;
fe_shared->tg[it] = &shm_obj->data.fe;
}
/* we use atomic op to make the object visible by setting valid tgid value */
HA_ATOMIC_STORE(&shm_obj->tgid, it + 1);
}
}
MAJOR: counters: dispatch counters over thread groups Most fe and be counters are good candidates for being shared between processes. They are now grouped inside "shared" struct sub member under be_counters and fe_counters. Now they are properly identified, they would greatly benefit from being shared over thread groups to reduce the cost of atomic operations when updating them. For this, we take the current tgid into account so each thread group only updates its own counters. For this to work, it is mandatory that the "shared" member from {fe,be}_counters is initialized AFTER global.nbtgroups is known, because each shared counter causes the stat to be allocated lobal.nbtgroups times. When updating a counter without concurrency, the first counter from the array may be updated. To consult the shared counters (which requires aggregation of per-tgid individual counters), some helper functions were added to counter.h to ease code maintenance and avoid computing errors.
2025-05-15 13:55:11 -04:00
if (!shared->tg[it]) {
_counters_shared_drop(shared);
MEDIUM: stats: avoid 1 indirection by storing the shared stats directly in counters struct Between 3.2 and 3.3-dev we noticed a noticeable performance regression due to stats handling. After bisecting, Willy found out that recent work to split stats computing accross multiple thread groups (stats sharding) was responsible for that performance regression. We're looking at roughly 20% performance loss. More precisely, it is the added indirections, multiplied by the number of statistics that are updated for each request, which in the end causes a significant amount of time being spent resolving pointers. We noticed that the fe_counters_shared and be_counters_shared structures which are currently allocated in dedicated memory since a0dcab5c ("MAJOR: counters: add shared counters base infrastructure") are no longer huge since 16eb0fab31 ("MAJOR: counters: dispatch counters over thread groups") because they now essentially hold flags plus the per-thread group id pointer mapping, not the counters themselves. As such we decided to try merging fe_counters_shared and be_counters_shared in their parent structures. The cost is slight memory overhead for the parent structure, but it allows to get rid of one pointer indirection. This patch alone yields visible performance gains and almost restores 3.2 stats performance. counters_fe_shared_get() was renamed to counters_fe_shared_prepare() and now returns either failure or success instead of a pointer because we don't need to retrieve a shared pointer anymore, the function takes care of initializing existing pointer.
2025-07-22 11:15:02 -04:00
return 0;
MAJOR: counters: dispatch counters over thread groups Most fe and be counters are good candidates for being shared between processes. They are now grouped inside "shared" struct sub member under be_counters and fe_counters. Now they are properly identified, they would greatly benefit from being shared over thread groups to reduce the cost of atomic operations when updating them. For this, we take the current tgid into account so each thread group only updates its own counters. For this to work, it is mandatory that the "shared" member from {fe,be}_counters is initialized AFTER global.nbtgroups is known, because each shared counter causes the stat to be allocated lobal.nbtgroups times. When updating a counter without concurrency, the first counter from the array may be updated. To consult the shared counters (which requires aggregation of per-tgid individual counters), some helper functions were added to counter.h to ease code maintenance and avoid computing errors.
2025-05-15 13:55:11 -04:00
}
it += 1;
}
MINOR: counters: rename last_change counter to last_state_change Since proxy and server struct already have an internal last_change variable and we cannot merge it with the shared counter one, let's rename the last_change counter to be more specific and prevent the mixup between the two. last_change counter is renamed to last_state_change, and unlike the internal last_change, this one is a shared counter so it is expected to be updated by other processes in our back. However, when updating last_state_change counter, we use the value of the server/proxy last_change as reference value.
2025-06-30 09:55:56 -04:00
/* initial values:
* only set one group, only latest value is considered
*/
HA_ATOMIC_STORE(&shared->tg[0]->last_state_change, ns_to_sec(now_ns));
MEDIUM: stats: avoid 1 indirection by storing the shared stats directly in counters struct Between 3.2 and 3.3-dev we noticed a noticeable performance regression due to stats handling. After bisecting, Willy found out that recent work to split stats computing accross multiple thread groups (stats sharding) was responsible for that performance regression. We're looking at roughly 20% performance loss. More precisely, it is the added indirections, multiplied by the number of statistics that are updated for each request, which in the end causes a significant amount of time being spent resolving pointers. We noticed that the fe_counters_shared and be_counters_shared structures which are currently allocated in dedicated memory since a0dcab5c ("MAJOR: counters: add shared counters base infrastructure") are no longer huge since 16eb0fab31 ("MAJOR: counters: dispatch counters over thread groups") because they now essentially hold flags plus the per-thread group id pointer mapping, not the counters themselves. As such we decided to try merging fe_counters_shared and be_counters_shared in their parent structures. The cost is slight memory overhead for the parent structure, but it allows to get rid of one pointer indirection. This patch alone yields visible performance gains and almost restores 3.2 stats performance. counters_fe_shared_get() was renamed to counters_fe_shared_prepare() and now returns either failure or success instead of a pointer because we don't need to retrieve a shared pointer anymore, the function takes care of initializing existing pointer.
2025-07-22 11:15:02 -04:00
return 1;
MINOR: counters: add shared counters helpers to get and drop shared pointers create include/haproxy/counters.h and src/counters.c files to anticipate for further helpers as some counters specific tasks needs to be carried out and since counters are shared between multiple object types (ie: listener, proxy, server..) we need generic helpers. Add some shared counters helper which are not yet used but will be updated in upcoming commits.
2025-05-06 14:45:40 -04:00
}
MEDIUM: stats: avoid 1 indirection by storing the shared stats directly in counters struct Between 3.2 and 3.3-dev we noticed a noticeable performance regression due to stats handling. After bisecting, Willy found out that recent work to split stats computing accross multiple thread groups (stats sharding) was responsible for that performance regression. We're looking at roughly 20% performance loss. More precisely, it is the added indirections, multiplied by the number of statistics that are updated for each request, which in the end causes a significant amount of time being spent resolving pointers. We noticed that the fe_counters_shared and be_counters_shared structures which are currently allocated in dedicated memory since a0dcab5c ("MAJOR: counters: add shared counters base infrastructure") are no longer huge since 16eb0fab31 ("MAJOR: counters: dispatch counters over thread groups") because they now essentially hold flags plus the per-thread group id pointer mapping, not the counters themselves. As such we decided to try merging fe_counters_shared and be_counters_shared in their parent structures. The cost is slight memory overhead for the parent structure, but it allows to get rid of one pointer indirection. This patch alone yields visible performance gains and almost restores 3.2 stats performance. counters_fe_shared_get() was renamed to counters_fe_shared_prepare() and now returns either failure or success instead of a pointer because we don't need to retrieve a shared pointer anymore, the function takes care of initializing existing pointer.
2025-07-22 11:15:02 -04:00
/* prepare shared fe counters pointer for a given <guid> object */
MINOR: counters: retrieve detailed errmsg upon failure with counters_{fe,be}_shared_prepare() counters_{fe,be}_shared_prepare now take an extra <errmsg> parameter that contains additional hints about the error in case of failure. It must be freed accordingly since it is allocated using memprintf
2025-08-27 08:51:48 -04:00
int counters_fe_shared_prepare(struct fe_counters_shared *shared, const struct guid_node *guid, char **errmsg)
MINOR: counters: add shared counters helpers to get and drop shared pointers create include/haproxy/counters.h and src/counters.c files to anticipate for further helpers as some counters specific tasks needs to be carried out and since counters are shared between multiple object types (ie: listener, proxy, server..) we need generic helpers. Add some shared counters helper which are not yet used but will be updated in upcoming commits.
2025-05-06 14:45:40 -04:00
{
MEDIUM: stats-file/counters: store and preload stats counters as shm file objects This is the last patch of the shm stats file series, in this patch we implement the logic to store and fetch shm stats objects and associate them to existing shared counters on the current process. Shm objects are stored in the same memory location as the shm stats file header. In fact they are stored right after it. All objects (struct shm_stats_file_object) have the same size (no matter their type), which allows for easy object traversal without having to check the object's type, and could permit the use of external tools to scan the SHM in the future. Each object stores a guid (of GUID_MAX_LEN+1 size) and tgid which allows to match corresponding shared counters indexes. Also, as stated before, each object stores the list of users making use of it. Objects are never released (the map can only grow), but unused objects (when no more users or active users are found in objects->users), the object is automatically recycled. Also, each object stores its type which defines how the object generic data member should be handled. Upon startup (or reload), haproxy first tries to scan existing shm to find objects that could be associated to frontends, backends, listeners or servers in the current config based on GUID. For associations that couldn't be made, haproxy will automatically create missing objects in the SHM during late startup. When haproxy matches with an existing object, it means the counter from an older process is preserved in the new process, so multiple processes temporarily share the same counter for as long as required for older processes to eventually exit.
2025-08-27 11:23:42 -04:00
return _counters_shared_prepare((struct counters_shared *)shared, guid, 0, errmsg);
MINOR: counters: add shared counters helpers to get and drop shared pointers create include/haproxy/counters.h and src/counters.c files to anticipate for further helpers as some counters specific tasks needs to be carried out and since counters are shared between multiple object types (ie: listener, proxy, server..) we need generic helpers. Add some shared counters helper which are not yet used but will be updated in upcoming commits.
2025-05-06 14:45:40 -04:00
}
MEDIUM: stats: avoid 1 indirection by storing the shared stats directly in counters struct Between 3.2 and 3.3-dev we noticed a noticeable performance regression due to stats handling. After bisecting, Willy found out that recent work to split stats computing accross multiple thread groups (stats sharding) was responsible for that performance regression. We're looking at roughly 20% performance loss. More precisely, it is the added indirections, multiplied by the number of statistics that are updated for each request, which in the end causes a significant amount of time being spent resolving pointers. We noticed that the fe_counters_shared and be_counters_shared structures which are currently allocated in dedicated memory since a0dcab5c ("MAJOR: counters: add shared counters base infrastructure") are no longer huge since 16eb0fab31 ("MAJOR: counters: dispatch counters over thread groups") because they now essentially hold flags plus the per-thread group id pointer mapping, not the counters themselves. As such we decided to try merging fe_counters_shared and be_counters_shared in their parent structures. The cost is slight memory overhead for the parent structure, but it allows to get rid of one pointer indirection. This patch alone yields visible performance gains and almost restores 3.2 stats performance. counters_fe_shared_get() was renamed to counters_fe_shared_prepare() and now returns either failure or success instead of a pointer because we don't need to retrieve a shared pointer anymore, the function takes care of initializing existing pointer.
2025-07-22 11:15:02 -04:00
/* prepare shared be counters pointer for a given <guid> object */
MINOR: counters: retrieve detailed errmsg upon failure with counters_{fe,be}_shared_prepare() counters_{fe,be}_shared_prepare now take an extra <errmsg> parameter that contains additional hints about the error in case of failure. It must be freed accordingly since it is allocated using memprintf
2025-08-27 08:51:48 -04:00
int counters_be_shared_prepare(struct be_counters_shared *shared, const struct guid_node *guid, char **errmsg)
MINOR: counters: add shared counters helpers to get and drop shared pointers create include/haproxy/counters.h and src/counters.c files to anticipate for further helpers as some counters specific tasks needs to be carried out and since counters are shared between multiple object types (ie: listener, proxy, server..) we need generic helpers. Add some shared counters helper which are not yet used but will be updated in upcoming commits.
2025-05-06 14:45:40 -04:00
{
MEDIUM: stats-file/counters: store and preload stats counters as shm file objects This is the last patch of the shm stats file series, in this patch we implement the logic to store and fetch shm stats objects and associate them to existing shared counters on the current process. Shm objects are stored in the same memory location as the shm stats file header. In fact they are stored right after it. All objects (struct shm_stats_file_object) have the same size (no matter their type), which allows for easy object traversal without having to check the object's type, and could permit the use of external tools to scan the SHM in the future. Each object stores a guid (of GUID_MAX_LEN+1 size) and tgid which allows to match corresponding shared counters indexes. Also, as stated before, each object stores the list of users making use of it. Objects are never released (the map can only grow), but unused objects (when no more users or active users are found in objects->users), the object is automatically recycled. Also, each object stores its type which defines how the object generic data member should be handled. Upon startup (or reload), haproxy first tries to scan existing shm to find objects that could be associated to frontends, backends, listeners or servers in the current config based on GUID. For associations that couldn't be made, haproxy will automatically create missing objects in the SHM during late startup. When haproxy matches with an existing object, it means the counter from an older process is preserved in the new process, so multiple processes temporarily share the same counter for as long as required for older processes to eventually exit.
2025-08-27 11:23:42 -04:00
return _counters_shared_prepare((struct counters_shared *)shared, guid, 1, errmsg);
MINOR: counters: add shared counters helpers to get and drop shared pointers create include/haproxy/counters.h and src/counters.c files to anticipate for further helpers as some counters specific tasks needs to be carried out and since counters are shared between multiple object types (ie: listener, proxy, server..) we need generic helpers. Add some shared counters helper which are not yet used but will be updated in upcoming commits.
2025-05-06 14:45:40 -04:00
}
Reference in a new issue Copy permalink