מכסות ומגבלות

בדף הזה מפורט מידע על המכסות והמגבלות של Cloud SQL. המכסות חלות על כל פרויקט, והמגבלות חלות על המופע או על הפרויקט, בהתאם למגבלה.

מכסות

מכסה מגבילה את כמות המשאבים של Google Cloud שאפשר להשתמש בהם בפרויקט ב- Google Cloud . ‫Cloud SQL הוא דוגמה למשאב מהסוג הזה.

ב-Cloud SQL, המכסות הן חלק ממערכת שמבצעת את הפעולות הבאות:

  • מעקב אחרי השימוש במכונות של Cloud SQL
  • מגבילה את השימוש במופעים האלה כדי לשמור על הוגנות ולצמצם עליות חדות בשימוש
  • שמירה על הגדרות שמחילות באופן אוטומטי הגבלות שנקבעו מראש
  • לספק אמצעי לביצוע שינויים במכסה או לשליחת בקשה לשינוי המכסה

כשחורגים מהמכסה, ברוב המקרים המערכת חוסמת מיד את הגישה למכונה הרלוונטית, והמשימה שאתם מנסים לבצע נכשלת. המכסות חלות על כל פרויקט ב- Google Cloud , והן משותפות לכל המכונות שמשתמשות בפרויקט הזה.

הרשאות לבדיקה ולהגדלה של המכסות

כדי לבדוק את המכסות ולהגדיל אותן, נדרשות ההרשאות הבאות:

כברירת מחדל, ההרשאות האלה כלולות בתפקידים הבסיסיים ב-IAM 'עריכה' ו'בעלים', ובתפקיד המוגדר מראש Quota Administrator. אם אתם צריכים הרשאות נוספות, פנו לאדמין של המכסה.

בדיקת המכסות

כדי לבדוק את המכסות הנוכחיות של משאבים בפרויקט, עוברים לדף Quotas במסוףGoogle Cloud ומסננים לפי Cloud SQL Admin API. המכסות האלה חלות רק על קריאות ל-API, ולא על שאילתות במסד הנתונים.

הגדלת המכסות

ככל שהשימוש שלכם ב- Google Cloud יתרחב עם הזמן, המכסות שלכם יגדלו בהתאם. אם אתם צופים עלייה משמעותית בשימוש, כדאי לשלוח את הבקשה כמה ימים מראש כדי לוודא שהמכסות יהיו בגודל המתאים.

אין תשלום על בקשה להגדלת מכסה. העלויות יגדלו רק אם תשתמשו ביותר משאבים.

כדי להגדיל את המכסות:

  1. נכנסים לדף Quotas במסוף Google Cloud .

    לדף Quotas

  2. מסננים לפי השירות Cloud SQL Admin API.

    אם השירות לא מופיע, מפעילים את Cloud SQL Admin API.

  3. מסמנים את התיבות לצד המכסות שרוצים לשנות ולוחצים על Edit quotas.

  4. לכל מכסה שבחרתם, בשדה New limit, מזינים את הערך של המגבלה הרצויה.

  5. בשדה Reason description, מזינים את הסיבה לבקשה להגדלת המכסה ולוחצים על Done.

  6. לוחצים על הבא.

  7. ממלאים את השם, כתובת האימייל ומספר הטלפון ולוחצים על שליחת הבקשה.

    אם נתקלתם בבעיות בהגדלת המכסות, אפשר לפתוח בקשת תמיכה.

איך מתחדשות מכסות המשאבים

המכסות היומיות מתחדשות כל יום בחצות, לפי שעון החוף המערבי של ארה"ב.

מכסות וזמינות משאבים

מכסות משאבים הן הכמות המקסימלית של משאבים שאפשר ליצור עבור סוג המשאב הזה, אם המשאבים האלה זמינים. המכסות לא מבטיחות שהמשאבים יהיו זמינים בכל זמן. אם משאב מסוים לא זמין פיזית באזור שלכם, לא תוכלו ליצור משאבים חדשים מהסוג הזה, גם אם נשארה לכם מכסה בפרויקט.

מכסות לקצב שליחת בקשות

