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

בדף הזה מפורט מידע על המכסות והמגבלות של 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 שניות, אתם צריכים לחכות עד שהמכסה הזו תתמלא מחדש לפני שתגישו בקשות נוספות בקטגוריה הזו. אם תחרגו מהמגבלה הזו בפרויקט, תקבלו קוד סטטוס 429‏ HTTP עם הסיבה 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.
  • השהיה מעריכית לפני ניסיון חוזר (exponential backoff): ודאו שלוגיקת הניסיון החוזר של הלקוח משתמשת בהשהיה מעריכית לפני ניסיון חוזר עם רעידות, כדי להימנע משליחת פרצי בקשות שחורגים ממגבלת הקצב.
  • חלוקת עומסי עבודה בין חשבונות שירות: אם כמה עומסי עבודה חולקים חשבון שירות אחד או פרויקט צרכן אחד, צריך ליצור חשבונות שירות ייעודיים לכל עומס עבודה כדי למנוע מצב שבו עומס עבודה אחד ינצל את המכסה המשותפת.
  • בקשה לשינוי המכסות: אם האפליקציה שלכם דורשת תפוקה גבוהה יותר, אתם יכולים לבקש להגדיל את המכסות לקצב הגשת בקשות של Cloud SQL Admin API.

מגבלות

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

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

מכונות לכל פרויקט

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

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

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

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

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

MySQL

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

כדי למצוא את מגבלת החיבורים של המכונה, מתחברים למסד הנתונים ומריצים את הפקודה הבאה: SHOW VARIABLES LIKE "max_connections";

PostgreSQL

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

כדי לראות את מגבלות החיבור למכונה, מתחברים למסד הנתונים ומריצים את הפקודה הבאה: SELECT * FROM pg_settings WHERE name = 'max_connections';

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

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

שרת SQL

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

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

הערות

ניצול המכסות של מחברי Cloud SQL

שרת 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). יש גם כלל שינוי למכסה לכל רשת ולמכסות לכל קבוצת Peering, עבור Cloud SQL. כלומר, כשמגדילים את המכסה לכל רשת ברשתות של ספקי השירות, המכסה לכל קבוצת רשתות שכנות (peering) גדלה גם היא לאותו ערך.

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

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

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

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

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

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

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

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

IOPS

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

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

מגבלת טבלה

ב-Cloud SQL ל-MySQL יש מגבלה של 50,000 טבלאות כברירת מחדל, או 500,000 טבלאות למכונה אם אתם עומדים בדרישות החומרה המינימליות של לפחות 32 ליבות וזיכרון של 200G לפחות. כדי ליהנות מביצועים אופטימליים, מומלץ שמספר הטבלאות במסד נתונים אחד לא יעלה על 50,000.

מכונות שחורגות מהמגבלות האלה לא נכללות בהסכם רמת השירות (SLA). אם הדגל innodb_file_per_table של מסד הנתונים מופעל, וגודל הטבלה מגיע ל-16 TB, הגודל המקסימלי למחיצות של Linux, לא ניתן להוסיף נתונים נוספים.

כמות הזיכרון שנדרשת למכונה תלויה בגורמים שונים. במאמר איך MySQL משתמש בזיכרון מוסבר בהרחבה על השימוש של Cloud SQL ל-MySQL בזיכרון.

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

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

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

אם מספר הטבלאות הפעילות גדול משמעותית ממספר ברירת המחדל של הטבלאות ב-Cloud SQL ומההמלצה של MySQL לגבי טבלאות פתוחות, Cloud SQL ממליץ להגדיר את הדגלים לניהול מסד נתונים table_open_cache ו-table_definition_cache עם מספר הטבלאות הפעילות במכונה. למידע נוסף, קראו את המאמר How MySQL Opens and Closes Tables.

גודל הטבלה המקסימלי ב-Cloud SQL ל-PostgreSQL הוא 32TB. כשטבלה מגיעה לגודל של 32TB, אי אפשר להוסיף לה עוד נתונים.

מגבלת הפעולות

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

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

מגבלות של ExecuteSQL

לבקשות אל ExecuteSql API בארכיטקטורת REST יש את המגבלות הבאות:

  • בכל רגע נתון יכולות להיות עד 10 שאילתות בו-זמנית לכל מופע.
  • הגבלת קצב של יצירת בקשות לשאילתות מוגבלת ל-100 שאילתות לדקה לכל פרויקט לכל אזור.
  • הגודל של הבקשות מוגבל ל-512KiB (0.5MiB), והגודל של התשובות מוגבל ל-10MiB.

מגבלת איסוף המדדים

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

מגבלות האחסון ב-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 Run יכולים להיות עד 100 חיבורים לכל מסד נתונים ב-Cloud SQL.

לכל מופע של שירות או משימה ב-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 Run יכולים להיות עד 100 חיבורים לכל מסד נתונים ב-Cloud SQL.

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

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

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

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

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