服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

在具有16个内核/处理器的2处理器计算机上,SQL Server 2012的CPU利用率非常不均衡

在使用Server + Cal许可证模型安装SQL Server Enterprise 2012之后,在具有两个每个都有16个内核的处理器(并且不涉及超线程)的计算机上,并且将服务器置于极其繁重的负载下,第一个处理器上的16个内核的利用率非常低,第二个CPU上的前4个内核被大量使用,最后12个内核根本不使用(因为这个sql服务器版本的内核限制为20个)。 总CPU利用率显示为25%左右。 不幸的是,即使如果任务在20个内核上均匀分配,服务器的性能也会非常差,但是这种性能不会太差。 Windows Server在ESX Server下的VMWare虚拟映像上运行,但是所有的CPU都被分配给了Windows服务器。 我们试着改变关联设置(例如,将大多数核心分配给CPU,其他核心分配给I / O),但是这并没有帮助解决性能问题。 将产品版本升级到SQL Server Enterprise Core 2012不仅使SQL Server能够利用第二个处理器上先前未使用的12个内核,而且还可以在所有处理器上实现更均匀的任务分配。 为了解决积压的问题,CPU利用率跳升到90%左右,一旦被赶上后下降到33%左右,但是从最新的版本失败后,性能大幅提升,性能问题也随之消失。 我想知道是否有人知道什么可能会导致SQL Server不均匀地分配负载,几乎完全依赖于第二个处理器的前12个核心处于空闲状态的4个内核,并且只在第一个内核的16个内核中分配了几个任务处理器。 另外,有没有什么办法可以让我们更平均地分配20个内核的负载,而不用进行产品版本升级呢? 这个问题的另一面是产品升级做了什么,导致SQL Server开始在所识别的所有核心上平均分配负载? 感谢任何见解,以回答这些问题和/或链接,可能会帮助我更好地了解如何理解发生了什么事情。

我如何使用SELinux来限制PHP脚本?

我想在我的SL6.4(RHEL 6.4重build)Web服务器上划分不同的PHP应用程序,以便它们不能访问彼此的数据。 SELinux似乎可以做到这一点,但我不确定细节。 我的问题有两个部分: SElinux如何使用mod_phppipe理在Apache进程中运行的PHP脚本? 当运行PHP脚本时,进程是否以某种方式进入脚本上下文,还是只有当脚本通过CGI或FastCGI运行在进程外时才能工作? 如果它转换到一个脚本上下文来运行PHP脚本,是什么让PHP的错误触发转换回主要的httpd上下文? 如果我需要一个备用的PHP部署方法,这将是很好的知道。 我怎样才能分离脚本/应用程序,例如TinyTinyRSS不能访问OpenCloud拥有的东西? 看起来我应该可以通过closureshttpd_unified并提供单独的httpd_ttrss_*和httpd_opencloud_*上下文来实现这一点,并行于httpd_user_foo和httpd_sys_foo 。 考虑到我可以使用的应用程序的数量,我甚至可以使用没有新上下文的sys / user区分。 但是我还没有find关于什么closureshttpd_unified的含义的文档,或者如何设置不同的HTTP上下文。 特别是用PHP脚本通过mod_php运行。 我很好地创build了新的SELinux策略模块,但希望一些文档指向我需要做的新策略,以及如何使它与SELinux目标策略很好地集成。 如果试图用SELinux来完成这种分离是一个失败的原因,我需要在不同的上下文中分别启动不同的httpd,甚至可能是LXC容器,这也是一个有用的答案。

我如何实现细粒度的密码策略,并期望XP机器打好?

我有一个2008 R2function级域,并且正在实施我的组织将要使用的第一个实际的密码策略。 为了将这一点慢慢推出给我们的用户,我们select使用细粒度的密码策略(FGPP)来仅适用于我们select的特定用户。 为此,我们将这个策略分配给一个使用它作为影子组的组。 我们已经完成了创buildPSO对象的过程,确认新策略只适用于该组内的用户。 一旦我们感到舒服,我们将删除此PSO并将密码策略移至默认域策略。 幸运的是,我只能为所有用户使用一个策略。 在5000台左右的桌面中,我们可能仍然超过75%的Windows XP。 在我们的testing中,我们发现如果这个FGPP适用于这个新组中的用户,并且在login到Windows 7个人电脑时被迫更改密码,那么效果很好。 但是,login到Windows XP PC时,仍然强制他们更改密码,但是由于错误消息使用默认域策略中的策略。 如果我们开始推出,用户在尝试input密码后会感到困惑,并且会收到一条错误消息,告诉他们在实际需求不符时尝试另一个。 正如在这篇Technet文章中所提到的那样,它说这是一个已知的行为,build议忽略它。 这对我们来说是不可能的。 如果在Windows XP电脑上出现,我们不能使用FGPP。 我们已经考虑过为所有用户设置“密码永不过期”属性,然后在默认域策略级别实现密码策略,但是如果出现问题,我们宁愿不这样做,因为可能的混乱。 有没有人曾经遇到过这个问题,或者可以提供任何build议? 这是在GINA某处的错误消息? 可以修改吗?