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

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

בדף הזה מוסבר איך להפעיל ב-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 מאפשר לכם להימנע מבעיית ה-double-buffering ב-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. בודקים את התמיכה במערכת ההפעלה ובמערכת הקבצים.

    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.

  2. כדי להשתמש בתכונות של 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

  1. מגדירים את מערכת הקבצים 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
...

  2. אופציונלי: מגדירים את מטמון הדיסק של 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. מידע נוסף מפורט במאמר שיפור הביצועים של מסד נתונים באמצעות מטמון דיסק.

  3. מורידים ומריצים את 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.

  4. מגדירים את 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 עלולות להיתקל בבעיות בהקצאת זיכרון כשזיכרון המערכת הזמין נמוך.