‫Cloud SQL תומך במכסות קצב, שנקראות גם הגבלות קצב או מכסות API. מכסות לקצב שליחת בקשות מגדירות כמה בקשות אפשר לשלוח ל-Cloud SQL Admin API.

כל מכסה לקצב הגשת בקשות תואמת לכל הבקשות לקטגוריה של שיטה אחת או יותר של Cloud SQL Admin API. המכסות לקצב שליחת בקשות מתאפסות אחרי פרק זמן שמוגדר ל-Cloud SQL (לדוגמה, מספר בקשות API לדקה).

כשמשתמשים ב-CLI של gcloud או במסוף Google Cloud , שולחים בקשות ל-Cloud SQL Admin API והבקשות האלה נספרות במכסות הקצב. אם אתם משתמשים בחשבונות שירות כדי לגשת ל-API, גם הבקשות האלה נכללות במכסות לקצב הגשת בקשות.

מערכת Cloud SQL אוכפת וממלאת מחדש את מכסות לקצב הגשת בקשות באופן אוטומטי במרווחים של 60 שניות. אם הפרויקט שלכם מגיע למגבלת המכסה לקצב הגשת בקשות בפרק זמן של 60 שניות, תצטרכו להמתין עד שהמכסה תתמלא מחדש לפני שתוכלו לשלוח בקשות נוספות באותה קטגוריה. אם בפרויקט שלכם תהיה חריגה מהמגבלה הזו, תקבלו קוד סטטוס HTTP‏ 429 עם הסיבה rateLimitExceeded.

‫Cloud SQL Admin API מחולק לקטגוריות הבאות:

  • ‫Connect: חיפוש ערכים שנדרשים כדי להתחבר למסד נתונים של Cloud SQL.
  • ‫Get: אחזור מידע על משאב (לדוגמה, מופע, פעולה או גיבוי).
  • ‫List: רשימת משאבים.
  • Mutate: יצירה, שינוי ומחיקה של משאבים.
  • ברירת המחדל לכל אזור: אינטראקציה עם מכונה של Cloud SQL בלי להתחבר אליה, לאחזר אותה, להציג אותה ברשימה או לשנות אותה.
  • ברירת מחדל: הצגת רשימה של דגלים של מסדי נתונים וסוגי מכונות (רמות) למכונות Cloud SQL. ממשקי ה-API בקטגוריה הזו הם גלובליים.

ב-Cloud SQL יש מכסות קצב לכל קטגוריה לדקה, לכל משתמש ולכל אזור. לכל שילוב ייחודי של המאפיינים האלה, Cloud SQL מטיל הגבלת קצב של יצירת בקשות נפרדת.

‫Cloud SQL Admin API מפיק מדדים מפורטים שיכולים לעזור לכם לעקוב אחרי השימוש ב-API, לעקוב אחרי הביצועים של המכונה ב-Cloud SQL ושל ה-API, ולגלות בעיות בין המכונה לבין ה-API. מידע נוסף זמין במאמר מעקב אחרי השימוש ב-API.

בטבלה הבאה מפורטים המדד, ממשקי ה-API ומגבלת ברירת המחדל לכל קטגוריה:

קטגוריה מדד ממשקי API מגבלת ברירת המחדל
חיבור

sqladmin.googleapis.com/connect

מספר הבקשות שכל משתמש שולח לדקה לכל אזור כדי להשתמש בממשקי ה-API בקטגוריה הזו.

 1000
הורדה

sqladmin.googleapis.com/get

מספר הבקשות שכל משתמש יכול לשלוח לדקה לכל אזור כדי להשתמש בממשקי ה-API בקטגוריה הזו.

 500
רשימה

sqladmin.googleapis.com/list

מספר הבקשות שכל משתמש יכול לשלוח לדקה לכל אזור כדי להשתמש בממשקי ה-API בקטגוריה הזו.

 500
שינוי

sqladmin.googleapis.com/mutate

מספר הבקשות שכל משתמש יכול לשלוח לדקה לכל אזור כדי להשתמש בממשקי ה-API בקטגוריה הזו.

 180
ברירת המחדל לפי אזור

sqladmin.googleapis.com/
default_per_region

