שיקולי ביצועים

בדף הזה מוסבר איך להגדיר את סביבת Parallelstore כדי להשיג את הביצועים הכי טובים.

המלצות כלליות

• כדי לשפר את ביצועי ברירת המחדל, מסירים את כל הכינויים מ-ls. במערכות רבות, הפקודה הזו היא כינוי ל-ls -color=auto, שהיא איטית הרבה יותר עם הגדרת ברירת המחדל של Parallelstore.

• אם הביצועים של פעולות ברשימה איטיים, כדאי להפעיל שמירה במטמון עבור dfuse mount.

ספריית Interception

אפשר להשתמש בספרייה libioil כדי לשפר את הביצועים של פעולות קריאה וכתיבה ב-DFuse מאפליקציות שמשתמשות ב-libc. הספרייה עוקפת את ליבת המערכת על ידי יירוט של קריאות קריאה וכתיבה של POSIX מהאפליקציה, כדי לטפל בהן ישירות במרחב המשתמש. פרטים נוספים זמינים במאמר בנושא ספריית יירוט.

ברוב המקרים, מומלץ להשתמש בספריית היירוט בכל הפעלה של תהליך או אפליקציה.

דוגמאות למצבים שבהם לא כדאי או לא צריך להשתמש בספריית היירוט:

• רק אפליקציות שנבנו באמצעות libc יכולות להשתמש בספריית היירוט.
• אם יש לכם עומס עבודה שמרוויח משימוש במטמון, כמו גישה חוזרת לאותם קבצים, מומלץ לא להשתמש בספריית היירוט.
• אם עומס העבודה שלכם כולל הרבה מטא נתונים, למשל אם אתם עובדים עם הרבה קבצים קטנים או עם רשימת ספריות גדולה מאוד, סביר להניח שספריית היירוט לא תשפר את הביצועים.

אפשר להגדיר את ההפעלה של LD_PRELOAD כמשתנה סביבה בסביבת מעטפת, אבל לפעמים זה עלול לגרום לבעיות. במקום זאת, מומלץ לציין אותו בכל פקודה.

אפשרות אחרת היא לקשר את ספריית היירוט לאפליקציה בזמן ההידור באמצעות הדגל -lioil.

dfuse שמירה במטמון

האפשרות 'שמירה במטמון' מופעלת ב-dfuse כברירת מחדל.

יש שני דגלים שקשורים למטמון שמשמשים את dfuse כשמפעילים מופע Parallelstore:

• ‫--disable-wb-cache משתמש בשיטת write-through במקום בשיטת write-back לניהול מטמון.
• ‫--disable-caching משבית את כל אפשרויות השמירה במטמון.

ההצעות הבאות רלוונטיות לשיפור הביצועים ולשמירת נתונים במטמון:

• אם אתם משתמשים בספריית היירוט, המערכת מדלגת על שמירת נתונים במטמון. מומלץ לציין --disable-wb-cache כשמשתמשים בספריית היירוט.
• אם עומס העבודה שלכם כולל קריאה של הרבה קבצים פעם אחת, כדאי להשבית את השמירה במטמון.
• עבור עומסי עבודה שכוללים הרבה לקוחות שמשנים קבצים, והעדכונים צריכים להיות זמינים מיד ללקוחות אחרים, צריך להשבית את השמירה במטמון.
• אם עומס העבודה כולל קריאה חוזרת של אותם קבצים, שמירת נתונים במטמון יכולה לשפר את הביצועים. זה נכון במיוחד אם הקבצים מתאימים לזיכרון של הלקוחות שלכם. ‫dfuse משתמש במטמון הדפים של Linux לצורך שמירת נתונים במטמון.

• עבור עומסי עבודה שכוללים קלט/פלט קטן לקבצים גדולים, בנוסף להפעלת שמירת נתונים במטמון, יכול להיות שיהיה יתרון להגדלת קריאת ה-dfuse מראש. כדי להגדיל את dfuse read-ahead, אחרי ש-dfuse נטען, מריצים את הפקודות הבאות:

  echo 4096 > /sys/class/bdi/\$(mountpoint -d /mnt)/read_ahead_kb
  echo 100 > /sys/class/bdi/\$(mountpoint -d /mnt)/max_ratio
  

אם עומסי העבודה שלכם כוללים שילוב של התרחישים הקודמים, אתם יכולים לצרף את אותו מופע Parallelstore לכמה נקודות צירוף עם הגדרות שונות של שמירת נתונים במטמון.

מספר השרשורים ומספר התורים של האירועים

כשמפעילים את מופע Parallelstore, מומלץ להשתמש בערכים הבאים לפרמטרים --thread-count ו---eq-count:

• ערך ספירת השרשורים לא יכול להיות גדול ממספר ליבות ה-vCPU.
• הערך המקסימלי המומלץ של מספר השרשורים הוא בין 16 ל-20. מעבר למספר הזה, אין שיפור בביצועים, לא משנה כמה ליבות זמינות.
• הערך של תור האירועים צריך להיות חצי מהערך של מספר השרשורים.

אם עומס העבודה כולל מספר גבוה מאוד של פעולות על קבצים קטנים וגישה רבה למטא-נתונים, אפשר לנסות להגדיל את המספרים מעבר להמלצות האלה.

