05-03-2014, 20:04
|
|
|
|
חבר מתאריך: 14.12.09
הודעות: 9,751
|
|
ציטוט:
במקור נכתב על ידי Big Joe
לפעמים רק אחרי שהוא מקבל תשובות, קולט הבן-אדם כמה טובה הייתה השאלה...
|
השאלה הייתה לא רק טובה אלא אפילו מצוינת. עד דצמבר 2008. עכשיו זה סתם ישן ואפילו משעמם.
ציטוט:
במקור נכתב על ידי Big Joe
מיקרוסופט כמובן מבלבלים את המוח. הם לא רוצים להמליץ, אז הם מלעיטים בהסברים...
|
מיקרוסופט נותנים המלצה. ההמלצה שלהם היא גם זו שנמצאת בשימוש בהתקנה נקייה של המערכת.
רואה איפה שכתוב "Automatically manage paging file for all drives"? זו ההמלצה. פשוט מאוד.
אתה אולי חושב שאתה נורא חכם או נורא מיוחד ולכן התרחיש הכללי והבסיסי זה לא מתאים לך. בסדר בשביל זה יש הסבר מה צריך לעשות:
How Big Should I Make the Paging File?
Perhaps one of the most commonly asked questions related to virtual memory is, how big
should I make the paging file? There’s no end of ridiculous advice out on the web and in the
newsstand magazines that cover Windows, and even Microsoft has published misleading
recommendations. Almost all the suggestions are based on multiplying RAM size by some
factor, with common values being 1.2, 1.5 and 2. Now that you understand the role that the
paging file plays in defining a system’s commit limit and how processes contribute to the
commit charge, you’re well positioned to see how useless such formulas truly are.
Since the commit limit sets an upper bound on how much private and pagefile-backed virtual
memory can be allocated concurrently by running processes, the only way to reasonably size
the paging file is to know the maximum total commit charge for the programs you like to have
running at the same time. If the commit limit is smaller than that number, your programs won’t
be able to allocate the virtual memory they want and will fail to run properly.
So how do you know how much commit charge your workloads require? You might have
noticed in the screenshots that Windows tracks that number and Process Explorer shows it:
Peak Commit Charge. To optimally size your paging file you should start all the applications
you run at the same time, load typical data sets, and then note the commit charge peak (or
look at this value after a period of time where you know maximum load was attained). Set the
paging file minimum to be that value minus the amount of RAM in your system (if the value is
negative, pick a minimum size to permit the kind of crash dump you are configured for). If you
want to have some breathing room for potentially large commit demands, set the maximum to
double that number.
Some feel having no paging file results in better performance, but in general, having a paging
file means Windows can write pages on the modified list (which represent pages that aren’t
being accessed actively but have not been saved to disk) out to the paging file, thus making
that memory available for more useful purposes (processes or file cache). So while there may
be some workloads that perform better with no paging file, in general having one will mean
more usable memory being available to the system (never mind that Windows won’t be able
to write kernel crash dumps without a paging file sized large enough to hold them).
הדברים הנ"ל נלקחו מסוף הפוסט Pushing the Limits of Windows: Virtual Memory של מארק רוסינוביץ'.
אתה מוזמן לקרוא את כל הפוסט (ואפילו את כל סדרת הפוסטים!) אם אתה כל-כך להוט לקבל המלצות מבוססות ולהבין את הבסיס של ההמלצות. אני בטוח שתהנה וזה בכלל לא יהיה בזבוז זמן.
_____________________________________
(קרדיט למרשי)
אמר לה ינאי מלכא לדביתיה אל תתיראי מן הפרושין ולא ממי שאינן פרושין אלא מן הצבועין שדומין לפרושין שמעשיהן כמעשה זמרי ומבקשין שכר כפנחס
אמר פסטן: שניהם גרועים, אבל עדיף להיות טיפש מאשר שקרן.
|