winlogon / LogonUI周期性尖锐CPU使用率
我注意到，我的AWS服务器偶尔会开始使用一堆CPU没有特别的原因，看起来像这样：
注意到它不是在特定的时间发生的，而是有一个非常确定的模式。 它持续不到一个小时。
在这种情况下对机器进行远程处理总是会使其停止发生。 将该帐户永久login允许我捕获更细粒度的CPU使用情况跟踪。 它看起来像这样：
- AWS CloudFormation能否创build一个KeyPair以便在启动实例时随后使用？
- AWS上的PCI-DSS选项 – 文件完整性监测和入侵检测
- 使用Chef Server部署AWS Auto Scaling组
- AWS ELB作为Varnish Accelerator的后端
- stream量在AWS虚拟私有云中
那就对了; 实际使用该CPU的进程不在列表中。 相反，它们总是出现和消失。 ProcMon显然是这项工作的工具，所以我抓住了一个痕迹。 这是我发现的：
还有Postgres参与：
但是，所有的CPU使用率是由Winlogon / LogonUI / etc：
以下是这个过程中的一个简短的过程开始和结束事件摘录：
请注意，postgres不与每个smss / winlogon / etc的启动/停止交错，但只有其中一些。
任何想法，为什么发生这种情况，以及如何预防呢？
对于postgres部分，这是因为postgres为每个会话创build一个进程而不是线程。 这在Windows上是相当昂贵的（但在UNIX系统上效率很高）。
Winlogon / LogonUi这部分很奇怪。 服务器是否可以远程访问？ 在networking上是否会有一个networking扫描器试图打开服务器上的端口3389，从而跨越一个rdp会话，这将解释smss / winlogon / logonui序列？ 我想到一个networking扫描仪，因为会议立即closures。
所以我的赏金猜测：你有一个nmap进程或一些“networking发现”工具，扫描您的networking端口，或者您的服务器是开放的互联网没有防火墙端口3389（也许5432）。
问题是有人蛮横强迫我的RDPlogin。 第二个问题是networking级别的身份validation被禁用，使每次login尝试相对CPU昂贵。
解决scheme是将RDP端口从3389改为远离蛮力攻击 ，并启用networking级别身份validation，以降低login尝试的CPU成本。
提示＃1 ，从syneticon-dj：检查事件日志。 这些尖峰与许多login失败相关，尝试像“john”，“admin”，“test”等用户名，每个用户有大约3-5个不同的密码。 他们相隔3-4秒。
来自Olivier S的提示＃2 ：这个服务器是Amazon EC2实例，需要RDP。 真正的问题是，出于某种原因，默认情况下， EC2机器已禁用networking级身份validation 。 这意味着每次有人想要input密码时，整个login界面都会自动启动，只是为了向他们展示一个非常远的桌面会话。 这是造成所有CPU使用率的原因。
我发现这个问题的答案是15人试图在3389端口上强制我的RDP。
打开一个命令提示符并键入netstat -n查找您的IP：3389如果有超过1个连接不是你自己，那么有人试图进入。
停止接近100％CPU的解决scheme是将默认的3389更改为其他值。
你可以谷歌解决这个，端口存储在registry中
您可能还需要相应地修改您的防火墙规则
这治好了我的问题，我有我的CPU回来！