Pushing the Limits of Windows
Published byBeverley Day Modified over 5 years ago
Similar presentations
Presentation on theme: «Pushing the Limits of Windows»— Presentation transcript:
2 Pushing the Limits of Windows
Mark Russinovich Technical Fellow Microsoft Corporation Session Code: CLI402 *Portions derived from David Solomon’s Windows Internals Seminar
3 About Me Technical Fellow, Microsoft
Co-founder and Chief Software Architect of Winternals Software Co-author of Windows Internals 4th and 5th Edition and Inside Windows rd Edition with David Solomon Author of TechNet Sysinternals Home of blog and forums Contributing Editor TechNet Magazine, Windows IT Pro Magazine Ph.D. in Computer Engineering
4 Pushing the Limits Resource exhaustion is obviously not a good thing
At the minimum it causes service outage At worst it can cause data loss or even corruption As a Windows systems administrator you need to know the limits For capacity planning For systems monitoring This session explains core Windows kernel limits, where they come from, and how to monitor them I’ll use Sysinternals Testlimit and Notmyfault to stress resources:
5 Outline Virtual Memory Physical Memory Paged and Nonpaged Pool
Processes and Threads Handles
6 Address Space Limits One virtual memory limit is address space
Process can run out of space to allocate virtual memory Typically only an issue for 32-bit processes Use Testlimit -r (reserve memory) to see address space exhaustion: Process Explorer Virtual Size shows amount of address space used
7 (boot.ini: /3GB or /USERVA)
32-bit x86 Address Space 32-bits = 2^32 = 4 GB 4GT Address Space (boot.ini: /3GB or /USERVA) (BCD: increasuserva) Default 2 GB User process space 3 GB User process space 2 GB System Space 1 GB System Space
8 64-bit Address Spaces 64-bits = 2^64 = 17,179,869,184 GB x64 IA-64
32-bit process on 64-bit Windows = 4 GB x64 (AMD64 & Intel 64) IA-64 8192 GB (8 TB) User process space 7152 GB (7 TB) User process space
8192 GB (8 TB) System Space
8192 GB (8 TB) System Space
9 Virtual Memory Types Address space breakdown
Shareable (e.g. EXE, DLL, shared memory, other memory mapped files) Private (e.g. process heap) Reserved (not yet committed) Free (not yet defined) Performance counters available: Private Bytes – private virtual memory Virtual Bytes – total of shareable+private+reserved No separate counters for Shareable or Reserved or Free
10 Looking at a Process Address Space
Sysinternals VMMap utility shows address-space usage
11 Tracking Process Commit Usage
Most virtual memory problems are due to a process leaking private committed memory Heap, GC heap, language heaps (CRT) Testlimit -m Viewing process commit usage: Private Bytes perf counter Process Explorer’s Private Bytes: Before Vista: Task Manager’s Virtual Size Vista and later: Task Manager’s Commit Size
12 The System Commit Limit
Another virtual memory limit is total virtual memory: system commit limit Committed virtual memory must be backed either by physical memory or stored in the paging file Sum of (most of) physical memory and paging files The system commit limit can change Default paging file (System Managed): Minimum: 1.5x RAM if RAM Maximum: 3x RAM or 4 GB, whichever is larger
13 Viewing the System Commit Limit
Process Explorer tracks the current commit limit in the System Information window: Prior to Vista, Task Manager shows it as “PF Usage”: Task Manager on Vista and higher doesn’t show a graph:
14 Exhausting the System Commit Limit
64-bit Testlimit -m (committed memory) will exhaust the system commit limit before its address space: You can increase the System commit limit by adding RAM or increasing the pagefile size
15 Sizing the Paging File Many recommendations use a formula based on RAM (1.5x, 2x, etc.) Actually, the more RAM, the smaller the paging file needed Should be based on workload usage of committed virtual memory Look at commit after workload has run Pre-Vista: Task Manager Vista+: Process Explorer Apply a formula to that to give buffer (1.5x or 2x) Make sure it’s big enough to hold a crash dump
16 Outline Virtual Memory Physical Memory Paged and Nonpaged Pool
Processes and Threads Handles
17 Windows Physical Memory Limits
The amount of physical memory Windows will use depends on: SKU licensing 32-bit vs 64-bit Tested systems Kernel address space See “Memory Limits for Windows Releases” for a complete list:
18 Physical Memory on 64-bit Systems
Kernel address space limits it to 2 PB (Petabytes) x64 page table structures limit physical memory to 48-bits physical addressing (256 TB) Current x64 hardware supports up to 1 TB
19 64-Bit Server Current Windows Server limits:
Windows Server 2003: 16 GB (Standard) – 2 TB (Datacenter) Windows Server 2008: 32 GB (Standard) – 2 TB (Datacenter) Windows Server 2008R2: 8 GB (Foundation) – 2 TB (Datacenter) For Datacenter Edition, the limit is based on SKU and hardware testing We won’t support what we can’t test Limits have gone up even for a particular release of Windows because of access to larger machines Datacenter Edition maxes out all licensing, including memory
20 2 Terabytes The Windows architecture can support much more, but as of now, the largest system we’ve tested is 2 TB (Itanium):
21 32-Bit Server Windows 32-bit Server limits:
Windows Server 2003: 2 GB (Web) – 128 GB (Datacenter) Windows Server 2008: 4 GB (Standard) – 64 GB (Datacenter) Windows Server 2008 R2: n/a The 32-bit Server limit is based on the kernel address space PFN entry is 28-bytes so 128 GB requires 890 MB Limits other system code and data Also why limit is lower when booted 4GT User Address Space System PFN Database
22 Client Systems 64-bit client limits solely based on licensing:
512 MB in Windows XP Starter 128 GB in Windows Vista Ultimate 192 GB in Windows 7 Ultimate 32-bit client limit is 4 GB Limited by potential driver incompatibility And usable amount might be less than 4 GB…
23 Drivers and Physical Memory
To be safe, client limits physical memory addresses to 4 GB Some client device drivers still truncate addresses > 4 GB Client systems with > 4 GB are recent Servers are safe with > 4 GB Have had more than 4 GB for longer Devices are more mainstream Policy allows only WHQL-signed drivers 0.2 GB 0x DMA Destination Device Data 4 GB 4.2 GB Target 0x x 6 GB
24 Device Memory Device memory can push physical memory above 4 GB
Device memory can push physical memory above 4 GB Firmware maps all device memory below 4GB For compatibility with older operating systems Biggest device memory consumer is video Result is that some physical memory may lie above 4 GB Watch out for Shared Video Memory (UMA) Video RAM 4 GB Inaccessible RAM
25 Physical Memory Management
Working set: all the physical pages “owned” by a process Pre-Vista: Task Manager’s “Mem Usage” Vista+: Task Manager’s “Memory – Working Set” Process Explorer’s “Working Set” System has its own working set (broken into multiple in Windows 7) System keeps physical pages on one of several lists Working sets (process and system) Available: Free page list, Standby page list (file cache), Zero page list Modified page list: pages that must be saved before being repurposed Lists are implemented by entries in the “PFN database” Each page of physical memory has an entry in the database The Memory Manager watches paging activity to determine how to assign memory Notepad Word Explorer System Available
26 Working Set Lists newer pages older pages A process always starts with just enough working set to describe the address space It then incurs page faults when referencing a page that isn’t in its working set Many page faults may be resolved from memory (from other working sets, the standby or Modified page lists) The Memory Manager can take away pages and reassign them (trimming) Note: the amount of physical memory assigned to a process is invisible to the process It simply affects the performance of the process
27 Do You Have Enough Memory?
There’s no sure-fire rule or counter to tell if you if you have enough memory The general rule: available memory remains generally low Use Perfmon to monitor available memory over time Use Process Explorer, or on Vista and later Task Manager, to monitor physical memory usage Use Process Explorer or Task Manager to see instantaneous value Watch in Process Monitor for excessive reads from paging file
28 Outline Virtual Memory Physical Memory Paged and Nonpaged Pool
Processes and Threads Handles
29 Paged and Nonpaged Pool
Backed by physical memory Kernel and device driver heap used by code paths that can’t take interrupts (ISRs and DPCs) or that hold spin locks Page fault in those paths results in IRQL_NOT_LESS_OR_EQUAL Paged pool: Backed by virtual memory (can be saved to paging file) Largest consumer is typically Registry Drivers use ExAllocatePoolWithTag to allocate both pool types Parameter specifies pool type Tag is 4-byte value that should be human readable and is used to help track pool usage
30 Viewing Pool Usage There are three performance counters that indicate pool usage: Pool nonpaged bytes Pool paged bytes (virtual size of paged pool – some may be paged out) Pool paged resident bytes (physical size of paged pool) No performance counter for viewing maximums Use Process Explorer to view current and maximums Must configure symbols to see maximum System Information dialog shows usage
31 Pool Limits Pool maximums are based on system address space and physical memory Nonpaged Pool 32-bit 64-bit XP, Server 2003 up to 1.2GB RAM: MB > 1.2GB RAM: 256MB min(
400K/MB of RAM, 128GB) Vista, Server 2008, Windows 7, Server 2008 R2 min(
75% of RAM, 2GB) min(
75% of RAM, 128GB) Paged Pool 32-bit 64-bit XP, Server 2003 XP: up to 491MB Server 2003: up to 650MB min( 4 * nonpaged pool limit, 128GB) Vista, Server 2008, Windows 7, Server 2008 R2 min( system commit limit, 2GB) min( system commit limit, 128GB)
32 Testing Pool Limits Sysinternals Notmyfault can leak paged and nonpaged pool Exhausting either pool type leads to erratic behavior and likely data loss or corruption
33 Tracking Pool Leaks Poolmon from the Windows Driver Kit shows pool usage by tag Search strings of drivers for pool tag: strings * | findstr
34 Pool Leaks and Crashes If a system crashes and you suspect a pool leak, use !vm to confirm: Use !poolused to view pool usage by tag Use 1 for nonpaged pool and 4 for paged
35 Outline Virtual Memory Physical Memory Paged and Nonpaged Pool
Processes and Threads Handles
36 Thread Limits User-mode stack area is reserved and committed as needed
Stacks grow down in memory “Guard” pages trigger stack expansion Committed Stack Grows Down Committed Thread Stack Guard Guard Reserved Reserved Before Expansion Before Expansion
37 32-Bit Thread Limits Default 2 GB address space and stack reserve: 2 GB / 1 MB =
2,000 threads 32-bit thread on 64-bit Windows has additional overhead of 256 KB 64-bit stack
38 64-Bit Thread Limits On 64-bit Windows, the system commit limit will be hit before address space exhaustion Even with default 2 MB stacks
39 Process Limits Minimum process working set also charged against “resident available memory” Reserved physical memory so that process can run Default minimum is 200 KB, which Process Explorer shows Every active process has one thread, so process limit will be lower than thread limit
40 Outline Virtual Memory Physical Memory Paged and Nonpaged Pool
Processes and Threads Handles
41 Handles and Objects Windows defines objects to represent operating system resources There are 42 in Windows 7 Use Sysinternals Winobj to view defined objects When a process wants to interact with a resource, it opens it That creates a handle in the process’ handle table Handle entry points at the object and records granted access Subsequent operations reference the handle Object Handle Table Entry Pointer Accesses
42 Handle Limits A process handle table can grow to about 16 million handles Handle tables are stored in paged pool, so that can also be a limiter 32-bit Windows: 8 bytes per entry 64-bit Windows: 16 bytes per entry
43 Tracking Handle Leaks A handle leaker will show a growing handle count over time Task Manager and Process Explorer show handle count columns Process Explorer also shows it in process properties dialog Process Explorer uses difference highlighting to show newly opened and closed handles
44 Tracking Handle Call Stacks
Windows can capture call stacks at the time of handle open and close Use Application Verifier to track from process start Free download from Microsoft Use Windbg to enable and disable dynamically !htrace –enable, !htrace –disable
45 Viewing Handle Call Stacks
Use Windbg to view stacks Use !htrace (no parameters) to show all recorded stacks Use !htrace –snapshot and !htrace –diff to see differences
46 Conclusion Knowing system limits can help you avoid resource exhaustion By knowing how to track resource usage you can identify potential problems and root cause them Visit my blog for posts on the limits I’ve covered and others Come to my other sessions: SIA301 Windows and Malware: Which Features Are Security and Which Aren’t Tomorrow at 9am CLI301 Case of the Unexplained. Windows Troubleshooting Tomorrow at 1pm
47 Complete an evaluation on CommNet and enter to win an Xbox 360 Elite!
Блог GunSmoker-а (переводы) 
. when altering one’s mind becomes as easy as programming a computer, what does it mean to be human.
пятница, 30 января 2009 г.
Преодолевая пределы Windows: физическая память
Это первый пост в блоге из серии «Pushing the Limits of Windows», которую я буду писать ближайшие месяцы и в которой буду описывать как Windows и приложения используют конкретный ресурс, лицензионные и реализационные ограничения ресурса, как измерить использование ресурса и как диагностировать его утечки. Чтобы эффективно управлять своими Windows системами вам нужно понимать как Windows управляет физическими ресурсами, такими как процессоры (CPUs) и память (memory), а также логическими ресурсами, такими как виртуальная память (virtual memory), дескрипторы (handles) и объекты оконного менеджера (window manager objects). Знание пределов и ограничений этих ресурсов и методы слежения за ними позволит вам соотносить использование ресурсов с приложениями, которые их используют, эффективно изменять систему для определённой нагрузки и идентифицировать приложения с утечкой ресурсов.
Физическая память
Физическая память является одним из основных ресурсов компьютера. Менеджер памяти Windows является ответственным за заполнение памяти кодом и данными запущенных процессов, драйверов устройств и самой операционной системы. Поскольку большинство систем работают с большим объёмом кода и данных, чем может вместить в себя физическая память компьютера, то физическая память, по сути, является окном в используемые код и данные. Поэтому количество установленной памяти влияет на производительность, потому что если данные или код не присутствуют в физической памяти, то менеджеру памяти необходимо загрузить их с диска.
Кроме влияния на производительность, количество установленной физической памяти привносит и другие ограничения. Например, размер не подкачиваемого пула (non-paged pool) — буфера операционной системы — очевидно, ограничен физической памятью. Физическая память также влияет на ограничения системной виртуальной памяти, размер которой является грубой суммой физической памяти плюс максимальным размером всех файлов подкачки. Ещё Физическая память может неявно влиять на максимальное число одновременно работающих процессов, о чём я буду говорить в будущем посте, посвящённому ограничениям на процессы и потоки.
Ограничения памяти на серверных Windows
Поддержка физической памяти Windows диктуется ограничениями аппаратной части, лицензированием, структурами операционной системы и совместимостью драйверов. Страница Memory Limits for Windows Releases в MSDN описывает ограничения в различных версиях Windows, а также в пределах версий по редакциям (SKU).
Вы можете увидеть различия в поддержки памяти у разных редакций Windows, диктуемые лицензионными ограничениями. Например, 32-х битная Windows Server 2008 Standard поддерживает только 4 Гб, в то время как 32-х битная же Windows Server 2008 Datacenter поддерживает уже 64 Гб. Аналогично, 64-х битная Windows Server 2008 Standard поддерживает 32 Гб, а 64-х битная Windows Server 2008 Datacenter может оперировать целыми 2 Тб. Вокруг нас не так много систем с 2 Тб физической памяти на борту, но команда производительности Windows Server (Windows Server Performance Team) знает парочку, включая одну, которая была у них в лаборатории для тестов. Вот скриншот Менеджера Задач (Task Manager), работающего на такой системе:
Максимальное ограничение в 128 Гб на 32-х битных Windows, поддерживаемое редакцией Windows Server 2003 Datacenter, следует из того, что структуры, используемые менеджером памяти для отслеживания физической памяти, занимали бы слишком много виртуального адресного пространства на системах с большим количеством памяти. Менеджер памяти следит за каждой страницей (page) памяти, храня данные о ней в массиве, называемом базой данных PFN (PFN database), и (по соображениям производительности) проецируя всю базу данных PFN в виртуальную память. Поскольку в ней каждая страница физической памяти представлена структурой данных размером 28 байт, то вся БД PFN для системы с 128 Гб занимает около 930 Мб. 32-х битные Windows имеют 4 Гб виртуального адресного пространства, которое аппаратно делится на две части: пользовательскую, в котором выполняется процесс пользователя (например, Блокнот), и системную. Поэтому 980 Мб занимают практически половину их доступных 2 Гб из системной части виртуального адресного пространства, оставляя только 1 Гб для ядра, драйверов устройств, системного кэша и других системных структур данных, что делает совершенно неразумным дальнейшее увеличение размера БД:
По этой же причине в таблице с ограничениями также указываются пределы для той же редакции, но при загрузке с модификацией этих 4 Гб (опция называется 4GT и включается указанием в Boot.ini /3GB или /USERVA, а также опцией /Set IncreaseUserVa в Bcdedit), потому что опция 4GT передвигает границу между пользовательской и системной частью виртуального адресного пространства, что даёт до 3 Гб пользовательской части, но оставляет только 1 Гб для системы. Для улучшения производительности, 32-х битный Windows Server 2008 увеличивает зарезервированную часть для системного адресного пространства понижением максимального размера поддерживаемой памяти до 64 Гб.
Менеджер памяти мог бы поддерживать и больше памяти, проецируя БД PFN по кускам в адресное пространство по мере необходимости, но это добавило бы сложности и уменьшило производительность за счёт добавленных накладных расходов на операции проецирования и снятия проекции (map and unmap operations). Только недавно системы стали настолько большими, что нужно задумываться об этом, но поскольку размер адресного пространства не является ограничением для БД PFN на 64-х битных Windows, то поддержка большего количества памяти перекладывается на 64-х битные Windows.
Максимальный предел в 2 Тб на 64-х битном Windows Server 2008 Datacenter не следует из каких-либо ограничений реализации или аппаратной части, но Microsoft поддерживает только те конфигурации, который она может протестировать. Ко времени релиза Windows Server 2008, самая большая система в мире имела 2 Тб, поэтому Windows ограничивает свою поддержку памяти именно 2-мя Тб.
Ограничения памяти на клиентских Windows
64-ти битные клиентские редакции Windows поддерживают различное количество физической памяти как средство усиления различий между редакциями (SKU-differentiating feature) — от нижнего предела в 512 Мб для Windows XP Starter до 128 Гб для Vista Ultimate. Все 32-х битные клиентские редакции Windows, однако, (включая Windows Vista, Windows XP и Windows 2000 Professional) поддерживают максимум 4 Гб физической памяти. 4 Гб — это максимальный размер физической памяти, доступный из стандартного режима управления памятью на x86. В те времена не было необходимости даже рассматривать большее число памяти на клиентских системах, потому что даже сервера с таким количеством памяти были редкостью.
Однако, ко времени, когда Windows XP SP2 был в разработке, клиентские системы с более чем 4 Гб памяти появились в обозримом будущем, поэтому команда Windows начала широкомасштабное тестирование Windows XP на системах с памятью более 4 Гб. Windows XP SP2 также включал по-умолчанию поддержку Physical Address Extensions (PAE) на железе, которое реализовывало память no-execute, потому что оно требовалось для Data Execution Prevention (DEP), но оно же включало поддержку для памяти выше 4 Гб.
Но при этом разработчики Windows обнаружили, что многие системы начинали вылетать, зависать или вообще не загружаться, потому что некоторые драйвера устройств (часто это такие видео или аудио драйвера, которые обычно используются на клиентских системах, а не на серверах) не были запрограммированы работать с физическими адресами больше 4 Гб. В результате, драйвера обрезали такие адреса, приводя к порче памяти и побочным эффектам такой порчи. Серверные системы обычно имеют более общие устройства с простыми и более стабильными драйверами, а поэтому обычно не встречаются с подобными проблемами. Эта проблематичная экосистема клиентских драйверов привела к принятию решения об игнорировании памяти выше 4 Гб на клиентских редакциях, даже если система теоретически может адресовать столько памяти.
Реальные ограничения памяти на клиентских 32-х битных Windows
Хотя 4 Гб памяти заявлено как предел для 32-х битных редакций Windows, но реальный предел будет ниже и зависит от чипсета системы и подключенных устройств. Причина в том, что физическое адресное пространство включает в себя не только оперативную память (RAM), но также и память устройств, а системы x86 и x64 проецируют память устройств ниже границы в 4 Гб для обеспечения совместимости с 32-х битными операционными системами, которые не знают, как обращаться с адресами выше 4 Гб. Если система имеет 4 Гб оперативной памяти и устройства, типа видео, аудио или сетевых адаптеров, будут реализовывать окна в свою память (которая в сумме пусть будет равна 500 Мб), то 500 Мб памяти из 4-х Гб будут расположены выше границы в 4 Гб, как показано ниже:
В результате этого, если у вас есть система с 3 Гб или более памяти под управлением клиентской версии 32-х битной Windows, вы не сможете получить в своё распоряжение всю оперативную память. На Windows 2000, Windows XP и Windows Vista RTM вы можете узнать, сколько оперативной памяти доступно системе в диалоговом окне Свойства системы, странице Производительность Менеджера Задач и, в Windows XP и Windows Vista (включая SP1), в утилитах Msinfo32 и Winver. На Window Vista SP1 некоторые из этих мест теперь показывают установленную память, а не доступную для системы память, как указано в этой статье Knowledge Base.
На моём ноутбуке с 4 Гб памяти, когда я загружаю 32-х битную Vista, количество доступной физической памяти будет 3.5 Гб, как показано в утилите Msinfo32:
Вы можете посмотреть раскладку физической памяти с помощью утилиты Meminfo от Alex Ionescu (он также внёс вклад в 5-ю редакцию Windows Internals, которую я написал в соавторстве с Дэвидом Соломоном). Вот вывод Meminfo, которую я запустил на этой же системе с ключом -r для создания дампа диапазонов физической памяти:
Обратите внимание на пробел в адресном пространстве со страницы 9F000 до страницы 100000, и ещё один от DFE6D000 до FFFFFFFF (4 Гб). Однако, когда я загружаюсь на этой же системе в 64-х битной Vista, все 4 Гб показываются как доступные и вы можете видеть, как Windows использует ещё 500 Мб оперативной памяти, находящиеся выше границы в 4 Гб:
Откуда берутся эти пробелы ниже 4 Гб? На этот вопрос нам поможет ответить Диспетчер Устройств. Для проверки, запустите «devmgmt.msc», выберите «Ресурсы по подключению» в меню «Вид», и разверните узел «Память». На моём ноутбуке главным похитителем памяти стала, что и неудивительно, видеокарта, которая потребляет 256 Мб в диапазоне E0000000-EFFFFFFF:
Прочие девайсы занимают большинство оставшегося места, а шина PCI резервирует дополнительные диапазоны для устройств во время загрузки как часть консервативной оценки firmware этих устройств.
Потребление адресов памяти ниже 4 Гб может быть весьма значительным на топовых игровых конфигурациях, имеющими видеокарты с большими объёмами памяти. Например, я купил одну такую систему в бутике игрового стенда компании — она шла с 4 Гб памяти и двумя видеокартами по 1 Гб каждая. Я не уточнил версию ОС, полагая, что они сообразят поставить 64-х битную Виста, но система пришла с 32-х битной версией. В результате только 2.2 Гб памяти было доступно для Windows. Вы можете увидеть гигантскую дыру в памяти с адреса 8FEF0000 по FFFFFFFF в следующем выводе Meminfo с этой системы после того, как я поставил на неё 64-х битную версию Windows:
Диспетчер Устройств показывает, что 512 Мб из этой дыры в зарезервированно для видеокарт (256 Мб каждая), и похоже, что firmware просто зарезервировало больше памяти, либо для динамического проецирования, либо же в результате использования консервативных оценок:
С такими проблемами могут встретиться даже системы имеющие на борту только 2 Гб. Проблемы возникают из-за чипсетов, агрессивно резервирующих регионы памяти для устройств. Наш общий семейный компьютер, который мы купили всего несколько месяцев назад от известного OEM поставщика, сообщает о доступности только 1.97 Гб из 2-х установленных:
Диапазон физических адресов от 7E700000 до FFFFFFFF зарезервирован шиной PCI и устройствами, что оставляет теоретический максимум физического адресного пространства в 7E700000 байт (1.976 Гб), но даже часть из этого резервируется для памяти устройств, что оставляет Windows только 1.97 Гб.
Поскольку теперь производители устройств обязаны отправлять как 32-х битный, так и 64-х битный драйвера в лаборатории Windows Hardware Quality Laboratories (WHQL) для получения сертификата подписи, то большинство производителей устройств сегодня могли бы поддерживать физические адреса выше 4 Гб. Однако, 32-х битные Windows будут продолжать игнорировать память выше этой границы, потому что всё ещё существуют определённые сложности с измерением риска такого изменения, а производители OEM двигаются (или, по крайней мере, должны) в сторону перехода на 64-х битные Windows, где эта проблема просто не стоит.
Суть заключается в том, что вы можете использовать всю установленную у вас память (до предела, установленного редакцией системы) с 64-х битной Windows, вне зависимости от её количества, и если вы покупаете высокопроизводительную геймерскую систему, то вам определённо стоит попросить продавца установить на неё 64-х битную Windows.
Достаточно ли у вас памяти?
Вне зависимости от того, сколько памяти у вас есть, настоящий вопрос заключается в том, достаточно ли этой памяти? К сожалению, не существует какого-либо простого правила, с помощью которого вы точно узнаете ответ на этот вопрос. Хотя есть общее руководство, которое вы можете использовать, оно основано на мониторинге доступной системе памяти за промежуток времени, особенно в моменты работы приложений, требовательных к памяти. Windows определяет доступную память как физическую память, которая не была привязана к процессу, ядру или драйверу устройства. Как следует из этого названия, доступная память доступна для присвоения её по требованию процесса или системы. Системный менеджер памяти, конечно же, пытается использовать максимум памяти, используя свободную память как файловый кэш (список standby), как обнулённую память (список страниц, заполненных нулями), а функция Superfetch в Vista также использует её для предзагрузки (prefetch) данных и кода в списке standby и упорядочивает их по наибольшей вероятности использования в ближайшее время.
Когда доступная память становится дефицитом, это означает, что либо процессы, либо система активно используют физическую память, и если доступная память находится в районе нуля продолжительное время, то вы вероятно выиграете от установки большего количества памяти. Есть несколько способов отслеживать доступную память. В Windows Vista вы можете неявно следить за доступной памятью, наблюдая за историей использования физической памяти (Physical Memory Usage History) в Диспетчере Задач, Task Manager. Вот снимок экрана Диспетчера Задач на моём настольнике с 8 Гб памяти (хмм, я думаю, что у меня, пожалуй, даже слишком много памяти!):
На всех версиях Windows вы можете увидеть график доступной памяти, используя оснастку Производительность (Performance Monitor) и добавляя в ней счётчик Available Bytes из раздела Memory:
Вы также можете видеть мнгновенные значения в диалоге System Information утилиты Process Explorer, или, на версиях Windows до Vista, на вкладке Производительность Диспетчера Задач (Task Manager’s Performance page).
Из процессора (CPU), памяти и дисков — память обычно наиболее важна для общей производительности системы. Чем больше памяти — тем лучше. И 64-х битные Windows являются способом убедиться, что вы используете все возможности вашей системы. Кроме того, 64-х битные Windows могут иметь и другие бонусы в плане производительности, о которых я поговорю в следующем посте серии Pushing the Limits, когда я буду говорить о виртуальной памяти.
