Windows 优化分析
Windows 优化分析
Windows 计算机的性能和稳定性总是相互影响的。提升性能又兼顾稳定性，需要科学、反复的实践才能应对持续发展的复杂IT化境。而 Windows PC 性能的直观表现主要归为以下几个方面：
一、启动速度
Windows PC 的启动速度，以秒为测量单位（实际监测和分析中可达到纳秒级），其对于用户的感知和体验尤为重要。排除硬件自身的启动过程（BIOS启动）所消耗的时间，加载操作系统到进入桌面欢迎界面，直到用户登录域能以正常响应速度进行操作，要经历一系列复杂的过程，涉及 PC 资源和模块的方方面面。
无论用户是否能切身感受到它，这一过程始终在一定的时间内持续进行。Windows 系统的启动过程，可参阅下图：
加入到AD域的Windows计算机上的操作系统启动和用户登录延迟，通常要耗费几十到上千秒。因为现实情况中存在许多原因，包括硬件性能，网络性能，IT添加的工作负载量，以及应用程序和操作系统组件中的低效率。
在OS初始化阶段，大部分操作系统工作都会发生。此阶段涉及内核初始化，即插即用活动，服务启动，登录和资源管理器初始化。操作系统初始化可以分为四个子阶段，每个子阶段都有独特的特征和性能漏洞。
- 子阶段1 – Pre Session Init（PreSMSS）：内核初始化
PreSMSS子阶段在内核被调用时开始。在这个子阶段，内核初始化数据结构和组件。它还启动PnP管理器，该管理器初始化在OSLoader阶段加载的Boot_START驱动程序。 - 子阶段2 – Session Init（SMSSInit）：会话初始化
当内核将控制传递给会话管理器进程（Smss.exe）时，SMSSinit子阶段开始。在此子阶段期间，系统将初始化注册表，加载并启动未标记为Boot_START的设备和驱动程序，并启动子系统进程。当控件传递给Winlogon.exe时，SMSSInit结束。 - 子阶段3 – WinLogon Init：Winlogon初始化
当SMSSInit完成并启动Winlogon.exe时，WinlogonInit子阶段开始。在WinlogonInit期间，出现用户登录屏幕，服务控制管理器启动服务，并运行组策略脚本。当Explorer进程启动时，WinlogonInit结束。 - 子阶段4 – Explorer Init：资源管理器初始化
ExplorerInit子阶段在Explorer.exe启动时开始。在ExplorerInit期间，系统创建桌面窗口管理器（DWM）进程，该进程初始化桌面并首次显示它。 - Post Boot阶段
PostBoot阶段包括桌面准备就绪后发生的所有后台活动。用户可以与桌面进行交互，但系统仍可能在后台启动服务，托盘图标和应用程序代码，这可能会影响用户对系统响应的感知。
二、内存占用
从系统开机过程可以理解和认识到用户终端的性能取决于计算机的四个主要资源：内存、处理器、磁盘和网络。其中内存部分，微软Windows系统使用多种内存，具体可分为物理内存、提交内存、应用程序虚拟内存和内核虚拟内存。基于微软官方的性能计数器指标，可以指出每个响应资源的潜在问题，并通过Windows性能计数器识别最初的性能问题。
- 物理内存，识别物理内存是否出现性能问题的最好办法，是监控“MemoryAvailable MBytes”，当其小于100MB或小于总物理内存的5%~10%，则计算机可能在物理内存上运行严重不足，出现性能问题。因为此时会增加系统对磁盘子系统的依懒性，如果磁盘子系统不堪重负，则可能发生系统范围的延迟。相反，如果它高于10%则可将物理内存用于磁盘缓存。系统具有的磁盘缓存越多，避免磁盘I/O的机会就越大。磁盘比物理内存慢得多，所以需要大磁盘缓存。（注意：较低的内存占用是理想的优化目标，但在可用内存不足的情况下并不好。）
- 提交内存，提交的字节数是提交虚拟内存量，以字节为单位。提交的内存是磁盘页面文件上保留了空间的物理内存。换句话说，它是由进程“使用”的内存。提交内存是操作系统可以用来存储数据的所有物理资源的总和，是内存和所有页面文件的总和。一旦所有的内存和所有的页面文件已满并且无法展开，那么系统已达到其提交限制。使用“MemoryCommitted Bytes In Use”大于75%，则计算机可能在物理资源（内存和/或页面文件）上运行不足。
- 应用程序虚拟内存，Windows 中的每一个进程都有自己的专用虚拟地址空间。理想情况下，虚拟内存应用是大的难以想象，但事实是它是一个有限的资源。如果应用程序（用户模式）用完了虚拟内存，那么它可能会因内存不足异常而崩溃。要确定应用程序的最大虚拟地址空间，可使用以下命令确定应用程序虚拟内存的最大大小：wmic PATH Win32_OperatingSystem GET MaxProcessMemorySize
Windows 7 x64计算机的示例输出如下：
MaxProcessMemorySize为8589934464，输出以千字节为单位，因此，这台Windows 7 x64计算机每个进程具有8TB的虚拟内存。如果应用程序（用户模式）的虚拟内存耗尽，即它接近MaxProcessMemorySize，那么它可能会因内存不足异常而崩溃。要判断虚拟内存不足，可通过“Process (*)Virtual Memory”，超过MaxProcessMemorySize的80%，那么应用程序很可能会用尽虚拟内存，并且如果无法为其下一次内存分配找到连续内存，可能会很快崩溃。此外，在虚拟内存概念中指出，进程并不知道物理硬件。每个进程都有自己的私有虚拟地址空间，这是有限数量的虚拟内存。这允许Windows操作系统更有效管理物理内存资源（内存和磁盘页面文件）。如果一个进程视图超过它的虚拟地址空间，那么它会因为内存不足出现异常而崩溃。每个进程的虚拟内存量取决于它是否编译为32位或64位。X86是Windows的32位实现；x64是Windows的64位实现。其中，x86进程默认具有2GB的虚拟地址空间；具有大量地址识别功能并在x64操作系统上运行的x86进程具有4GB的虚拟地址空间；x64进程具有8TB的虚拟地址空间。
- 内核虚拟内存，内核也驻留在虚拟内存中，如果虚拟内存不足，则操作系统可能会挂起。内核有三个重要资源，即虚拟内存中的资源：系统页表条目（PTE），池分页和池非分页内存池。其中系统页面表条目提供了虚拟内存和物理内存之间的映射。使用“MemoryFree System Page Table Entries”进行监测，当小于10000，那么操作系统可能会遭受长时间的性能延迟。池分页和池非分页池用作操作系统和设备驱动程序用来存储其数据结构的内存资源。当它们无法分配内存时，操作系统可能会遭受长时间的性能延迟，通过对“MemoryPool Paged Bytes”或“MemoryPool NonPaged Bytes”的监测，当接近或超过其各自最大值的80%，则操作系统可能会遭受长时间的性能延迟。
三、处理器占用
处理器（CPU）方面，当“Processor (_Total)%Processor Time”平均大于80%，则计算机可能正忙于处理资源调度。此外，处理器中还包含线程，即进程的工蜂，其以两种模式之一执行：用户模式或特权模式，可通过相关指标进行监测：“Process (*)%User Time” 和 “Process (*)%Privileged Time”，二者组成“Processor (_Total)%Processor Time”。其中，特权（内核）模式是在执行系统调用的Windows内核（如驱动程序、IRP（I/O请求数据包）、上下文切换等等）中花费的时间。如果操作系统花费超过特定模式的30%，那么这意味着它可能执行大量的I/O并且一个或多个驱动程序正在执行以管理该I/O。用户模式，是处理器花费在执行应用程序代码上的时间量，因此需要确定哪些进程消耗了大部分时间以及执行最多的函数调用。可通过用户进程的内核时间或“Processor (*)%User Time”进行识别。
四、磁盘占用
终端磁盘不仅用于存储重要的数据，也是影响终端整体性能的关键因素之一。虽然目前磁盘容量已经非常大，但其硬件参数并不一定完全满足现实 IT 环境的性能需求。关键的磁盘性能指标如下：
- “LogicalDisk (*)Avg Disk Sec/Read”，以毫秒表示的值，因此在1秒样本取样中，将在1秒间隔内运行平均读取持续时间，并以毫秒为单位给出平均延迟时间。
- “LogicalDisk (*)Avg Disk Sec/Write”，同上，但仅表示写入时间。
一般而言，这两个值始终应在生产 IT 环境中低于15ms（0.015秒），否则说明计算机可能存在磁盘性能问题。但是，这些阈值只是假定传输大小为64KB或更小的文件。如果要移动较大容量的文件，则需要调整预期值，此时就需要考虑Disk Bytes/sec和Disk Transfers/sec因素。此外，关于磁盘性能的任何讨论都不能通过其容量以及物理性能特征来完成。制造商列出了大部分重要或相关指标，以便进行产品比较。平均搜索时间、平均写入时间或平均读取时间，以及内部控制器上的缓存数量，旋转速度，支持的技术（如本地命令队列）和物理特征（如接口，盘片大小等）。
例如，一块希捷商用台式机驱动器。
- 自转速度为7200转；
- 持续的数据传输速率为138Mb/s；
- 平均延迟4.16ms；
- 随机读取寻道时间8.5ms；
- 随机写入寻道时间9.5ms；
- I/O数据传输速率600MB/s。
该磁盘支持6Gb/秒的SATA接口，具有64MB板载高速缓存并具有2TB容量，转速是7200转。虽然其接口速度为6Gb/秒，但持续数据传输速率仅为138Mb/sec。就磁盘可以处理的负载而言，这是我们真正需要关注的数字。而这些参数的等待时间中，平均等待时间为4.16毫秒，随机（最差/典型情况下）读取和写入寻道时间均低于10毫秒。在Windows性能方面的含义，平均等待（延迟）意味着磁头需要这段时间将所需扇区放置在磁盘头下。读取和写入寻道时间是执行器将磁头移动到正确的刺刀进行读取或写入操作所用的时间。所以写入磁盘的平均传输时间应为13.66毫秒，读取为12.66毫秒。
五、网络
“Network Interface(*)Output Queue Length”指标如果大于2，则表示网卡无法用足够快的速度将数据包发送到网络。这可能是网络存在延迟或瓶颈。
HOWTO: 解决因禁用防火墙服务引发的 Outlook 附件预览故障
HOWTO: 解决因禁用防火墙服务引发的 Outlook 附件预览故障
MPSSvc is a core service! MPSSvc is a core service! MPSSvc is a core service! [ 重要的事情说三遍！！！]
MPSSvc是什么服务？干什么用的？
为了获取 MPSSvc 服务的相关信息，使用命令行 “sc qc mpssvc” 进行查看，可得知 MPSSvc 就是 Windows Defender Firewall，即 Windows 防火墙服务，启动方式为自启动。从遥远的 XP 时代开始，这个服务就存在，而且随着 Windows 系统的发展，已经成为必要的核心级服务。
而一些 “聪明” 的 IT 人员为了避免客户端计算机的 Windows 防火墙功能影响正常使用和管理，使用了自认为最有效的方法来禁用它！即，通过域 GPO 直接禁用 Windows Firewall（MPSSvc）服务。下发策略后，确实像 XP、Win7这样的客户端运行照旧，貌似没什么不良的影响，也满足了 IT 管理员的 “目标”，因为那些防火墙问题的报修有效减少了。
但是在后续的发展阶段，随着 Win8、Win8.1 的发布，到现在 Win10 的发布，企业中运行 Win10 的客户端计算机也越来越多，而微软也一直在致力于改善 Windows 的安全功能以提高安全性。那么问题来了，一些用户开始抱怨自己的 Outlook 无法正常预览 Office 附件，且在双击打开这些附件后会报错。
在预览附件时的报错提示为“不能预览此文件，因为以下预览程序发生了错误：...”；如果双击打开这个 Office 附件，则会提示“内存或磁盘空间不足，Microsoft ... 无法再次打开或保存任何文档。”在故障发生的起初，进行排错时一直都没有想到是防火墙导致的故障。（PS：谁会想到 “聪明” 的 IT 会如此禁用 WFW）
在无奈之际，使用 Procmon 对执行 trace 进行了捕获，进行具体的分析。在密密麻麻的记录中，终于找到了线索。当用户执行预览时，会触发一个对防火墙动态链接库的查询操作，由于 GPO 禁用了防火墙服务的启动，所以未能找到相关的资源。
当时为了验证，立刻检查了防火墙服务，果然被禁用导致无法正常启动。恢复设置后，故障解除。（PS：就此问题与 IT 理论的结果就是之前怎么没问题，现在怎么就出问题，压根就不是禁用防护墙服务的问题嘛！）
所以呢，要其变更下发的 GPO 是没戏了，为此想了一个 Workaround，即通过计划任务在每次启动系统后使用 sc 命令将 mpssvc 改为自启动，并启动它。具体的命令如下：
在编写上段命令前，曾尝试调整 Office 的安全设置，将打开有异常的 Office 文档的程序保护试图功能关闭，如下图所示。但是在 Outlook 中预览还是无法解决。
就 Windows 防火墙 与 Office 的问题，微软也发布了知识库进行了说明和解释。当同时满足以下条件时，则会发生上述描述的故障问题。
- Windows防火墙服务没有运行
- Windows 10、Windows 8.1、Windows 8 或基于 Windows Server 2012 的计算机上使用 Outlook 2016 或 Outlook 2013
具体是因为 Outlook 中的预览功能使用受保护的试图功能（也成为沙盒）。在 Microsoft Office 2010 引入了此功能。在 Windows 10、 Windows 8.1、Windows 8 和 Windows Server 2012，受保护的试图功能改进了 AppContainer 功能的结合。这提供了更强的进程隔离，并且它还会阻止从沙盒的网络访问。
参考资料：KB2912722
HOWTO：禁用 Windows 10 更新
HOWTO: 禁用 Windows 更新
Windows as a Service 是大势所趋，满足了大多数用户的需求。在过去用户总是抱怨 Windows 更新周期过慢，现在 Windows 10 每半年就会推出一个功能更新，但也并不是所有的用户都感到满意，真是众口难调！之前抱怨 Windows 更新过慢的一些企业用户，反而现在又抱怨更新过快！gOxiA 倒认为，其实他们的抱怨不是因为更新过快，而是因为每半年一次的功能更新常会发生更新失败的问题，这就增加了 IT 维护成本。导致更新失败的原因确实很多，在企业中常见的是因为一些第三方安全软件导致的，所以 In-Place Upgrade 就极易失败。最终，IT 希望能禁用或推迟 Windows 10 的功能更新，但在实际操作中发现并不能彻底禁用功能更新补丁的推送，这主要是因为 Waas 策略导致的，要求客户端要获得持续的支持就必须更新到最新版本，所以在到达推迟更新的最后期限后 Windows 10 仍旧会接收功能更新。
有不少 IT 人员来咨询是否有什么方案能解决这一问题？！网上也提供了很多种禁用更新的方法，但多少都有些瑕疵，其实我们完全可以借助微软 GPO 来实现禁用功能更新的需求。
首先在企业内部部署 WSUS，使客户端接入到 WSUS 上接受企业的统一更新管理，这样企业 IT 可以利用 WSUS 的审批功能只允许每月的安全更新。
虽然 Windows 客户端连接到 WSUS 上接受管理，但仍旧可以从微软官方获取更新，这就导致功能更新最终会被推送到系统上，尤其是“微软 Windows 10 易升”这样的工具。
所以我们还需要阻断到微软更新服务器的连接，为此我们使用 GPO 来实现。在“计算机配置 /管理模板/Windows 组件/Windows 更新”中找到“不要连接任何 Windows 更新 Internet 位置”，将其设置为“已启用”。
gOxiA 专门写了一个脚本，可通过 Github 获取。
https://github.com/goxia/ITSM/blob/master/W10_DisableOSUpgrade.bat
