Skip to content

using worker_id instead of pid will produce fewer db files #430

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

Closed
wants to merge 1 commit into from

Conversation

cai-personal
Copy link

As the program is restarted frequently, more and more db files will be generated. These files are cumbersome to manage, and aggregate metrics also consume resources.

If the worker id is used as the db file naming method, as long as the number of wokers is determined and the metric type is unchanged, the number of generated db files will not increase, but the values ​​in the file are changing.

image

this will slow down the prometheus scrape duration.

Signed-off-by: fangjianfeng <fangjianfeng@rightpaddle.com>

using worker_id instead of pid will produce fewer db files

As the program is restarted frequently, more and more db files will be generated. These files are cumbersome to manage, and aggregate metrics also consume resources.

If the worker id is used as the db file naming method, as long as the number of wokers is determined and the metric type is unchanged, the number of generated db files will not increase, but the values ​​in the file are changing.
@brian-brazil
Copy link
Contributor

This would break everyone not using uwsgi. Doing an import on every metric declaration would also be unwise.

@cai-personal
Copy link
Author

This would break everyone not using uwsgi. Doing an import on every metric declaration would also be unwise.

uwsgi is used in my project, in order to avoid generating too many db files, modify it to this. Indeed, every time read metric, it will be imported once. I will consider how to optimize.

thanks

@QuicksilverMachine
Copy link

QuicksilverMachine commented Jun 20, 2019

Maybe the function for getting the ID could be configurable from the outside, so the default behavior could stay as it is if it's not set, but would allow for overrides for each individual case?

@cai-personal
Copy link
Author

Maybe the function for getting the ID could be configurable from the outside, so the default behavior could stay as it is if it's not set, but would allow for overrides for each individual case?

There is no problem get it outside.

and

If modify this method to use a class implementation, it is better to support user-defined functions that pass in <_pidFunc>

@brian-brazil
Copy link
Contributor

This has gone stale, and would still break many users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants