בדף הזה מתועדת גרסה 16.13.0 של AlloyDB Omni באמצעות אפשרות הפריסה containers. בוחרים אפשרות פריסה אחרת.

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

שיפור הביצועים של AlloyDB Omni באמצעות האצת קלט/פלט

בוחרים גרסה של מאמרי העזרה:

תצוגה מקדימה ‫— AlloyDB Omni

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

בדף הזה מוסבר איך להפעיל ב-AlloyDB Omni קבוצה של תכונות להאצת קלט/פלט, שיכולות לעזור לכם לשפר את השימוש במשאבי החישוב והקלט/פלט, כדי להריץ עומסי עבודה מהר יותר ולשפר את הביצועים של השאילתות.

התכונות הבאות כלולות:

הגנה מכתיבה שנפרצה
התמיכה של O_DIRECT
קלט/פלט אסינכרוני (AIO)
קריאות בסטרימינג

כדי להפעיל את התכונות האלה להאצת קלט/פלט, צריך להפעיל את alloydb_omni_atomic Grand Unified Configuration (GUC) ולהגדיר את AlloyDB Omni כך שיוכל להשתמש ב-GUC.

תכונות להאצת קלט/פלט

בקטעים הבאים מתוארות תכונות האצת הקלט/פלט שמופעלות על ידי alloydb_omni_atomic GUC.

הגנה מכתיבה שנפרצה

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

תמיכה ב-O_DIRECT

כדי לבצע כתיבה אטומית, צריך תמיכה ב-O_DIRECT. ‫O_DIRECT חל על ספריית הנתונים של PostgreSQL ועל מטמון הדיסק של AlloyDB Omni. מידע נוסף מפורט במאמר שיפור הביצועים של מסד נתונים באמצעות מטמון דיסק.

O_DIRECT מציע גם את היתרונות הבאים:

שימוש ב-O_DIRECT מאפשר לכם להימנע מבעיית ה-double-buffering ב-PostgreSQL. ל-PostgreSQL יש מטמון מאגר משלו, והוא יכול לעקוף את מטמון המאגר של ליבת מערכת ההפעלה.
‫O_DIRECT מפחית את התקורה של המעבד והזיכרון של מערכת ההפעלה שנדרשים כדי לתחזק את מטמון המאגר של הליבה.

קלט/פלט אסינכרוני

ההגדרה alloydb_omni_atomic מספקת יכולות קלט/פלט אסינכרוני (AIO) באמצעות הספריות io_uring ו-libaio. מומלץ להשתמש ב-io_uring כדי להימנע מהמגבלות של הספרייה הישנה יותר, libaio. אם לא מזוהה תמיכה ב-io_uring, ‏AlloyDB Omni חוזר ל-libaio. הגישה הזו מאפשרת להתגבר על אובדן היתרונות של קלט/פלט (I/O) בזיכרון מטמון, כמו קריאה מראש ושילוב כתיבה, והיא גם מבטיחה ניצול מקסימלי של רוחב הפס הזמין של הקלט/פלט (I/O) באחסון הבסיסי המוצע.

קריאה בסטרימינג

‫AlloyDB Omni משתמש בקריאות סטרימינג, בדומה לתכונה של PostgreSQL 17, שמשפרות את הביצועים של סריקות רציפות, ANALYZE ו-pg_prewarm באמצעות קלט/פלט וקטורי לקריאת כמה בלוקים למטמון המאגר. קלט/פלט וקטורי היא שיטה שבה קריאה לפרוצדורה אחת יכולה לאחזר מראש נתונים מכמה מאגרים, מה שמשפר את היעילות על ידי הפחתת החלפות ההקשר והקריאות למערכת.

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

לפני שמתחילים

