Skip to content
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

[DB-15464][Sizing Calc] buffer to choose higher vCPU instance type #2348

Merged
merged 9 commits into from
Mar 7, 2025

Conversation

shaharuk-yb
Copy link
Contributor

@shaharuk-yb shaharuk-yb commented Feb 20, 2025

Describe the changes in this pull request

Pre-calculate the required number of cores and use it for selecting the appropriate instance type recommendation.
Current sizing calculator decides final recommendation based on the number of nodes required in later stage( which is calculated using the required number of cores in the first place). Hence, the better way is to use required number of cores.

example: Take into consideration following two sizing recommendation are suitable.

  • 8 vCPU setup needing 296 cores gives 37 nodes.
  • 16 vCPU setup needing 290 cores gives 19 nodes.
    But, currently, in pickBestRecommendation, while recalculating the cores, it uses nodes * vCPU. Thus giving,
    8 * 37 ==> 296
    16 * 19 ==> 304
    Even though the required cores were 290 but because of reverse calc, it says 304 cores required for 16 vCPU setup and hence current sizing calculator suggest 8vCPU setup as it favours lesser cores(even though the number of required cores originally were higher).

This change directly considers required cores instead on recalculating it. Giving better recommendation.

Describe if there are any user-facing changes

NA

How was this pull request tested?

Manually and with CI jobs.

Does your PR have changes that can cause upgrade issues?

Component Breaking changes?
MetaDB No
Name registry json No
Data File Descriptor Json No
Export Snapshot Status Json No
Import Data State No
Export Status Json No
Data .sql files of tables No
Export and import data queue No
Schema Dump No
AssessmentDB No
Sizing DB No
Migration Assessment Report Json No
Callhome Json No
YugabyteD Tables No
TargetDB Metadata Tables No

Copy link
Collaborator

@sanyamsinghal sanyamsinghal left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks for the clear PR description.

priyanshi-yb and others added 7 commits February 27, 2025 14:25
…f session_replication_role session variable is used (#2322)

Adding GRANT SQL for granting the SET on session_replication_role to source-db-user to utilize it in Fallback case for import data to source
Added a check in GetEnabledTriggersAndFks(), to not fetch the triggers/Fks in case this session parameter is used.
…e and Check Constraints (#2330)

- ALTER TABLE ADD - Primary Key, Unique constraint and Check constraints ddls are merged into corresponding CREATE TABLE resulting in overall performance improvement of import schema. 
Cases where constraint is NOT VALID are skipped since it is for post snapshot phase.

* Added unit tests for transformer struct method Merge Constraints
* Fixed expected values in the assessment report tests
…s for the issue index on complex datatypes in schema report and assessment report (#2288)

- Earlier indexes on all the complex datatypes were reported under a single issue type: INDEX ON COMPLEX DATATYPES
- Added a separate issue for all such complex datatypes and removed the original issue.
- Reporting the issue in both the analyze schema report and the assessment report.
- Fixed issue: Define separate Issue for each case related to datatype(unsupported datatype, index on complex datatype) #2231
@shaharuk-yb shaharuk-yb merged commit c8306e4 into main Mar 7, 2025
66 checks passed
@shaharuk-yb shaharuk-yb deleted the sshaikh/db-15464 branch March 7, 2025 05:15
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.

4 participants