Skip to content

Conversation

@Hor911
Copy link
Collaborator

@Hor911 Hor911 commented Jan 6, 2024

No description provided.

@Hor911 Hor911 requested review from dorooleg and uzhastik January 6, 2024 19:46
@github-actions
Copy link

github-actions bot commented Jan 6, 2024

Note

This is an automated comment that will be appended during run.

🔴 linux-x86_64-relwithdebinfo: some tests FAILED for commit 4be8e9f.

Test history

TESTS PASSED ERRORS FAILED SKIPPED MUTED?
59878 50639 0 4 9210 25

🔴 linux-x86_64-release-asan: some tests FAILED for commit 4be8e9f.

Test history

TESTS PASSED ERRORS FAILED SKIPPED MUTED?
15867 15703 0 32 123 9

@Hor911 Hor911 force-pushed the YQ-2702 branch 2 times, most recently from fb31e1e to 4be8e9f Compare January 13, 2024 08:38
PrepareAstAndPlan(pingTaskRequest, QueryStats.query_plan(), QueryStats.query_ast());
try {
pingTaskRequest.set_statistics(GetV1StatFromV2Plan(QueryStats.query_plan()));
TDuration duration = TDuration::MicroSeconds(QueryStats.total_duration_us());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we move this code to the separate function PrepareStatistics(...)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've made this refactoring already with next "--stat_full" feature, will merge in next PR

TString Scope;
TDuration Duration;
double CpuSecondsConsumed;
double Quota; // if zero, default quota is used
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is this parameter filled in or is it for the future usage?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was idea that client my override default expected load in relation to compiled query size (task count). Currently is not used


void Handle(TEvYdbCompute::TEvCpuLoadRequest::TPtr& ev) {
auto actorId = GetMonitoringActorIdByScope(ev.Get()->Get()->Scope);
if (actorId != TActorId{}) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

        if (actorId != TActorId{}) {
            Send(ev->Forward(actorId));
            return;
        }
        Send(ev->Sender, new TEvYdbCompute::TEvCpuLoadResponse(NYql::TIssues{NYql::TIssue{TStringBuilder{} << "Cluster load monitoring disabled"}}), 0, ev->Cookie);

to get rid of else

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why it is better?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does not matter in this case imho
but yes, no "else" - simplier code

uint32 DefaultQueryLoadPercentage = 5; // default 10
uint32 PendingQueueSize = 6; // default 0 == instant decline if overloaded
bool Inherit = 7; // whether to apply global config to databases (override, NOT merge)
uint32 CpuNumber = 8;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this option? What does this option mean (per house, per cluster)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is number if CPU per cluster. It is needed to align two different "systems". Why I ask for cluster load with Monitoring Service, I've got ratio between 0.0 and 1.0 for complete cluster. Query reports its usage in number of CPUs. To convert one to another we need to know number of CPU per cluster.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have another way to get this information? It's difficult to keep in consistent state two configs (ydb sls and fq proxy config). If we don't have another way than this solution is ok for me :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No other sources is available. This param is not mandatory, it is required for "cashback" feature - decrease CPU usage estimation after query completion. Allows better CPU utilization for short light queries

@Hor911 Hor911 requested a review from a team as a code owner January 26, 2024 19:15
@github-actions
Copy link

github-actions bot commented Jan 26, 2024

2024-01-26 19:18:40 UTC Pre-commit check for f047e7f has started.
2024-01-26 19:18:43 UTC Build linux-x86_64-release-asan is running...
🟢 2024-01-26 19:56:33 UTC Build successful.
2024-01-26 19:56:49 UTC Tests are running...
🔴 2024-01-26 21:35:23 UTC Some tests failed, follow the links below.

Test history

TESTS PASSED ERRORS FAILED SKIPPED MUTED?
15981 15871 0 19 55 36

@github-actions
Copy link

github-actions bot commented Jan 28, 2024

2024-01-28 19:59:15 UTC Pre-commit check for 43b60a2 has started.
2024-01-28 19:59:17 UTC Build linux-x86_64-relwithdebinfo is running...
🟢 2024-01-28 20:33:10 UTC Build successful.
2024-01-28 20:33:28 UTC Tests are running...
🔴 2024-01-28 21:58:50 UTC Some tests failed, follow the links below.

Test history

TESTS PASSED ERRORS FAILED SKIPPED MUTED?
60227 50936 0 2 9254 35

@github-actions
Copy link

github-actions bot commented Jan 28, 2024

2024-01-28 19:59:40 UTC Pre-commit check for 43b60a2 has started.
2024-01-28 19:59:42 UTC Build linux-x86_64-release-asan is running...
🟢 2024-01-28 20:39:08 UTC Build successful.
2024-01-28 20:39:25 UTC Tests are running...
🔴 2024-01-28 22:22:06 UTC Some tests failed, follow the links below.

Test history

TESTS PASSED ERRORS FAILED SKIPPED MUTED?
15984 15864 0 30 61 29

@Hor911 Hor911 merged commit 27e9095 into ydb-platform:main Jan 30, 2024
This was referenced Jan 31, 2024
dorooleg pushed a commit to dorooleg/ydb that referenced this pull request Feb 2, 2024
* Limit v2 compute load by CPU

* Mon fix

* Per db load config + cpu load ajustment (cashback)

* Review fixes

* Clear config etc
@starlinskiy starlinskiy mentioned this pull request Feb 12, 2024
@vitstn vitstn mentioned this pull request Feb 16, 2024
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