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

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

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

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

גרסת טרום-השקה — AlloyDB Omni

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

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

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

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

כדי להפעיל את התכונות האלה להאצת קלט/פלט, צריך להפעיל את alloydb_omni_atomicGrand 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 מאפשר להימנע מבעיית המאגר הכפול ב-PostgreSQL. ‫PostgreSQL מנהל את מטמון המאגרים שלו ויכול לעקוף את מטמון המאגרים של ליבת מערכת ההפעלה.
‫O_DIRECT מפחית את התקורה של המעבד והזיכרון של המערכת שנדרשים לתחזוקת מטמון המאגר של הליבה.

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

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

קריאות בסטרימינג

‫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 להאטה. יכול להיות שקצב הקריאה יהיה איטי יותר במהלך שחזור מסד הנתונים (נתיב redo), סריקות vacuum וחימום מראש של מטמון הדיסק של Omni.
תכונות ההאצה של קלט/פלט ב-AlloyDB Omni בעותקי קריאה לא נתמכות בגרסת טרום-השקה.
בעומסי עבודה כבדים, יכול להיות שהביצועים של מערכות מבוססות-ARM יהיו נמוכים יותר בגלל הבדלים בארכיטקטורה.
בגלל המגבלות של libaio בעומסי עבודה מוגברים, יכול להיות שמשאבים לא יהיו זמינים. io_uring עלולות להיתקל בבעיות בהקצאת זיכרון כשזיכרון המערכת הזמין נמוך.