מספר הבקשות האזוריות שמוגדרות כברירת מחדל, שמתבצעות בכל דקה לכל משתמש בכל אזור, כדי להשתמש בממשקי ה-API בקטגוריה הזו.

 180
ברירת מחדל

sqladmin.googleapis.com/default

מספר ברירת המחדל של הבקשות שמשתמש יכול לשלוח בדקה כדי להשתמש בממשקי ה-API בקטגוריה הזו.

 180

פתרון שגיאות שקשורות למגבלת הקצב

מכיוון ש-Cloud SQL אוכף מכסות לקצב הגשת בקשות לדקה, לכל משתמש ולכל אזור, בדף Cloud Quotas במסוף Google Cloud לא מוצג השימוש במכסות לכל משתמש. אם משתמש או חשבון שירות יחיד ממצה את מכסת הקצב לכל משתמש, Cloud SQL Admin API מחזיר קוד סטטוס HTTP‏ 429 Too Many Requests עם הסיבה rateLimitExceeded. בתרחיש הזה, יכול להיות שמדדי המכסות המצטברים ברמת הפרויקט בדף Cloud Quotas יראו שהמכסה עדיין זמינה.

כדי לזהות איזה משתמש או חשבון שירות מנצל את מגבלת הקצב לכל משתמש, בצעו את הפעולות הבאות:

  1. במסוף Google Cloud , בוחרים את הפרויקט הצרכני שממנו נשלחות הבקשות ל-Cloud SQL, ואז נכנסים לדף Metrics Explorer.
  2. לוחצים על Select a metric ומזינים serviceruntime.googleapis.com/api/request_count בשורת הסינון. בתפריטי המשנה, בוחרים באפשרות Consumed API > Api > Request count, ואז לוחצים על Apply.
  3. ברכיב Filter, מוסיפים את המסננים הבאים כדי לבודד את הבקשות שבוצע להן ויסות נתונים:
    1. לוחצים על הוספת מסנן ואז בוחרים באפשרות response_code. בתיבת הדו-שיח של המסנן, משאירים את Comparator מוגדר ל-= (equals), מזינים 429 בשדה Value ולוחצים על Apply.
    2. לוחצים שוב על הוספת מסנן ובוחרים באפשרות service. משאירים את ההגדרה של Comparator (אופרטור השוואה) כ-= (equals) (שווה), מזינים sqladmin.googleapis.com בשדה Value (ערך) ולוחצים על Apply (החלה).
    3. אופציונלי: כדי לסנן לפי שיטת API ספציפית, לוחצים על Add filter ובוחרים את method. משאירים את Comparator מוגדר כ-= (equals), מזינים את שם השיטה בשדה Value (למשל google.cloud.sql.v1.SqlInstancesService.Get) ולוחצים על Apply.
  4. ברכיב Aggregation, מוודאים שהתפריט הראשון מוגדר לערך Sum, ואז בתפריט השני (לצד by) בוחרים באפשרות credential_id כדי לקבץ את מספר הבקשות לפי פרטי כניסה ספציפיים.
  5. בתוצאות, מחפשים את מזהה פרטי הכניסה (credential_id) עם הנפח הגבוה ביותר של קודי התגובה 429. הערך הזה הוא מזהה הלקוח ב-OAuth 2.0 של חשבון השירות או של פרטי הכניסה של המשתמש שמנצל את מגבלת הקצב לכל משתמש.
  6. כדי למצוא את חשבון השירות שתואם למזהה הלקוח, נכנסים לדף Service accounts במסוףGoogle Cloud ומזינים את מזהה הלקוח ב-OAuth 2.0 בתיבת הסינון. הרשומה התואמת היא חשבון השירות שמנצל את מגבלת הקצב לכל משתמש.

