Pagefile על Radmisk, וכונני ram (ע"י תוכנה) בכלליות...

[smalul]

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

עכשו, נגיד והפעלת WORD. היישום הזה מקבל מקום ב RAM כדי שיוכל לעבוד מהר, כי הוא היישום הפעיל. עכשו הפעלת יישום שני - EXCEL, והוא עכשו היישום הפעיל. מה קורה לזיכרון שבשימוש תוכנת ה WORD? הוא עובר לזיכרון הוירטואלי. אני מניח שקודם כל הזיכרון האמיתי - ה RAM, מתמלא ואז אם נגמר בו המקום, הדיסק הקשיח (או ה swap file/page file) מתחיל להתמלא (אני לא חושב שהיישום "יודע" אם הוא יושב ב RAM או בדיסק הקשיח, אלא פשוט שהוא נמצא בזיכרון הוירטואלי). כאשר חוזרים ל WORD, ה EXCEL מועבר מה RAM ו"מאוחסן" בזיכרון הוירטואלי, וה WORD מוצא מהזיכרון הוירטואלי ועובר לזיכרון האמיתי. אם יש מספיק זיכרון אמיתי (RAM), התהליך הזה יהיה דיי מהיר. אבל אם אין מספיק RAM, הדיסק הקשיח נכנס לשימוש והתהליך יהיה הרבה יותר איטי (בגלל שהדיסק הקשיח הוא איטי יחסית לזיכרון).

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

לדעתי, כל עוד יש לך מספיק מקום ב RAM כדי להפעיל את היישומים שלך, וגם לבצע את ה"החלפות" בינהם, אז לא ממש נעשה שימוש בדיסק הקשיח כזיכרון חלופי. הקטנת ה RAM שלך תביא להגברת השימוש בזיכרון הוירטואלי, שכמעט בוודאות יהיה איטי יותר (גם כל התהליך הזה של ההחלפות, גם שימוש בדיסק הקשיח וכו'), ולכן שימוש ב RAM ככונן RAM לצורך אחסנת קובץ ה SWAP יוביל להורדה בביצועים.

[habarbash]

מה שקורה זה שאפי' והRAM לא מתמלא אז עוברים קבצים לSWAP .

ומה שהתוכנה עושה זה שהקבצים שהיו אמורים לעבור ל SWAP שהוא בHD , עוברים לRAM ( שהוקצא ע"י התוכנה ל SWAP ) .

למעשה התוכנה טובה במקרים שאין עומס על הRAM, אז הRAM מעביר מידה לRAM בעצם ( כי התוכנה מקצה חלק ממנו ל SWAP ) , אבל בממקרה שיש עומס על ה RAM אז אתה בעצם מוריד ביצועים כי במקום לדוג' 1G יש לך רק 900M , והקבצים שאמורים להיות עכשיו ב HD (SWAP) שהם בעצם פחות חשובים כרגע , תופסים מקום לקבצים יותר חשובים .

[LiorP23]

אבל זה הקטע

שכשאתה מקצה לתוכנה מקום אתה גורם למחשב לגשת ל-Page File יותר מוקדם

[habarbash]

לא בדיוק , המחשב נגש ל PF גם אם הRAM לא מלא .

[bla7]

אני מניח שקודם כל הזיכרון האמיתי - ה RAM, מתמלא ואז אם נגמר בו המקום, הדיסק הקשיח (או ה swap file/page file) מתחיל להתמלא

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

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

[AppleJack]

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

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

תודה לך

כבר התחלתי לזלזל בעצמי...

הפתרון כנראה יעיל כל עוד (לפחות) רוב הזמן יש לך כמות מכובדת של זכרון שלא בשימוש.

ובמקרה הגרוע בזבזת חלק מסויים מכלל הזכרון שהקצית ל-VM , וה-HD יתחיל להבין שגם הוא חלק מהעניין

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

בכל מקרה, אם התאוריה נכונה או לא, רק מבחן מעשי יוכל לגלות. לא יהיה קל לערוך השוואה שכזאת (ramdisk+hd vs. hd),

או לפחות להציג את התוצאות בצורה הוגנת.

אולי חיווי של פעולות ה-HD, מעקב אחר זמני טעינה , סגירה-פתיחה \ מיזעור-הגדלה של יישומים. (בעבודה ממושכת)

לעומת זאת, בהשוואה לקונפיגורציה של אי שימוש ב-pagefile בכלל (ramdisk+hd vs. none), ההשוואה נוגעת יותר ליציבות מערכת אל מול זכרון מקסימלי פנוי. עניין של העדפה אישית.

עריכה:

מצאתי שכבר התעניינו בעניין הזה עוד לפני 3 שנים... לפחות הבחור הזה:

Ramdisk pagefile plus harddisk pagefile works!

« on: Mar 30th, 2003, 7:01am »

In my continuing effort to tweak,

I wanted to see if I could have the best of both worlds,

by having a ramdisk pagefile and a harddisk pagefile.

The idea being that if Windows starts to page,

it'll first use the smaller ramdisk pagefile,

and should that fill up, start using the harddisk pagefile.

I had read somewhere that Windows will use the faster one first before it uses the slower one.

And that is indeed what happens! I

confirmed it by using Performance Monitor to watch the percent usage of both pagefiles

individually. So I now have a system that has no danger of running out of VM,

and during my normal usage will just use the ramdisk pagefile,

but should I need to do some very RAM intensive stuff,

will still be able to (with a slowdown of course).

On my machine with 2 GB on the motherboard,

I have /MAXMEM:1520 in the boot.ini (so the OS sees 1520 MB),

a ramdisk size of 519 MB and a pagefile on the ramdisk of 514 MB.

My C drive has a 3000 MB pagefile.

My numbers don't add up to 2048 MB (adds up to 2039) because in testing,

I discovered a small fudge factor is necessary for some reason.

The motherboard seems to gives the OS only 2043 MB for some reason..

no big deal, just one of those things that make you go hmmmm..

-------

A side note- After running this for three days with no reboot,

and a commit charge running between 500 to 800 MB,

I'm showing a RamDisk_PF usage of 18.59% (512 MB pagefile) and a

harddisk pagefile usage of .891% (3000 MB pagefile),

so Windows does indeed mostly use the faster RamDisk_PF. The system has been fast and stable