בדף הזה מפורטות המכסות והמגבלות של 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 שניות, אתם צריכים לחכות עד שהמכסה הזו תתמלא מחדש לפני שתגישו בקשות נוספות בקטגוריה הזו. אם תחרגו מהמגבלה הזו בפרויקט, תקבלו קוד סטטוס 429 HTTP עם הסיבה rateLimitExceeded.
Cloud SQL Admin API מחולק לקטגוריות הבאות:
- חיבור: חיפוש ערכים שנדרשים לחיבור למסד נתונים של 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 | מגבלת ברירת מחדל |
|---|---|---|---|
| חיבור |
מספר הבקשות שכל משתמש שולח לדקה לכל אזור כדי להשתמש בממשקי ה-API בקטגוריה הזו. |
1000 | |
| קבל |
מספר הבקשות שכל משתמש יכול לשלוח לדקה לכל אזור כדי להשתמש בממשקי ה-API בקטגוריה הזו. |
500 | |
| רשימה |
מספר הבקשות שכל משתמש יכול לשלוח לדקה לכל אזור כדי להשתמש בממשקי ה-API בקטגוריה הזו. |
500 | |
| שינוי |
מספר הבקשות שכל משתמש יכול לשלוח לדקה לכל אזור כדי להשתמש בממשקי ה-API בקטגוריה הזו. |
|
180 |
| ברירת מחדל לכל אזור |
מספר הבקשות האזוריות שמוגדרות כברירת מחדל שמתבצעות לדקה לכל משתמש בכל אזור כדי להשתמש בממשקי ה-API בקטגוריה הזו. |
180 | |
| ברירת מחדל |
מספר בקשות ברירת המחדל שמוגשות לדקה לכל משתמש כדי להשתמש בממשקי ה-API בקטגוריה הזו. |
180 |
מגבלות
יש הגבלות על חלק מהמשאבים של Cloud SQL שלא מתחדשים באופן תקופתי ולא מוצגים בדף Quotas (מכסות) במסוף Google Cloud . אפשר להגדיל חלק מהמגבלות, אבל אי אפשר להגדיל מגבלות אחרות.
מגבלות שניתן להגדיר
Instances per project
המספר המקסימלי של מופעים שאפשר להגדיר בפרויקט יחיד תלוי בארכיטקטורת הרשת של המופעים האלה:
- ארכיטקטורת רשת חדשה של 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, כדאי לשים לב לנוסחה שלמעלה ולזכור את הדברים הבאים:
המהירות שבה אפשר להגדיל את מספר הלקוחות החדשים של מסד הנתונים
כמה מהר מוסיפים עוד מופעים
שימוש בחשבונות שירות שונים לכל אפליקציה
אימות פרטי ההתחברות למסד נתונים ב-IAM ב-Cloud SQL
לכל מופע יש מכסה של התחברויות לדקה, שכוללת התחברויות מוצלחות ולא מוצלחות. אם חורגים מהמכסה, הכניסה לחשבון לא תהיה זמינה באופן זמני. מומלץ להימנע מכניסה לחשבון בתדירות גבוהה ולהגביל את הכניסות באמצעות רשתות מורשות. המכסה לאישור של התחברויות היא 12,000 לדקה, לכל מופע.
מכסת כללי העברה
כל מכונה של Cloud SQL מורכבת מכלל העברה וממאזן עומסים. יש מכסה להגבלת כלל ההעברה, בהתאם לסוג איזון העומסים שאליו הוא מפנה. יש כמה מכסות לכל סוג של כללי העברה, לכל פרויקט, לכל רשת ולכל קבוצת שירותי Peering. בנוסף, יש כלל לביטול מכסות לרשת ולמכסות לקבוצות של רשתות משותפות ב-Cloud SQL. המשמעות היא שכשאנחנו מגדילים את המכסה לכל רשת עבור רשתות של יצרנים, המכסה לכל קבוצת פירינג גדלה גם היא לאותו ערך.
רשת ה-VPC של יצרן Cloud SQL מקושרת לרשת ה-VPC של הלקוח, ולכן אנחנו נתקלים לעיתים קרובות במכסה לכל רשת עבור רשת היצרן של Cloud SQL, ובמכסה לכל קבוצת קישור עבור רשת ה-VPC של הלקוח.
כשהמכסה מגיעה למקסימום, פעולות מסוימות עלולות להיכשל, כולל:
יצירת פעולה: אנחנו צריכים כללי העברה חדשים כשאנחנו יוצרים מופעים חדשים.
עדכון פעולה: אנחנו מאפשרים ללקוחות להחליף את הרשת של המופעים, ולכן אנחנו צריכים כללי העברה חדשים ברשת החדשה.
פעולת תחזוקה: כללי ההעברה נוצרים מחדש.
כדי להימנע מבעיות, מומלץ להגביל את המספר הכולל של המופעים לכל רשת ל-500 ומטה.
אם נתקלתם בבעיה, אתם יכולים לפתוח בקשת תמיכה, ואנחנו נגדיל את המכסות הרלוונטיות בשבילכם.
מגבלות קבועות
IOPS
IOPS הוא מספר פעולות הקלט/פלט (או פעולות הקריאה/הכתיבה) שהדיסק יכול לעבד בשנייה.
Cloud SQL משתמש במכונות וירטואליות (VM) של Compute Engine עם דיסקים לאחסון מתמיד. פרטים על מאפייני ביצועים ספציפיים של מכונות וירטואליות מופיעים בטבלה IOPS מקסימליים מתמשכים בדף ביצועים של דיסקים קשיחים קבועים.
מגבלת טבלה
ב-Cloud SQL ל-MySQL יש מגבלה של 50,000 טבלאות כברירת מחדל, או 500,000 מכונות אם אתם עומדים בדרישות המינימליות של חומרה עם לפחות 32 ליבות וזיכרון של לפחות 200G. כדי ליהנות מביצועים אופטימליים, מומלץ שמספר הטבלאות במסד נתונים יחיד לא יעלה על 50,000.
מופעים שחורגים מהמגבלות האלה לא נכללים בהסכם רמת השירות. אם הדגל innodb_file_per_table של מסד הנתונים מופעל, וגודל הטבלה מגיע ל-16 TB, הגודל המקסימלי למחיצות של Linux, לא ניתן להוסיף נתונים נוספים.
הזיכרון שנדרש למופע תלוי בגורמים שונים. מידע נוסף על השימוש בזיכרון ב-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.
אתם יכולים להשתמש בסכימת הביצועים כדי לקבל הערכה של גודל מטמון הטבלה עבור המופע שלכם. מידע נוסף זמין במסמכי התיעוד של 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.
מידע נוסף זמין במאמר בנושא תמחור של CPU וזיכרון.
- ליבה משותפת: עד 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 ממופעי קונטיינר של Cloud Run מוגבל ל-100.
לכל מופע של שירות או משימה ב-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.
מידע נוסף זמין במאמר בנושא תמחור של CPU וזיכרון.
- ליבה משותפת: עד 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 ממופעי קונטיינר של Cloud Run מוגבל ל-100.
לכל מופע של שירות או משימה ב-Cloud Run יכולות להיות 100 חיבורים למסד הנתונים, וככל שהשירות או המשימה האלה גדלים, המספר הכולל של החיבורים לכל פריסה יכול לגדול.
המגבלה הזו לא חלה כשמשתמשים בשיטות חיבור אחרות, כמו שרת proxy ל-Cloud SQL Auth ב-sidecar, מחברי שפות ל-Cloud SQL או כשמתחברים ישירות לכתובת ה-IP של מופע Cloud SQL.
מגבלות על פונקציות Cloud Run
פונקציות Cloud Run (דור ראשון) מגבילות את ההרצות המקבילות להרצה אחת לכל מכונה. לעולם לא תהיה סיטואציה שבה מופע יחיד של פונקציה מדור ראשון מעבד שתי בקשות בו-זמנית. ברוב המקרים, נדרש רק חיבור אחד למסד הנתונים.
פונקציות Cloud Run (דור שני) מבוססות על Cloud Run, ויש להן מגבלה של 100 חיבורים למסד נתונים לכל מופע.