blocks|key|3613169|text|几件事。首先，集群服务器不会给您带来任何性能上的好处，只会增加可用性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3613170|为了减轻磁盘I/O，您可以做的最简单的事情可能是增加服务器上的内存。随着更多的数据页存储在RAM中，运行查询所需的物理I/O减少了。|3613171|根据工作负载的不同，如果您有能力迁移到SAN，那么您可能想要将您的TempDB、日志和数据文件拆分到单独的物理磁盘上(您可能想看看这篇关于存储Server的十大最佳实践的MS文章：http://technet.microsoft.com/en-us/library/cc966534.aspx)。正如哈奇所指出的，离开RAID+5，特别是对于日志和TempDB，它们有大量的写入量(RAID+5对奇偶性有写惩罚)。|offset|length|3613172|正如Chopper3所说，FusionIO驱动器是目前最快的驱动器之一。如果您有他们的预算，这绝对是一个值得探索的领域(特别是对于您的TempDB)。|3613173|哈，丹|entityMap|0|LINK|mutability|MUTABLE|url|http://technet.microsoft.com/en-us/library/cc966534.aspx^0|0|0|2I|1K|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|U|8|@]|9|@$F|V|G|W|1|X]]|A|$]]|$1|H|3|I|5|6|7|Y|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|Z|8|@]|9|@]|A|$]]]|L|$M|$5|N|O|P|A|$Q|R]]]]

Couple of things. First off, clustering the server won't give you any performance benefit, only increase in availability.

Probably the easiest thing you can do to relieve disk I/O is to increase the memory on your server. As more of your data pages are stored in RAM, the less physical I/O that needs to happen for queries to run. 

Depending on your workload, if you can afford to move to a SAN, then you will probably want to look at splitting up your TempDB, logs, and data files onto seperate physical disks (you may want to look at this MS article around storage top 10 best practices for SQL Server: <a href="http://technet.microsoft.com/en-us/library/cc966534.aspx" rel="nofollow noreferrer">http://technet.microsoft.com/en-us/library/cc966534.aspx</a>). As Hutch stated, move off of RAID 5, especially for logs and TempDB, has these have high amounts of writes (RAID 5 has a write penalty for the parity).

As Chopper3 says, FusionIO drives are some of the fastest drives around currently. If you have the budget for them, that is definitely one area to explore (especially for your TempDBs).

HTH, Dan

blocks|key|3613111|text|将数据和日志移动到FusionIO驱动器，非常昂贵，但据我所知，您现在无法获得更快的持久存储。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3613112|哦，你应该移到2008R2+64位，当然，加上内存负载。|entityMap|0|LINK|mutability|MUTABLE|url|http://www.fusionio.com/products/^0|9|8|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@$A|N|B|O|1|P]]|C|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@]|C|$]]]|F|$G|$5|H|I|J|C|$K|L]]]]

Move your data and logs to a <a href="http://www.fusionio.com/products/" rel="nofollow noreferrer">FusionIO</a> drive, very very expensive but as far as I'm aware you can't get faster persistent storage right now.

Oh and you should move to 2008R2 64-bit too of course, plus load up on memory.

blocks|key|5911910|text|眼前一想到的事情就是把这个RAID5转换成RAID10或者一对RAID1+1‘S。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

The immediate thing that leaps to mind is to look into converting that RAID5 to a RAID10 or a pair of RAID1's.

blocks|key|5912172|text|这是一个很大的话题，但我可能可以提供一些提示，以帮助您开始。一般来说，我认为你说你需要收集更精确的信息，然后才能决定如何最好地解决你的问题。最后，它可能会归结为内存问题或磁盘问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5912173|(我将忽略查看运行缓慢的查询并试图找出是否有方法改进它们的可能性。这是一个大话题，但是使用查询分析器可以帮助您确定您是否丢失了一个索引或一个查询应该完全重写。)|offset|length|5912174|首先，我将使用工具来查看一些关键指标。Server性能计数器是查看的好地方。磁盘队列的统计数据也很能说明问题。应用程序(即Server)是否等待磁盘I/O来执行操作？如果是这样的话，那么您就知道需要升级磁盘(或者可能修复查询)。@Hutch是正确的，对于数据库服务器来说，RAID+10将提供比RAID+5更好的性能，但实际上只有在等待写入时才能发挥作用。一个RAID+5中的415K+RPM驱动器应该能够用一个像样的RAID卡处理相当合理的负载(当然，合理和/或体面的是相对的)。|5912175|我也会检查内存。服务器正在运行server+2000，所以我假设它是32位服务器操作系统。SQL+server实际上能够使用所有的内存吗？在32位系统上，您需要使用PAE来使用所有的6GB，即使这样，我相信SQL+server进程本身也只能增长到4GB。您可以使用像sysinternals这样的程序来查看实际使用了多少内存。您甚至可以查看Server“需要”多少内存--查看Server:+memory+Manager计数器(如果它们在2000年可用，则无法从头上记起)。|5912176|您还提到服务器正在运行IIS。如果在运行其他重载服务的服务器上运行memory，则可能需要手动配置应该使用多少内存。默认情况下，Server假设它位于专用服务器上，并试图动态分配尽可能多的内存；取决于IIS进程的需要，这可能不是件好事。在运行多个应用程序的服务器上，我通常喜欢通过将最小值和最大值设置为相同的值(例如，4GB、10+4GB等)，将Server配置为使用一定数量的RAM。|5912177|最后，您可以考虑升级Server。Server+2005在某些领域引入了一些大幅度的速度增强，根据您的设置可能会使您受益。更不用说，您可以获得server+2005/2008的64位版本，并在64位操作系统上运行它，从而为其提供更多的内存，而内存对于SQL服务器来说是迄今为止最重要的事情之一。|entityMap|0|LINK|mutability|MUTABLE|url|http://technet.microsoft.com/en-us/library/aa178417%2528SQL.80%2529.aspx|1|http://technet.microsoft.com/en-us/library/cc938959.aspx|2|http://technet.microsoft.com/en-us/library/cc966420.aspx|3|http://msdn.microsoft.com/en-us/library/aa366796%2528v=VS.85%2529.aspx^0|0|11|3|0|0|12|4|1|0|3|4|2|2A|3|3|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@$D|12|E|13|1|14]]|A|$]]|$1|F|3|G|5|6|7|15|8|@]|9|@$D|16|E|17|1|18]]|A|$]]|$1|H|3|I|5|6|7|19|8|@]|9|@$D|1A|E|1B|1|1C]|$D|1D|E|1E|1|1F]]|A|$]]|$1|J|3|K|5|6|7|1G|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1H|8|@]|9|@]|A|$]]]|N|$O|$5|P|Q|R|A|$S|T]]|U|$5|P|Q|R|A|$S|V]]|W|$5|P|Q|R|A|$S|X]]|Y|$5|P|Q|R|A|$S|Z]]]]

This is a huge topic, but I might be able to offer some tips to help you get started. In general I think it is safe you say that you will need to gather more precise information before you can decide how to best attack your problem. In the end it will probably come down to a memory issue or a disk issue.

(I'll ignore the possibility of looking at the queries that are running slowly and attempting to find out if there are ways to improve them. This is a <a href="http://technet.microsoft.com/en-us/library/aa178417%28SQL.80%29.aspx" rel="nofollow noreferrer">huge topic</a>, but using the query analyzer can help you to determine if you are missing an index or of a query should be completely rewritten.)

I would start out by using the Performance Administrative Tool to look at a few key metrics. The SQL Server performance counters are a good place to look. <a href="http://technet.microsoft.com/en-us/library/cc938959.aspx" rel="nofollow noreferrer">Disk queue</a> stats can also be very telling. Are applications (i.e. SQL Server) waiting on disk I/O to perform operations? If so, then you know that you will need to upgrade the disks (or fix the queries, possibly). @Hutch is correct that RAID 10 will offer better performance than RAID 5 for a database server, but really that is only going to come into play if you're waiting on writes. 4 15k RPM drives in a RAID 5 should be able to handle quite a reasonable load with a decent RAID card (of course what's reasonable and/or decent is relative).

I would also <a href="http://technet.microsoft.com/en-us/library/cc966420.aspx" rel="nofollow noreferrer">check the memory</a>. The server is running SQL Server 2000 so I will assume it's a 32-bit server OS. Is SQL server actually able to use all that memory? On a 32-bit system you'll need to use <a href="http://msdn.microsoft.com/en-us/library/aa366796%28v=VS.85%29.aspx" rel="nofollow noreferrer">PAE</a> to use all 6 GB, and even then I believe the SQL server process itself will only be able to grow to 4 GB. You can use a program like the sysinternals process explorer to look at how much memory is actually being used. You can even view how much memory SQL Server "wants" -- check out the SQL Server: Memory Manager counters (if they are available on 2000, can't remember off the top of my head).

You also mention that the server is running IIS. If you're running MS SQL Server on a server that's also running other heavily loaded services, you may want to look into manually configuring how much memory should be used. By default SQL Server assumes its on a dedicated server and tries to dynamically allocate as much memory as possible; depending on the needs of your IIS processes this may not be a good thing. On servers running multiple applications I usually like to configure SQL Server to use exactly a certain amount of RAM by setting the minimum and maximum to the same value (e.g. 4GB, 10GB, whatever).

Finally, you might consider upgrading SQL Server. SQL Server 2005 introduced some big speed enhancements in certain areas that might benefit you depending on your setup. Not to mention the fact that you can obtain a 64-bit version of SQL Server 2005/2008 and run it on a 64-bit OS to give it even more memory, and memory is by far one of the most important things for a SQL server.

blocks|key|3613383|text|这个话题需要一个巨大的“它取决于”的答案。虽然到目前为止发布的答案对于给定的条件是正确的，但是还有更多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3613384|是的，从RAID-5移到RAID-10是“立即做这件事”专栏中的一个巨大的检查标记，但是我们还没有被告知的部分呢？|3613385|考虑到这一点，我提出了以下内容:磁盘布局：|3613386|3613387|+What+files+are+on+what+drives?+++++++Where+is+the+TempDb+and+how+many+files+are+associated+with+TempDb+++++++Are+the+DB's+and+T-Logs+on+different+drives?|code-block|syntax|javascript|3613388|查询管理和优化：|3613389|3613390|+Have+the+heaviest+queries+been+identified+and+optimized?++How?+++++Are+the+Updates+causing+row+relocations+or+are+they+able+to+"Update+in-place"?+++++++Row+relocations+during+an+update+cause+all+sorts+of+performance+issues.+++++Index+management:++Are+the+needed+indexes+in+place+and+are+they+correctly+defined++++++++in+order+to+be+utilized+by+the+queries+which+need+them?+++++Index+rebuilds:+++++++Indexes+become+fragmented+over+time+and+need+to+be+reorganized+or+rebuilt.++Not+++++++doing+this+will+affect+performance.|3613391|环境:驱动器碎片会导致文件碎片。即使驱动器保持干净，对于任何DB或T-日志文件来说，大量的扩展也会产生负面影响。从SQL+2000升级到SQL+2005或(更好的)2008年或2008年的R2是一个很好的建议。在Windows+2008+x64或Windows+2008+R2+x64上运行是对本机6GB内存的补充。Server+2008和2008+R2有内置工具来帮助识别问题查询。在有压力的DBA环境中，这是值得升级的。驱动器控制器缓存内存:足够吗？多个逻辑驱动器之间是否共享缓存？|3613392|资源竞争(压力)：|3613393|3613394|+Besides+IIS,+what+other+processes+on+the+SQL+Server+system+are+competing+for+the++++++system's+resources?|3613395|添加SAN并不是一个坏主意，但是您需要了解环境。了解是否由于表扫描、不正确的外键管理、更新过程中的行重定位、其他一些问题或“所有这些”而导致性能下降是非常重要的。不知道根本原因(S)意味着增加一个三只将只是一个暂时的恩惠。另外，要正确调整SAN的大小，必须了解您的环境--这不仅关系到可用的磁盘空间。|3613396|我不知道你的环境，也不能给出一个合理的答案，你应该做什么；我上面的清单也确实是一个主题的小贴士，许多有思想的书籍已经投入使用。|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|14|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|16|8|@]|9|@]|A|$J|K]]|$1|L|3|M|5|6|7|17|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|18|8|@]|9|@]|A|$]]|$1|O|3|P|5|I|7|19|8|@]|9|@]|A|$J|K]]|$1|Q|3|R|5|6|7|1A|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1B|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|V|3|W|5|I|7|1D|8|@]|9|@]|A|$J|K]]|$1|X|3|Y|5|6|7|1E|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1F|8|@]|9|@]|A|$]]]|11|$]]

