הגדרות של Planner/Optimizer

ראשי פורומים פיתוח הגדרות של Planner/Optimizer

הדיון הזה מכיל 0 תגובות, ויש לו משתתף 1, והוא עודכן לאחרונה ע״י  vrqv2 לפני 6 חודשים, 1 שבוע.

מוצגות 1 תגובות (מתוך 1 סה״כ)
  • מאת
    תגובות
  • #224

    vrqv2
    מנהל בפורום

    ההתאמות הבאות מאפשרות לPlanner להעריך נכון את הערך של פעולות שונות ולבחור את תכנית הביצוע הטובה ביותר עבור שאילתות.

    ישנם 3 הגדרות מתזמנות, שכדאי לשים לב:

    default_statistics_target
    פרמטר זה מציין את כמות הנתונים הסטטיסטיים שנאספת על ידי הפקודה ANALYZE. הגדלת הפרמטר תגרום למערכת לעבוד יותר, אך היא יכולה לאפשר לבנות תכניות מהירות יותר, ע"י שימוש במידע הנוסף שהתקבל. נתונים סטטיסטיים עבור שדה אפשר להגיד ע"י ALTER TABLE … SET STATISTICS.

    effective_cache_size
    פרמטר זה מעביר את הנפח המשוער של ​​מטמון קבצים במערכת ההפעלה ל PostgreSQL, ה Planner משתמש בערך זה לבניית תכנית השאילתה.

    על שרת ייעודי ניתן להגדיר את הפרמטר כי ⅔ מ RAM הכולל; בשרת עם יישומים אחרים קודם כל מחסירים מה RAM את מטמון מערכת ההפעלה וזיכרון התפוש ע"י תהליכים אחרים בשרת.

    random_page_cost
    משתנה המראה את הערך הנקוב של הגישה אינדקסית לדפי הנתונים.

    בשרתים עם מערכי דיסקים מהרים ניתן להפחית את ההגדרה הראשונית עד ל 3.0, 2.5 או אפילו עד ל 2.0.

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

    אפשר לגשת לבחירת ערך הפרמטר האופטימלי גם מצד של אופטימיזציה של השאילתות.

    אם מתכנן השאילתה לעתים קרובות יותר ממה שצריך, מעדיף סריקות רציפות (sequential scans) מאשר שימוש באינדקס (index scans), תוריד את הערך.

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

    לאחר השינויים צריך לבדוק את התוצאות על הסט הרחב ככל האפשר של שאילתות.

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

    עבור הגדרות האוטומטית של כמה פרמטרים, אתה יכול להשתמש ב pgtune.

    כדי לייעל את ההגדרות עבור PostgreSQL גרגורי סמית יצר שירות pgtune בחישוב כדי להבטיח את הביצועים הטובים ביותר עבור תצורת חומרה נתונה.

    השירות הוא קל לשימוש ובמערכות לינוקס רבות יכול ללכת כחלק מחבילה. יש גם גרסה מקוונת של pgtune.

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

    – full_page_writes, תבחר באפשרות off, אם fsync = off. אחרת, כאשר on נבחר, PostgreSQL כותב את התוכן של כל רשומה ביומן בשינוי הראשון של הטבלה. זה נחוץ משום שהנתונים עשויים להיות שמורים באופן חלקי בלבד, אם בזמן התהליך נפלה מערכת ההפעלה. זה יגרום שבדיסק יהיה מידע חדש מעורבב עם הישן. רישום ביומן יכול להיות לא מספיק על מנת לשחזר את הנתונים באופן מלא לאחר נפילת מערכת ההפעלה. full_page_writes מבטיח התאוששות בצורה נכונה, ע"י עלייה בכמות הנתונים שייכתבו ביומן (הדרך היחידה להפחית את כמות הנתונים ביומן היא להגדיל checkpoint_interval).

    – wal_buffers, כמות הזיכרון בשימוש בזיכרון המשותף לתחזוקת לוגים של הטרנזקציות. זה הכרחי להגדיל את המאגר עד ל 256-512 KB, אשר יטיב בעבודה עם טרנזקציות גדולות. לדוגמא, כאשר הזיכרון הזמין הוא 1-4 GB מומלץ להגדיר KB 256-1024.

    • הדיון הזה עודכן לפני 6 חודשים, 1 שבוע ע״י vrqv2.
מוצגות 1 תגובות (מתוך 1 סה״כ)

יש להתחבר למערכת על מנת להגיב.

מדיניות הפרטיות
כל הזכויות שמורות ל © העמותה לקידום הפוטגרס בישראל 2018