כדי לפתור את השגיאה אחרי שמזהים את חשבון השירות, צריך לבצע אחת או יותר מהפעולות הבאות:

  • הטמעת שמירת נתונים במטמון בצד הלקוח: אם האפליקציה שלכם מבצעת לעיתים קרובות סקר של מטא-נתונים של מופע – למשל במהלך הפעלה מחדש של קונטיינר או בדיקות תקינות – כדאי לשמור את המטא-נתונים של המופע במטמון כדי להימנע מקריאות חוזרות ל-SqlInstancesService.Get.
  • הטמעת השהיה מעריכית לפני ניסיון חוזר: מוודאים שהלוגיקה של הניסיון החוזר של הלקוח משתמשת בהשהיה מעריכית לפני ניסיון חוזר עם רעידות, כדי להימנע משליחת פרצי בקשות שחורגים ממגבלת הקצב.
  • פיזור עומסי עבודה בין חשבונות שירות: אם כמה עומסי עבודה משתפים חשבון שירות אחד או פרויקט צרכן אחד, צריך ליצור חשבונות שירות ייעודיים לכל עומס עבודה כדי למנוע מצב שבו עומס עבודה אחד ינצל את המכסה המשותפת.
  • בקשה לשינוי המכסות: אם האפליקציה שלכם דורשת תפוקה גבוהה יותר, אתם יכולים לבקש להגדיל את המכסות לקצב הגשת בקשות של Cloud SQL Admin API.

מגבלות

יש הגבלות על חלק מהמשאבים של Cloud SQL שלא מתחדשים באופן תקופתי ולא מוצגים בדף Quotas (מכסות) במסוף Google Cloud . חלק מהמגבלות אפשר להגדיל, וחלק לא.

מגבלות שניתן להגדיר

Instances per project

המספר המקסימלי של מופעים שיכולים להיות בפרויקט יחיד תלוי בארכיטקטורת הרשת של המופעים האלה:

  • ארכיטקטורת רשת חדשה של SQL: אפשר ליצור עד 1,000 מכונות בכל פרויקט.
  • ארכיטקטורת רשת SQL ישנה: אפשר ליצור עד 100 מכונות לכל פרויקט.
  • שימוש בשתי הארכיטקטורות: המגבלה תהיה בין 100 ל-1,000, בהתאם לפיזור של המופעים בשתי הארכיטקטורות.

כדי לבקש הגדלה, צריך לשלוח בקשת תמיכה. רפליקות לקריאה נספרות כמכונות.

מומלץ לפזר את מספר המכונות בין כמה פרויקטים כדי להפחית את ההסתמכות על בקשות להגדלת המכסות. כך תוכלו להימנע מחסימות פוטנציאליות.

מספר מקסימלי של חיבורים בו-זמניים

מספר החיבורים המותרים בפועל תלוי בגרסת SQL Server שבה אתם משתמשים, וגם במגבלות של האפליקציה או האפליקציות והחומרה שלכם. ב-SQL Server אפשר ליצור עד 32,767 חיבורי משתמשים.

מידע נוסף על הגדרת חיבורי משתמשים ב-SQL Server זמין במאמרי העזרה.

הערות

שימוש במכסת Cloud SQL Connectors

שרת proxy ל-Cloud SQL Auth ומחברים אחרים של Cloud SQL משתמשים במכסה של Cloud SQL Admin API. המחברים של Cloud SQL פועלים באמצעות פעולת רענון שמתבצעת בערך כל שעה. פעולת הרענון הזו מבצעת שתי קריאות ל-API. קריאה אחת מאחזרת את המטא-נתונים של המופע, והקריאה השנייה מאחזרת אישור זמני.

השימוש במכסה מחושב כך:

Quota usage = connector processes running * instances * 2 API calls per hour

לדוגמה, אם יש לכם שלושה תהליכים שמריצים מחבר, המחבר מוגדר להתחבר לשתי מכונות של Cloud SQL, ומתבצעות שתי קריאות ל-API למשך שעה, אז ניצול המכסה שלכם הוא 12 (3 תהליכים * 2 מכונות * 2 קריאות ל-API).

אם אתם מתחילים להשתמש ב-Cloud SQL, כדאי לשים לב לנוסחה שלמעלה ולזכור את הדברים הבאים:

  • כמה מהר אתם מרחיבים את הפעילות של לקוחות חדשים בתחום מסדי הנתונים

  • באיזו מהירות אתם מוסיפים עוד מכונות

  • שימוש בחשבונות שירות שונים לכל אפליקציה

אימות של מסד נתונים ב-Cloud SQL IAM