This topic needs a huge "It Depends" for the answer. While the answers posted so far are good and correct for given conditions, there is so much more. 

Yes, moving off of RAID-5 to RAID-10 is a huge check-mark in the "Do this now" column, but what about the pieces we have not been told?

Thinking about this, I come up with the following items:
 Disk layout: 
 What files are on what drives?
 Where is the TempDb and how many files are associated with TempDb
 Are the DB's and T-Logs on different drives?

Query management and optimization: 
 Have the heaviest queries been identified and optimized? How?
 Are the Updates causing row relocations or are they able to "Update in-place"?
 Row relocations during an update cause all sorts of performance issues.
 Index management: Are the needed indexes in place and are they correctly defined 
 in order to be utilized by the queries which need them?
 Index rebuilds:
 Indexes become fragmented over time and need to be reorganized or rebuilt. Not
 doing this will affect performance.

Environment:
 Drive fragmentation can lead to file fragmentation. Even when the drive is kept 
 clean, a large number of extents for any DB or T-Log file has a negative effect.
 Upgrading from SQL 2000 to SQL 2005 or (better yet) 2008 or 2008 R2 
 is a great suggestion.
 Running on Windows Server 2008 x64 or Windows Server 2008 R2 x64 complements the 
 6GB of memory in natively.
 SQL Server 2008 and 2008 R2 have built-in tools for helping to identify problem
 queries. In a stressed environment with a stressed DBA, this is worth the upgrade.
 Drive Controller Cache Memory:
 Is it sufficient? Is the cache shared between multiple logical drives? 

