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

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

מכסות

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

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

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

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

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

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

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

בדיקת המכסות

כדי לבדוק את המכסות הנוכחיות של המשאבים בפרויקט, נכנסים לדף 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.
  • השהיה מעריכית לפני ניסיון חוזר (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

‫Cloud SQL Auth Proxy ומחברים אחרים של 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, כדאי לשים לב לנוסחה שלמעלה ולזכור את הדברים הבאים:

  • המהירות שבה אתם מגדילים את מספר הלקוחות החדשים של DB

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

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

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

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

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

כל מכונה של Cloud SQL מורכבת מכלל העברה וממאזן עומסים. יש מגבלת מכסה על כלל ההעברה, בהתאם לסוג מאזן העומסים שאליו הוא מפנה. יש כמה מכסות לכל סוג של כללי העברה, לכל פרויקט, לכל רשת ולכל קבוצת רשתות שכנות (peering). ב-Cloud SQL יש גם כלל שמחליף את המכסה לכל רשת ואת המכסות לכל קבוצת רשתות שכנות (peering). כלומר, כשמגדילים את המכסה לכל רשת ברשתות של היצרנים, המכסה לכל קבוצת רשתות שכנות (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 מופעל וגודל הטבלה מגיע ל-16TB (הגודל המקסימלי למחיצות של 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 (מעבד (CPU) יחיד) היא 50 פעולות בו-זמנית.

מגבלות ExecuteSQL

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

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

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

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

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

  • ליבה ייעודית: עד 64TB.

  • ליבת מעבד משותפת: עד 3TB.

    מידע נוסף זמין במאמר תמחור של מכונות.

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

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

המגבלות של App Engine

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

באפליקציות של 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

  • ליבה ייעודית: עד 64TB.

  • ליבת מעבד משותפת: עד 3TB.

    מידע נוסף זמין במאמר תמחור של מכונות.

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

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

המגבלות של App Engine

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

באפליקציות של 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 חיבורים למסד נתונים לכל מכונה.