לכל מכונה יש מכסת התחברות לדקה, שכוללת גם התחברויות שהצליחו וגם התחברויות שנכשלו. אם חורגים מהמכסה, הכניסה לחשבון לא תהיה זמינה באופן זמני. מומלץ להימנע מהתחברויות תכופות ולהגביל את ההתחברויות באמצעות רשתות מורשות. המכסה לאישור התחברויות היא 12,000 לדקה, לכל מכונה.

מכסת כללי העברה

כל מכונה של Cloud SQL מורכבת מכלל העברה וממאזן עומסים. יש מגבלת מכסה על כלל ההעברה, בהתאם לסוג מאזן העומסים שאליו הוא מפנה. יש כמה מכסות לכל סוג של כללי העברה, לכל פרויקט, לכל רשת ולכל קבוצת קישור בין רשתות שכנות (peering). בנוסף, יש כלל לביטול מכסות לרשת ולמכסות לקבוצות של רשתות משותפות ב-Cloud SQL. כלומר, כשמגדילים את המכסה לכל רשת ברשתות של ספקי השירות, המכסה לכל קבוצת רשתות שכנות (peering) גדלה גם היא לאותו ערך.

רשת ה-VPC של יצרן Cloud SQL מקושרת לרשת ה-VPC של הלקוח, ולכן לעיתים קרובות אנחנו מגיעים למכסה לכל רשת של רשת היצרן של Cloud SQL, ולמכסה לכל קבוצת קישור לרשתות שכנות (peering) של רשת ה-VPC של הלקוח.

כשהמכסה מגיעה למקסימום, פעולות מסוימות עלולות להיכשל, כולל:

  • פעולת יצירה: אנחנו צריכים כללי העברה חדשים כשאנחנו יוצרים מכונות חדשות.

  • פעולת עדכון: אנחנו מאפשרים ללקוחות להחליף את הרשת של המכונות, ולכן אנחנו צריכים כללי העברה חדשים ברשת החדשה.

  • פעולת תחזוקה: כללי ההעברה נוצרים מחדש.

כדי למנוע בעיות, מומלץ להגביל את המספר הכולל של המופעים לכל רשת לפחות מ-500.

אם נתקלתם בבעיה, אתם יכולים לשלוח בקשת תמיכה ואנחנו נגדיל את המכסות הרלוונטיות.

מגבלות קבועות

IOPS

‫IOPS הוא מספר פעולות הקלט/פלט (או פעולות הקריאה/הכתיבה) שהדיסק יכול לעבד בשנייה.

ב-Cloud SQL משתמשים במכונות וירטואליות (VM) של Compute Engine עם דיסקים לאחסון מתמיד. לפרטים על מאפייני ביצועים ספציפיים של מכונות וירטואליות, עיינו בטבלה מספר מקסימלי של פעולות קלט/פלט לשנייה (IOPS) לטווח ארוך בדף ביצועים של Persistent Disk.

מגבלת פעולות

סוגי מכונות ברמת Micro ו-Small מגבילים את מספר הפעולות בו-זמנית. חריגה מהמגבלות האלה גורמת לשגיאה מסוג Too many operations.

המגבלה של סוג המכונה db-custom-1-3840 (מעבד (CPU) יחיד) היא 50 פעולות בו-זמנית.

מגבלות האחסון ב-Cloud SQL

אפשרויות האחסון ב-Cloud SQL

כדי להגדיר אפשרות אחסון לביצועים מיטביים, חשוב להבין את עומס העבודה ולבחור את סוג הדיסק והגודל המתאימים. למידע נוסף על האפשרויות הזמינות ב-Cloud SQL, ראו הגדרות של מכונות.

המגבלות של App Engine

לכל מכונה של App Engine שפועלת בסביבה סטנדרטית יכולים להיות עד 100 חיבורים בו-זמניים למכונה. באפליקציות PHP 5.5, המגבלה היא 60 חיבורים בו-זמנית.

באפליקציות של App Engine יש מגבלות זמן על בקשות, בהתאם לשימוש ולסביבה. מידע נוסף זמין במאמרים על ניהול מכונות ב-App Engine ב סביבת ברירת המחדל ב-App Engine וב סביבה גמישה.

