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

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

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

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

‫AlloyDB Omni משתמש בקריאות של נתונים בזמן אמת, שמשפרות את הביצועים של סריקות רציפות, 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 נבדקת במהלך ההפעלה. ההפעלה של PostgreSQL נכשלת אם אי אפשר לאשר כתיבות אטומיות עם הדגל RWF_ATOMIC.

אפשר לשנות את פעולת ברירת המחדל הזו, אבל מומלץ להשתמש בפלטפורמה נתמכת ובאפשרות 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:17
```
  מחליפים את הפרטים הבאים:
  - ‫CONTAINER_NAME: השם של מאגר AlloyDB Omni במרשם המאגרים של המחשב המארח.
  - ‫NEW_PASSWORD: הסיסמה שהוקצתה למשתמש PostgreSQL של הקונטיינר.
  - ‫DATA_DIR: המיקום של ספריית הנתונים.
  - ‫CACHE_DIRECTORY_PATH_INSIDE_CONTAINER: הנתיב של ספריית מטמון הדיסק בתוך הקונטיינר.
  - ‫HOST_PORT: פוסט ה-TCP במכונת המארח שאליו הקונטיינר צריך לפרסם את הפורט שלו 5432.
הגדרת AlloyDB Omni לשימוש בקלט/פלט אטומי.

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

מגבלות

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