Resource competition (pressure): 
 Besides IIS, what other processes on the SQL Server system are competing for the 
 system's resources?

Adding a SAN is not a bad idea, but you need to understand the environment. Knowing if the cause of your performance speed-bumps is due to table-scans, improper foreign-key management, row-relocation during update, some other issue, or "all of the above" is very important. Without knowing the underlying cause(s) means the addition of a SAN will only be a temporary boon. Also, knowing your environment is mandatory for the proper sizing of a SAN -- It is not only about the availabe dise-space.

I do not know your environment and could not give a reasonable answer as to what you should do; also my above list is really the tip of a topic to which many thoughtful books have been dedicated.

I am having some disk access issues on a web application.

The main load is many concurrent inserts/updates/selects on large tables.

It is currently a single 2ru rackmount running SQL Server 2000 and IIS, running a raid5 with 4x15k SAS for the DB; and 6GB of ram/8 physical cores. CPU and memory usages seem fine.

Things i'm considering....

<ul>
<li>move from our current Raid to a many disk SAN </li>
<li>Ram Drive for tempdb files </li>
<li>Cluster the server</li>
<li>Upgrade SQL-Server (Will happen eventually regardless; but handy new keywords should help much at the very least)</li>
<li>?</li>
</ul>

Anything I should be looking at/considering?

Thanks,
 Chris

Best way to improve disk performance (SQL Server 2000)

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我在一个web应用程序上有一些磁盘访问问题。主要负载是大型表上的许多并发插入/更新/选择。它目前是运行Server 2000和IIS的单个2ru rackmount，运行的raid5为DB具有4x15kSAS；以及6GB的ram/8物理核。CPU和内存的使用似乎很好。我正在考虑的事情..。从当前的Raid转移到多个磁盘SAN用于tempdb文件的Ram驱动器集群服务器升级Server(无论如何都会

问提高磁盘性能的最佳方法( Server 2000)
EN

回答 5

Server Fault用户

Server Fault用户

Server Fault用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问提高磁盘性能的最佳方法( Server 2000)EN

回答 5

Server Fault用户

Server Fault用户

Server Fault用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问提高磁盘性能的最佳方法( Server 2000)
EN