אפליקציות App Engine כפופות גם למכסות ולמגבלות נוספות של App Engine, כפי שמוסבר בדף מכסות של App Engine.

מגבלות ב-Cloud Run

אם משתמשים בחיבור המובנה ל-Cloud SQL ב-Cloud Run, מספר החיבורים לכל מסד נתונים של Cloud SQL ממופעי קונטיינר של Cloud Run מוגבל ל-100.

לכל מכונה של שירות או משימה ב-Cloud Run יכולים להיות 100 חיבורים למסד הנתונים, וככל שהשירות או המשימה גדלים, המספר הכולל של החיבורים לכל פריסה יכול לגדול.

המגבלה הזו לא חלה כשמשתמשים בשיטות חיבור אחרות, כמו Cloud SQL Auth Proxy ב-sidecar, מחברי שפות ל-Cloud SQL או כשמתחברים ישירות לכתובת ה-IP של מופע Cloud SQL.

מגבלות על פונקציות Cloud Run

בפונקציות Cloud Run (דור ראשון), אפשר להריץ רק פונקציה אחת בכל מכונה. לעולם לא יקרה מצב שבו מופע פונקציה יחיד מהדור הראשון מעבד שתי בקשות בו-זמנית. ברוב המקרים, צריך רק חיבור אחד למסד נתונים.

פונקציות Cloud Run (דור שני) מבוססות על Cloud Run, ויש להן מגבלה של 100 חיבורים למסד נתונים לכל מופע.

מגבלות על שאילתות שמורות

ערך הגבלה
המספר המקסימלי של שאילתות שמורות לכל פרויקט (כולל שאילתות שמורות למוצרים אחרים) Google Cloud 10,000
הגודל המקסימלי של כל שאילתה ‫1 MiB

מגבלות האחסון ב-Cloud SQL

אפשרויות האחסון ב-Cloud SQL

כדי להגדיר אפשרות אחסון לביצועים מיטביים, חשוב להבין את עומס העבודה ולבחור את סוג הדיסק והגודל המתאימים. למידע נוסף על האפשרויות הזמינות ב-Cloud SQL, ראו הגדרות של מכונות.

מגבלות ב-App Engine

לכל מכונה של App Engine שפועלת בסביבה סטנדרטית יכולים להיות עד 100 חיבורים בו-זמניים למכונה. באפליקציות PHP 5.5, המגבלה היא 60 חיבורים בו-זמנית.

אפליקציות App Engine כפופות למגבלות זמן לבקשות, בהתאם לשימוש ולסביבה. מידע נוסף זמין במאמרים על ניהול מכונות ב-App Engine ב סביבת ברירת המחדל ב-App Engine וב סביבה גמישה.

אפליקציות App Engine כפופות גם למכסות ולמגבלות נוספות של App Engine, כפי שמוסבר בדף מכסות של App Engine.

מגבלות ב-Cloud Run

אם משתמשים בחיבור המובנה ל-Cloud SQL ב-Cloud Run, מספר החיבורים לכל מסד נתונים של Cloud SQL ממופעי קונטיינר של Cloud Run מוגבל ל-100.

לכל מכונה של שירות או משימה ב-Cloud Run יכולים להיות 100 חיבורים למסד הנתונים, וככל שהשירות או המשימה גדלים, המספר הכולל של החיבורים לכל פריסה יכול לגדול.

המגבלה הזו לא חלה כשמשתמשים בשיטות חיבור אחרות, כמו Cloud SQL Auth Proxy ב-sidecar, מחברי שפות ל-Cloud SQL או כשמתחברים ישירות לכתובת ה-IP של מופע Cloud SQL.

מגבלות על פונקציות Cloud Run

בפונקציות Cloud Run (דור ראשון), אפשר להריץ רק פונקציה אחת בכל מכונה. לעולם לא יקרה מצב שבו מופע פונקציה יחיד מהדור הראשון מעבד שתי בקשות בו-זמנית. ברוב המקרים, צריך רק חיבור אחד למסד נתונים.

פונקציות Cloud Run (דור שני) מבוססות על Cloud Run, ויש להן מגבלה של 100 חיבורים למסד נתונים לכל מופע.