我什么时候可以在同一台机器上托管IIS和SQL Server？ [英] When can I host IIS and SQL Server on the same machine?

问题描述

我读过在同一台机器上安装SQL Server和IIS是不明智的，但我没有看到任何证据。有没有人试过这个，如果有的话，结果是什么？在什么时候需要将它们分开？有必要进行调整吗？我特别关注IIS7和SQL Server 2008.

I've read that it's unwise to install SQL Server and IIS on the same machine, but I haven't seen any evidence for that. Has anybody tried this, and if so, what were the results? At what point is it necessary to separate them? Is any tuning necessary? I'm concerned specifically with IIS7 and SQL Server 2008.

如果有人能够提供显示何时更有意义转到两台机器的数字，那将是最有帮助的。

If somebody can provide numbers showing when it makes more sense to go to two machines, that would be most helpful.

推荐答案

使用任何其他产品运行SQL Server是不明智的，包括另一个SQL Server实例。此建议的原因是SQL Server如何使用OS资源的性质。 SQL Server在用户模式内存管理和处理器调度基础结构上运行，名为 SQLOS 。 SQL Server旨在以最佳性能运行，并假设它是操作系统上唯一的服务器。因此，SQL OS会在机器上为SQL进程保留所有RAM，并为每个CPU核心创建一个调度程序，并为所有调度程序分配任务，以便在需要时利用它可以获得的所有CPU。因为SQL保留所有内存，所以需要内存的其他进程将导致SQL看到内存压力，对内存压力的响应将从缓冲池和计划缓存中编译的计划中逐出页面。而且，因为SQL是唯一实际利用内存通知<的服务器/ a> API（有传言称下一个Exchange也会这样），SQL是唯一实际收缩的过程，为其他进程提供空间（如漏洞的错误ASP池）。在BOL中也解释了此行为：动态内存管理。

It is unwise to run SQL Server with any other product, including another instance of SQL Server. The reason for this recommendation is the nature of of how SQL Server uses the OS resources. SQL Server runs on an user mode memory management and processor scheduling infrastructure called SQLOS. SQL Server is designed to run at peak performance and assumes that is the only server on the OS. As such the SQL OS reserves all RAM on the machine for SQL process and creates a scheduler for each CPU core and allocates tasks for all schedulers to run, utilizing all CPU it can get, when it needs it. Because SQL reserves all memory, other processes that need memory will cause SQL to see memory pressure, and the response to memory pressure will evict pages from buffer pool and compiled plans from the plan cache. And since SQL is the only server that actually leverages the memory notification API (there are rumors that the next Exchange will too), SQL is the only process that actually shrinks to give room to other processes (like leaky buggy ASP pools). This behavior is also explained in BOL: Dynamic Memory Management.

CPU调度会发生类似的模式，其他进程会从SQL调度程序中窃取CPU时间。在高端系统和Opteron机器上，事情变得更糟，因为SQL充分利用了 NUMA 所在地但是没有其他进程通常不了解NUMA，并且尽管操作系统可以尝试保留分配的位置，但它们最终会分配整个物理RAM并降低系统的整体吞吐量，因为CPU在等待时空闲用于跨域边界页面访问。还有其他一些事情需要考虑，例如 TLB 和由于其他进程占用CPU周期导致的L2未命中增加。

A similar pattern happens with CPU scheduling where other processes steal CPU time from the SQL schedulers. On high end systems and on Opteron machines things get worse because SQL uses NUMA locality to full advantage, but no other processes are usually not aware of NUMA and, as much as the OS can try to preserve locality of allocations, they end up allocating all over the physical RAM and reduce the overall throughput of the system as the CPUs are idling on waiting for cross-numa boundary page access. There are other things to consider too like TLB and L2 miss increase due to other processes taking up CPU cycles.

总而言之，可以使用SQL Server运行其他服务器，但不建议这样做。如果必须，请确保将两台服务器隔离到最佳状态。使用 SQL和IIS / ASP的CPU关联掩码将两者隔离在单独的核心上，配置SQL以保留较少的RAM，以便为IIS / ASP留出可用内存，将应用程序池配置为积极回收防止应用程序池增长。

So to sum up, you can run other servers with SQL Server, but is not recommended. If you must, then make sure you isolate the two server to your best ability. Use CPU affinity masks for both SQL and IIS/ASP to isolate the two on separate cores, configure SQL to reserve less RAM so that it leaves free memory for IIS/ASP, configure your app pools to recycle aggressively to prevent application pool growth.

这篇关于我什么时候可以在同一台机器上托管IIS和SQL Server？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！