我什么时候可以在同一台机器上托管 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 使用操作系统资源的方式的性质.SQL Server 在名为 SQLOS 的用户模式内存管理和处理器调度基础结构上运行.SQL Server 旨在以最高性能运行，并假定它是操作系统上唯一的服务器.因此，SQL 操作系统为 SQL 进程保留机器上的所有 RAM，并为每个 CPU 内核创建一个调度程序，并为所有调度程序分配任务以运行，在需要时利用它可以获得的所有 CPU.因为SQL保留所有内存，其他需要内存的进程会导致SQL看到内存压力，并且对内存压力的响应将从缓冲池中驱逐页面，并从计划缓存中驱逐已编译的计划.由于 SQL 是唯一真正利用 内存通知 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 空闲等待用于跨 numa 边界页面访问.还有其他一些事情也需要考虑，例如 TLB 和 L2 未命中由于其他进程占用 CPU 周期而增加.

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屋！