לאחר החלת עדכון זה, עליך להוסיף את דגל המעקב-T8075 כפרמטר אתחול כדי להפוך שינוי זה לזמין.
תופעות
בעת הפעלת שאילתה בגירסת 64 סיביות של Microsoft SQL Server 2012, אתה מקבל הודעת שגיאה מחוץ לזיכרון הדומה להודעה הבאה ביומן השגיאות של SQL Server:
עמודי הקצאה שנכשלו: FAIL_PAGE_ALLOCATION 513
שאילתות נמשכות זמן רב כדי לסיים את הביצוע ולהיתקל SOS_MEMORY_TOPLEVELBLOCKALLOCATOR ממתין. כאשר אתה בוחן את נקודות המידע הבאות, תוכל לגלות ששטח הכתובות הווירטואלי הזמין נמוך מאוד:
-
DBCC MEMORYSTATUS-המקטע ' ספירת תהליכים/מערכת '-זיכרון וירטואלי זמין
-
רישוי: virtual_address_space_available_kb sys.dm_os_process_memory עמודה
ערכים אלה מתחילים בסביבות 8 טרה-בתים (TB) בתהליך x64 וממשיכים לרדת למטה ולהגיע לכמה ג'יגה-בתים (GB). כאשר אתה נמצא בשלב שבו מרחב הכתובות הווירטואלי הזמין נמוך מאוד, ייתכן ששאילתות שמנסים לבצע הקצאת זיכרון ייתקלו גם בסוג המתנה של CMEMTHREAD. נקודות הנתונים הבאות ימשיכו להגדיל את הזמן:
-
רישוי: sys.dm_os_process_memory וsys.dm_os_memory_nodes-עמודה virtual_address_space_reserved_kb
-
DBCC MEMORYSTATUS-מנהל הזיכרון מקטע-VM שמור
ערכים אלה יגדלו בדרך כלל בכפולות של ערך "זיכרון שרת מירבי" עד כמעט 8 שחפת.
סיבה
כאשר התהליך של SQL Server הגיע למצב שבו זיכרון השרת הכולל = זיכרון של שרת יעד = memory server memory, קיימים פריטי מדיניות ב-SQL Server memory manager כדי לאפשר להקצאות חדשות לבקש באופן זמני הקצאות מרובות. תבנית הקצאה חוזרת תחת תנאי כזה עלולה לגרום לפיצול של גושי זיכרון וצריכת שטח הכתובות הווירטואליות. אם תהליך זה חוזר על עצמו פעמים רבות, מרחב הכתובות הווירטואלי של SQL Server יהיה מותש, ותבחין בתופעות שהוזכרו מוקדם יותר.
פתרון
מידע אודות עדכון מצטבר
הבעיה נפתרה לראשונה בעדכון המצטבר הבא של SQL Server.
כל עדכון מצטבר חדש עבור SQL Server מכיל את כל התיקונים החמים ואת כל תיקוני האבטחה שנכללו בעדכון המצטבר הקודם. אנו ממליצים להוריד ולהתקין את העדכונים המצטברים האחרונים עבור SQL Server:
תיקון חם זה מונע הן את הזיכרון הקצוב והן את הצמצום המתמשך של שטח הכתובות הווירטואלי הזמין שאתה עשוי להיתקל בו.
מצב
Microsoft אישרה שזוהי בעיה במוצרי Microsoft המופיעים בסעיף "חל על".
מידע נוסף
-
Windows 2012 R2 מאפשר למרחב כתובות וירטואלי לגדול בגודל של 128 TB. לכן, ייתכן שלא תבחין בבעיה זו בסביבות Windows 2012 R2. לקבלת מידע נוסף, עיין בנושא הבא במרכז הפיתוח של Windows:מגבלות זיכרון עבור windows ו-Windows Server מהדורות
-
אם אתה רואה צמיחה רציפה במרחב הכתובות הווירטואלי גם לאחר החלת התיקון, באפשרותך לקבוע אילו שאילתות או פעולות מבקשים מקטעים גדולים של זיכרון באמצעות האירוע Page_allocated ורחב. קובץ script לדוגמה נראה כך:
CREATE EVENT SESSION [memory_tracking] ON SERVERADD EVENT sqlos.page_allocated( ACTION(package0.callstack,sqlos.cpu_id,sqlos.task_address,sqlos.worker_address,sqlserver.database_id,sqlserver.query_hash,sqlserver.request_id,sqlserver.session_id,sqlserver.sql_text) WHERE ([number_pages]>(1)))ADD TARGET package0.event_file(SET filename=N'E:\Data\MSSQL11.MSSQLSERVER\MSSQL\Log\memory_tracking.xel')WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=PER_CPU,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)GO
בדרך כלל אלה הן גיבויים של יומני רישום ופעולות תחזוקה של אינדקס, המתרחשות לעתים קרובות.