הגדרה של חלוקת קבצים

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

כשיוצרים את מופע Parallelstore, אפשר לציין אחת משלוש הגדרות של חלוקת קבצים:

• מינימום
• מאוזן
• מקסימום

להגדרות האלה יכולה להיות השפעה משמעותית על הביצועים של חנות Parallelstore. לרוב עומסי העבודה, מומלץ להשתמש בהגדרה 'מאוזן', שהיא פשרה סבירה לרוב עומסי העבודה. אם הביצועים עם ההגדרה 'מאוזן' לא מספיק טובים:

• ההגדרה המינימלית עשויה לשפר את הביצועים בעומסי עבודה עם הרבה קבצים קטנים, במיוחד כשהגודל הממוצע של הקבצים קטן מ-256KB.

• ההגדרה המקסימלית עשויה לשפר את הביצועים בעומסי עבודה עם קבצים גדולים מאוד, בדרך כלל גדולים מ-8GB, במיוחד כשלקוחות רבים משתפים גישה לאותם קבצים.

לצורך כוונון מתקדם, הכלי daos מספק הגדרות לכל קובץ או לכל ספרייה. ניסויים בהתאמות מתקדמות כרוכים בסיכונים שקשורים לביצועים, ולכן בדרך כלל לא מומלץ לבצע אותם. פרטים נוספים זמינים במאמר הסבר על יתירות נתונים וחלוקת נתונים ב-DAOS.

הגדרת פס בספרייה

כשיוצרים את מופע Parallelstore, אפשר לציין אחת משלוש הגדרות של חלוקת ספריות:

• מינימום
• מאוזן
• מקסימום

לרוב עומסי העבודה, מומלץ להשתמש בהגדרה המקסימלית.

עבור עומסי עבודה שכוללים הרבה רישומים של ספריות גדולות, ההגדרות המאוזנות או המינימליות יכולות לשפר את הביצועים של הרשימה. עם זאת, הביצועים של פעולות אחרות, במיוחד יצירת קבצים, עלולים להיפגע.

משתמשים מרובים

כשמשתמשים בכלי dfuse כדי לטעון את מופע Parallelstore, מומלץ לציין את הדגל --multi-user. הדגל הזה אומר לליבה להפוך את מערכת הקבצים לזמינה לכל המשתמשים בלקוח, ולא רק למשתמש שמריץ את תהליך DFuse. אחרי כן, DFuse יופיע כמערכת קבצים כללית למשתמשים מרובים, והקריאות הסטנדרטיות chown ו-chgrp יופעלו. הבעלות על כל הרשומות במערכת הקבצים היא של המשתמש שיצר אותן, כמו שקורה בדרך כלל במערכת קבצים של POSIX.

כשמציינים את הדגל --multi-user, צריך גם לעדכן את /etc/fuse.conf כמשתמש root על ידי הוספת השורה הבאה:

user_allow_other

לא נראה שיש השלכות על הביצועים כשמפעילים את המופע כמשתמשים רבים.

הגדרה של קידוד מחיקה

קידוד המחיקה מוגדר כ-2+1. ולא ניתן לשנות את ההגדרה הזו. כל קלט/פלט שלא משתמש ב-EC2+1 נדחה.

הקצאת משאבים לקונטיינר sidecar ב-Google Kubernetes Engine

ברוב המקרים, ביצועים לא מספקים ב-Google Kubernetes Engine וב-Parallelstore נובעים ממספר ליבות CPU או מנפח זיכרון לא מספיקים שהוקצו לקונטיינר של Parallelstore sidecar. כדי להקצות משאבים בצורה נכונה, כדאי לפעול לפי ההצעות הבאות:

• קוראים את השיקולים שמודגשים במאמר בנושא הגדרת משאבים עבור קונטיינר sidecar. במאמר הזה נסביר למה לפעמים צריך להגדיל את הקצאת המשאבים, ואיך מגדירים את הקצאת המשאבים של קונטיינר ה-sidecar באמצעות הערות Pod.

• אפשר להשתמש בערך 0 כדי להשבית את כל מגבלות המשאבים או הבקשות באשכולות רגילים. לדוגמה, אם מגדירים את gke-parallelstore/cpu-limit: 0 ואת gke-parallelstore/memory-limit: 0, מגבלות המעבד (CPU) והזיכרון של קונטיינר ה-sidecar יהיו ריקות, והבקשות שמוגדרות כברירת מחדל ישמשו. ההגדרה הזו שימושית כשאתם לא יודעים כמה משאבים נדרשים ל-dfuse עבור עומסי העבודה שלכם, ואתם רוצים שהוא ישתמש בכל המשאבים שזמינים בצומת. אחרי שמבינים כמה משאבים נדרשים ל-dfuse על סמך מדדי עומס העבודה, אפשר להגדיר מגבלות מתאימות.

• ב-Autopilot clusters, אי אפשר להשתמש בערך 0 כדי לבטל את ההגדרה של מגבלות ודרישות המשאבים של קונטיינר ה-sidecar. צריך להגדיר במפורש מגבלת משאבים גדולה יותר עבור קונטיינר ה-sidecar באשכולות Autopilot, ולהסתמך על מדדים כדי להחליט אם יש צורך להגדיל את מגבלת המשאבים. Google Cloud