בדף הזה מפורטות המכסות והמגבלות של Cloud SQL. המכסות חלות על כל פרויקט, והמגבלות חלות על המופע או על הפרויקט, בהתאם למגבלה.
מכסות
מכסה מגבילה את כמות המשאבים של Google Cloud שאפשר להשתמש בהם בפרויקט ב- Google Cloud . Cloud SQL הוא דוגמה לסוג כזה של משאב.
ב-Cloud SQL, המכסות הן חלק ממערכת שמבצעת את הפעולות הבאות:
- מעקב אחרי השימוש במכונות Cloud SQL
- מגבילה את השימוש במשאבים האלה כדי לשמור על הוגנות ולצמצם עליות חדות בשימוש
- שמירה על הגדרות שמחילות באופן אוטומטי הגבלות שנקבעו מראש
- לספק אמצעי לביצוע שינויים במכסה או לשליחת בקשה לשינוי המכסה
ברוב המקרים, כשחורגים מהמכסה, המערכת חוסמת מיד את הגישה למופע הרלוונטי, והמשימה שמנסים לבצע נכשלת. המכסות חלות על כל פרויקט ב- Google Cloud ומשותפות לכל המופעים שמשתמשים בפרויקט הזה.
הרשאות לבדיקה ולהגדלה של המכסות
כדי לבדוק את המכסות ולהגדיל אותן, דרושות לכם ההרשאות הבאות:
serviceusage.quotas.get:בדיקת המכסותserviceusage.quotas.update:הגדלת המכסות
כברירת מחדל, ההרשאות האלה כלולות בתפקידים הבסיסיים ב-IAM 'עריכה' ו'בעלים', ובתפקיד המוגדר מראש Quota Administrator. אם אתם צריכים הרשאות נוספות, פנו לאדמין של המכסה.
בדיקת המכסות
כדי לבדוק את המכסות הנוכחיות של משאבים בפרויקט, עוברים לדף Quotas במסוףGoogle Cloud ומסננים לפי Cloud SQL Admin API. המכסות האלה חלות רק על קריאות ל-API, ולא כוללות שאילתות במסד הנתונים.
הגדלת המכסות
ככל שהשימוש שלכם ב- Google Cloud יתרחב עם הזמן, המכסות שלכם יגדלו בהתאם. אם צפוי גידול משמעותי בשימוש, מומלץ לשלוח את הבקשה כמה ימים מראש כדי לוודא שהמכסות יספיקו.
אין תשלום על בקשה להגדלת מכסה. העלויות יגדלו רק אם תשתמשו ביותר משאבים.
כדי להגדיל את המכסות:
נכנסים לדף Quotas במסוף Google Cloud .
מסננים את השירות Cloud SQL Admin API.
אם השירות הזה לא מופיע, צריך להפעיל את Cloud SQL Admin API.
מסמנים את תיבות הסימון לצד המכסות שרוצים לשנות ולוחצים על עריכת מכסות.
לכל מכסה שבחרתם, בשדה New limit, מזינים את הערך של המגבלה הרצויה.
בשדה Reason description (תיאור הסיבה), מזינים את הסיבה לבקשה להגדלת המכסה ולוחצים על Done (סיום).
לוחצים על הבא.
ממלאים את השם, כתובת האימייל ומספר הטלפון ולוחצים על שליחת בקשה.
אם אתם נתקלים בבעיות בהגדלת המכסות, אתם יכולים לפתוח בקשת תמיכה.
איך מתבצעת מילוי מחדש של מכסות משאבים
המכסות היומיות מתחדשות כל יום בחצות לפי שעון החוף המערבי.
מכסות וזמינות משאבים
מכסות משאבים הן הכמות המקסימלית של משאבים שאפשר ליצור עבור סוג המשאב הזה, אם המשאבים זמינים. המיכסות לא מבטיחות שהמשאבים יהיו זמינים בכל זמן. אם משאב מסוים לא זמין פיזית באזור שלכם, לא תוכלו ליצור משאבים חדשים מהסוג הזה, גם אם עדיין יש לכם מכסה פנויה בפרויקט.
מכסות לקצב שליחת בקשות
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: רשימת משאבים.
- שינוי: יצירה, שינוי ומחיקה של משאבים.
- ברירת מחדל לכל אזור: אינטראקציה עם מופע Cloud SQL בלי להתחבר אליו, לאחזר, לפרט או לשנות אותו.
- ברירת מחדל: הצגת רשימה של דגלים של מסדי נתונים וסוגי מכונות (רמות) למכונות של Cloud SQL. ממשקי ה-API בקטגוריה הזו הם גלובליים.
ב-Cloud SQL יש מכסות קצב לכל קטגוריה לדקה, לכל משתמש ולכל אזור. לכל שילוב ייחודי של המאפיינים האלה, Cloud SQL מטיל מגבלת קצב נפרדת.
Cloud SQL Admin API יוצר מדדים מפורטים שיכולים לעזור לכם לעקוב אחרי השימוש ב-API, לעקוב אחרי הביצועים של מכונת Cloud SQL ושל ה-API, ולגלות בעיות בין המכונה לבין ה-API. מידע נוסף מופיע במאמר מעקב אחר השימוש ב-API.
בטבלה הבאה מפורטים המדד, ממשקי ה-API והמגבלה שמוגדרת כברירת מחדל לכל קטגוריה:
| קטגוריה | מדד | ממשקי API | מכסת ברירת מחדל |
|---|---|---|---|
| חיבור |
מספר הבקשות שכל משתמש יכול לשלוח לדקה לכל אזור כדי להשתמש בממשקי ה-API בקטגוריה הזו. |
1000 | |
| קבל |
מספר הבקשות שמוגשות לדקה לכל משתמש בכל אזור כדי להשתמש בממשקי ה-API בקטגוריה הזו. |
500 | |
| רשימה |
מספר הבקשות שמוגשות לדקה לכל משתמש בכל אזור כדי להשתמש בממשקי ה-API בקטגוריה הזו. |
500 | |
| שינוי |
מספר הבקשות שמוגשות לדקה לכל משתמש בכל אזור כדי להשתמש בממשקי ה-API בקטגוריה הזו. |
|
180 |
| ברירת מחדל לפי אזור |
מספר הבקשות האזוריות שמוגדרות כברירת מחדל שמתבצעות לדקה לכל משתמש בכל אזור כדי להשתמש בממשקי ה-API בקטגוריה הזו. |
180 | |
| ברירת מחדל |
מספר בקשות ברירת המחדל שמוגשות לדקה לכל משתמש כדי להשתמש בממשקי ה-API בקטגוריה הזו. |
180 |
מגבלות
יש מגבלות על חלק מהמשאבים ב-Cloud SQL שלא מתחדשים באופן תקופתי ולא מוצגים בדף Quotas (מכסות) במסוף Google Cloud . אפשר להגדיל חלק מהמגבלות, אבל אי אפשר להגדיל מגבלות אחרות.
מגבלות שניתן להגדיר
מופעים לכל פרויקט
המספר המקסימלי של מופעים שאפשר להגדיר בפרויקט יחיד תלוי בארכיטקטורת הרשת של המופעים האלה:
- ארכיטקטורת רשת חדשה של SQL: אפשר להשתמש בעד 1,000 מופעים לכל פרויקט.
- ארכיטקטורת רשת ישנה של SQL: אפשר להשתמש בעד 100 מופעים לכל פרויקט.
- שימוש בשתי הארכיטקטורות: המגבלה תהיה בין 100 ל-1,000, בהתאם לפיזור של המופעים בשתי הארכיטקטורות.
שליחת בקשת תמיכה כדי לבקש הגדלה. רפליקות לקריאה נספרות כמכונות.
מומלץ לפצל את מספר המופעים בין כמה פרויקטים כדי לצמצם את ההסתמכות על בקשות להגדלת המכסה. כך תוכלו להימנע מחסימות פוטנציאליות.
מספר מקסימלי של חיבורים בו-זמניים
אפשר להשתמש בדגל
max_connections כדי להגדיר מגבלת חיבורים.
כשיוצרים מופע של Cloud SQL ל-MySQL, בוחרים סוג מכונה שקובע את כמות הזיכרון. כמות הזיכרון הזמין קובעת את מגבלות החיבור למופע.
כדי לראות את מגבלת החיבורים של המופע, מתחברים למסד הנתונים ומריצים את הפקודה הבאה:
SHOW VARIABLES LIKE "max_connections";
נקודות שחשוב לדעת
השימוש במכסת 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, כדאי לשים לב לנוסחה שלמעלה ולזכור את הדברים הבאים:
המהירות שבה אתם מרחיבים את בסיס הלקוחות שלכם ב-DB
כמה מהר מוסיפים עוד מופעים
שימוש בחשבונות שירות שונים לכל אפליקציה
אימות פרטי ההתחברות למסד נתונים ב-IAM ב-Cloud SQL
לכל מופע יש מכסה של התחברויות לדקה, שכוללת התחברויות מוצלחות ולא מוצלחות. אם חורגים מהמכסה, הכניסות לחשבון לא זמינות באופן זמני. מומלץ להימנע מהתחברות לחשבון בתדירות גבוהה ולהגביל את ההתחברויות באמצעות רשתות מורשות. המכסה לאישור של התחברויות היא 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 עם דיסקים לאחסון מתמיד. פרטים על מאפייני הביצועים של מכונות וירטואליות ספציפיות מופיעים בטבלה maximum sustained IOPS בדף persistent disk performance.
מגבלת טבלה
ב-Cloud SQL ל-MySQL יש מגבלה של 50,000 טבלאות כברירת מחדל, או 500,000 טבלאות למופע אם אתם עומדים בדרישות המינימליות של חומרה עם לפחות 32 ליבות וזיכרון של לפחות 200G. כדי ליהנות מביצועים אופטימליים, מומלץ שמספר הטבלאות במסד נתונים יחיד לא יעלה על 50,000.
הסכם ה-SLA לא חל על מקרים שבהם חורגים מהמגבלות האלה. כשגודל הטבלה מגיע ל-16TB, הגודל המקסימלי למחיצות לינוקס, אי אפשר להוסיף נתונים נוספים.
הזיכרון שנדרש למופע תלוי בגורמים שונים. מידע נוסף על השימוש בזיכרון ב-Cloud SQL ל-MySQL זמין במאמר איך MySQL משתמש בזיכרון.
אם מספר הטבלאות הפעילות גדול יותר מהערכים שמוגדרים כברירת מחדל ב-Cloud SQL, או אם גודל המטמון הכולל גדול באופן משמעותי, צריך לבצע שינויים במופע. כדי לשמור על ביצועים אופטימליים, אפשר:
- כדי לקבל אפשרויות זיכרון גדולות יותר, אפשר לשדרג ל-Cloud SQL Enterprise Plus edition.
- משדרגים את מכונת Cloud SQL כדי להוסיף זיכרון למכונה.
- צריך להקטין את הערך של הדגל של מסד הנתונים
innodb_buffer_pool_size.
אפשר להשתמש בדגלים table_open_cache ו-table_definition_cache כדי לשנות את מטמון הטבלאות של Cloud SQL ל-MySQL.
אתם יכולים להשתמש בסכימת הביצועים כדי לקבל הערכה של גודל מטמון הטבלה עבור המופע שלכם.
אם מספר הטבלאות הפעילות גדול משמעותית ממספר ברירת המחדל של הטבלאות ב-Cloud SQL ומההמלצה של MySQL לגבי טבלאות פתוחות, Cloud SQL ממליץ להגדיר את דגלי מסד הנתונים table_open_cache ו-table_definition_cache עם מספר הטבלאות הפעילות במכונה.
מידע נוסף זמין במאמר איך MySQL פותח וסוגר טבלאות.
מגבלת פעולות
סוגי מכונות ברמה מיקרו וברמה קטנה מגבילים את מספר הפעולות המקבילות.
חריגה מהמגבלות האלה גורמת לשגיאה Too many operations.
המכסה של סוג המכונה db-custom-1-3840 (מעבד יחיד) הוא 50 פעולות בו-זמניות.
המגבלה של סוג המכונה f1-micro (מעבד עם ליבת מעבד משותפת) היא 20 פעולות בו-זמניות.מגבלות האחסון ב-Cloud SQL
- ליבה ייעודית: עד 64TB.
מידע נוסף זמין במאמר תמחור של מעבד וזיכרון.
- ליבה משותפת: עד 3TB.
מידע נוסף זמין במאמר תמחור של מכונות VM.
אפשרויות אחסון ב-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 SQL מוגבל ל-100 מופעי קונטיינר ב-Cloud Run.
לכל מופע של שירות או משימה ב-Cloud Run יכולים להיות 100 חיבורים למסד הנתונים, וככל שהשירות או המשימה האלה גדלים, המספר הכולל של החיבורים לכל פריסה יכול לגדול.
המגבלה הזו לא חלה כשמשתמשים בשיטות חיבור אחרות, כמו שרת proxy ל-Cloud SQL Auth ב-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.
מידע נוסף זמין במאמר תמחור של מכונות VM.
אפשרויות אחסון ב-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 SQL מוגבל ל-100 מופעי קונטיינר ב-Cloud Run.
לכל מופע של שירות או משימה ב-Cloud Run יכולים להיות 100 חיבורים למסד הנתונים, וככל שהשירות או המשימה האלה גדלים, המספר הכולל של החיבורים לכל פריסה יכול לגדול.
המגבלה הזו לא חלה כשמשתמשים בשיטות חיבור אחרות, כמו שרת proxy ל-Cloud SQL Auth ב-sidecar, מחברי שפות ל-Cloud SQL או כשמתחברים ישירות לכתובת ה-IP של מופע Cloud SQL.
מגבלות על פונקציות Cloud Run
בפונקציות Cloud Run (דור ראשון), מספר ההפעלות המקבילות מוגבל לאחת לכל מכונה. לעולם לא תהיה סיטואציה שבה מופע יחיד של פונקציה מדור ראשון מעבד שתי בקשות בו-זמנית. ברוב המקרים, נדרש רק חיבור אחד למסד הנתונים.
פונקציות Cloud Run (דור שני) מבוססות על Cloud Run, ויש מגבלה של 100 חיבורים למסד נתונים לכל מופע.