בודקים את התמיכה במערכת ההפעלה ובמערכת הקבצים.
1. כדי לוודא שהקרנל תומך ב-RWF_ATOMIC, בודקים את גרסת הליבה. בדוגמה הבאה, אתם משתמשים במכונת Ubuntu 24.10 שמריצה את הליבה של Linux 6.14 שתומכת בכתיבות אטומיות.
```
> sudo hostnamectl
 ...
 Operating System: Ubuntu 24.10
      Kernel: Linux 6.14.0-061400rc5-generic
...
```
2. אם הליבה שלכם לא תומכת ב-RWF_ATOMIC, מומלץ לעדכן לגרסת ליבה שתומכת ב-RWF_ATOMIC.

כדי להשתמש בתכונות של AlloyDB Omni להאצת קלט/פלט כדי לבדוק שיפורים בביצועים עם הגנה מכתיבה קרועה, צריך להפעיל את alloydb_omni_atomic Grand Unification Configuration (GUC). כדי להשתמש ב-GUC הזה, צריך ליבה ומערכת קבצים תומכות שמספקות קלט/פלט אטומי ומגנות מפני כתיבות חלקיות.

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

אפשר לשנות את פעולת ברירת המחדל הזו, אבל מומלץ להשתמש בפלטפורמה נתמכת ובאפשרות force כדי להימנע משינוי בטעות של הגדרות אופטימליות.

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

בטבלה הבאה מפורטות הגדרות התצורה של alloydb_omni_atomic ובדיקות התאימות המתאימות.

ערך `alloydb_omni_atomic`	בדיקת תאימות בהפעלה	תיאור
off	לא רלוונטי	הערך הזה משבית את המצב האטומי. התכונה לא פעילה.
force	מבצע בדיקת תאימות בזמן ההפעלה. ההפעלה נכשלת אם הכתיבה של `RWF_ATOMIC` נכשלת.	הגדרות של מצב אטומי.
force_unsafe	לא מבצעת בדיקת תאימות בזמן ההפעלה. מוחזרת אזהרה, אבל התהליך ממשיך אם הכתיבה של `RWF_ATOMIC` נכשלת.	הגדרת תצורות של מצב אטומי.

בהגדרה force/force_unsafe, ההגדרות full_page_writes,‏ io_combine_limit ו-debug_io_direct מוגדרות באופן אוטומטי. אפשר לשנות את ההגדרות האלה באמצעות ההגדרה האופציונלית on/on_unsafe.

הגדרת תכונות להאצת קלט/פלט ב-AlloyDB Omni

מגדירים את מערכת הקבצים XFS לספריית הנתונים. משתמשים ב-XFS כי הוא תומך בגודל בלוק של מערכת קבצים שגדול מגודל הדף. ‫AlloyDB Omni יכול להשתמש ב-XFS כדי לכתוב בלוקים של 8KiB באופן אטומי עם RWF_ATOMICתמיכה מלאה.
1. יוצרים מערכת קבצים מסוג XFS עם גודל בלוק של 8KiB ומחברים אותה למיקום של ספריית הנתונים (DATA_DIR).
```
sudo mkfs.xfs -f -b size=8k /dev/$DEVICE
sudo mount /dev/$DEVICE DATA_DIR
```
  מחליפים את הפרטים הבאים:
  - ‫DATA_DIR: המיקום של ספריית הנתונים.
2. בודקים את יומני הליבה כדי לוודא שנעשה שימוש בבלוקים של 8k:
```
> sudo journalctl -f
...
kernel: XFS (sdc): EXPERIMENTAL large block size feature enabled.  Use at your own risk!
kernel: XFS (sdc): Mounting V5 Filesystem 350aa26a-7555-4566-94c1-74e54ddc9250
...
```
אופציונלי: מגדירים את מטמון הדיסק של AlloyDB Omni.

כדי ליצור מערכת קבצים באמצעות ext4, ואז לטעון אותה, אפשר להשתמש בדוגמה הבאה:
```
sudo /sbin/mkfs.ext4 -m 1 -F -E lazy_itable_init=0,lazy_journal_init=0 /dev/DEVICE
sudo mount --make-shared -o noatime,discard,errors=panic /dev/DEVICE /OMNI_DISK_CACHE_DIRECTORY
```
מחליפים את הפרטים הבאים:
- ‫DEVICE: הישות שאיתה האפליקציה יוצרת אינטראקציה כדי לבצע פעולות קלט/פלט (קריאה או כתיבה של נתונים).
כדי לתמוך בביצועים אופטימליים של תכונות האצת הקלט/פלט של AlloyDB Omni כשהאחסון הראשי לא מציע יותר פעולות קלט/פלט לשנייה (IOPS), מומלץ להגדיר את מטמון הדיסק של AlloyDB Omni. מידע נוסף מופיע במאמר שיפור הביצועים של מסד הנתונים באמצעות מטמון הדיסק.

הערה: מטמון הדיסק לא צריך לתמוך בכתיבה אטומית כי הנתונים במטמון הם זמניים. עם זאת, תכונות האצת הקלט/פלט של AlloyDB Omni עדיין משתמשות ב-O_DIRECT כדי לגשת למטמון.
הורדה והפעלה של AlloyDB Omni.
1. מורידים את קונטיינר Docker העדכני של AlloyDB Omni. מידע נוסף זמין במאמר איך מתקינים את AlloyDB Omni במכונה וירטואלית.
2. כדי להשתמש במטמון הדיסק, פועלים לפי ההוראות במאמר בנושא שיפור ביצועי מסד הנתונים באמצעות מטמון הדיסק.
3. כדי לאפשר את io_uring, צריך להוסיף עוד ארגומנט, --security-opts="seccomp:unconfined"
```
docker run -d --name CONTAINER_NAME \
   -e POSTGRES_PASSWORD=NEW_PASSWORD \
   -v DATA_DIR:/var/lib/postgresql/data \
   -v /OMNI_DISK_CACHE_DIRECTORY:/CACHE_DIRECTORY_PATH_INSIDE_CONTAINER \  # Only if disk cache is enabled
   -p HOST_PORT:5432 \
   --security-opts="seccomp:unconfined" \
   --restart=always \
   google/alloydbomni:16
```
  מחליפים את הפרטים הבאים:
  - ‫CONTAINER_NAME: השם של מאגר AlloyDB Omni במאגר מאגרי התגים של מכונת המארח.
  - ‫NEW_PASSWORD: הסיסמה שהוקצתה למשתמש PostgreSQL של הקונטיינר.
  - ‫DATA_DIR: המיקום של ספריית הנתונים.
  - ‫CACHE_DIRECTORY_PATH_INSIDE_CONTAINER: הנתיב לספריית מטמון הדיסק בתוך הקונטיינר.
  - ‫HOST_PORT: יציאת ה-TCP במחשב המארח שאליה הקונטיינר צריך לפרסם את יציאה 5432 שלו.
הגדרת AlloyDB Omni לשימוש בקלט/פלט אטומי.

מגדירים את ה-GUC של alloydb_omni_atomic לערך מתאים ומפעילים מחדש את הקונטיינר.
```
alter system set alloydb_omni_atomic='force';
sudo docker restart CONTAINER_NAME;
```
מחליפים את הפרטים הבאים:
- ‫CONTAINER_NAME: השם של מאגר AlloyDB Omni במרשם המאגרים של המחשב המארח.

מגבלות

‫PostgreSQL 16 מכיל נתיבים שמבצעים קלט/פלט של בלוק יחיד, מה שמאט את O_DIRECT. יכול להיות שפעולות הקריאה יהיו איטיות יותר במהלך שחזור מסד הנתונים (נתיב ביצוע מחדש), סריקות ואקום וחימום מראש של מטמון הדיסק של Omni.
תכונות האצת קלט/פלט של AlloyDB Omni ברפליקות לקריאה בלבד לא נתמכות בגרסת טרום-השקה.
בעומסי עבודה כבדים, יכול להיות שהביצועים של מערכות מבוססות-ARM יהיו נמוכים יותר בגלל הבדלים בארכיטקטורה.
בגלל המגבלות של libaio בעומסי עבודה מוגברים, יכול להיות שמשאבים לא יהיו זמינים. יכול להיות שיהיו בעיות בהקצאת הזיכרון ב-io_uring כשזיכרון המערכת הזמין עומד להיגמר.