Questions tagged «performance»

对系统是否运行良好以适合目标的评估。通常,性能是指系统随时间完成一个或一组操作的速度。

2
我应该在SQL Server中嵌套依赖的外部联接吗?
我听说过与此相关的信息不一,并希望能提出规范或专家意见。 如果我有多个LEFT OUTER JOIN,每个都依赖于最后一个,嵌套它们会更好吗? 对于一个人为的示例,JOINto MyParent取决于JOINto MyChild:http : //sqlfiddle.com/#!3/31022/5 SELECT {columns} FROM MyGrandChild AS gc LEFT OUTER JOIN MyChild AS c ON c.[Id] = gc.[ParentId] LEFT OUTER JOIN MyParent AS p ON p.[id] = c.[ParentId] 与http://sqlfiddle.com/#!3/31022/7相比 SELECT {columns} FROM MyGrandChild AS gc LEFT OUTER JOIN ( MyChild AS c LEFT …

1
IO_STALL的问题和理解
我每5分钟从sys.dm_io_virtual_file_stats中收集IO_STALLS,然后做一个增量查看哪些文件受IO影响最大。 在5分钟内,我得到了5826331毫秒的增量,即97分钟。 我对此有些困惑,这是说一次操作开始于97分钟之前才刚刚完成,因此记录了等待时间吗? 谢谢 根据要求添加了代码: /* USE [SysDBA] GO */ /****** Object: Table [dbo].[DISKIOPS] Script Date: 04/07/2013 11:40:15 ******/ /* DROP TABLE [dbo].[DISKIOPS] GO */ --Create the table /****** Object: Table [dbo].[DISKIOPS] Script Date: 04/07/2013 11:40:15 ******/ /* SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO SET ANSI_PADDING ON GO …

1
行为异常DBCC Shrinkfile
我正在尝试对其中95%的数据已被存档和删除的数据库运行1GB的dbcc收缩文件。我用的是235GB的文件,其中9GB是数据/索引。我想缩小到50GB。我知道收缩数据库文件是不好的,它会导致碎片等。作为数据清除/收缩的一部分,我们还有一个重建idnex脚本。 当我在自己的工作站(四核,12GB RAM,2个SATA驱动器)上对数据库运行dbcc收缩文件脚本时,收缩过程大约需要8-10分钟。 当在数据库发布后数据清除的相同副本上运行相同的代码时,在我们的测试环境(80多个核,128GB RAM,SSD SAN)中,需要70分钟。请注意,运行收缩文件时,此服务器上几乎没有活动。它已运行4次,结果相同。 然后,我采取了另一种方法,将剩余的9GB移动到另一个文件组和物理文件。在空的230GB文件上运行dbcc收缩文件以将其缩减到50GB,在我自己的工作站上花费的时间不到1分钟。 使用相同的方法,在测试环境上,又需要70分钟以上的时间。 在测试环境运行70分钟的过程中,按照布伦特·奥扎尔(Brent Ozar)的脚本操作前后,我已经对waitstats进行了快照,并且返回的waittypes值得关注。下面的前3行: 秒采样时间采样持续时间(以秒为单位)wait_type等待时间(秒)等待次数平均每次等待的毫秒数 2013-05-28 11:24:22.893 3600 WRITELOG 160.8 143066 1.1 2013-05-28 11:24:22.893 3600 CXPACKET 20.9 13915 1.5 2013-05-28 11:24:22.893 3600 PAGELATCH_EX 11.1 443038 0.0 Windows事件日志显示没有异常。在这一点上,我要抓挠,为什么与独立工作站相比,忍者硬件要花这么长时间。

5
为什么乐观锁定比悲观锁定快?
两种形式的锁定都会导致一个进程等待记录的正确副本(如果该记录当前正被另一个进程使用)。使用悲观锁定,锁定机制来自数据库本身(本机锁定对象),而使用乐观锁定,锁定机制是某种形式的行版本控制,例如时间戳,用于检查记录是否“陈旧”。 但是,两者都会导致第二个进程挂起。所以我问:为什么乐观锁定通常比悲观锁定快/优?并且,在某些用例中,悲观胜于乐观吗?提前致谢!

1
Amazon RDS MySQL 5.5 Innodb Lock超过等待超时
自从移至Amazon RDS以来,我们就遇到了一些非常疯狂的性能问题,而今天我们开始遇到锁定问题。因此,我认为这只是超时问题,因此检查了我们使用的内存。我们交换了大约70MB的内存。我用mysqltuner进行了一次内存巫婆搜索,它说最大可能的内存使用率为400%。现在,由于Percona的配置向导,我将其降低到100%以上。 但是,我们仍然存在此锁定问题,因此我假设它与内存/交换无关。为什么我仍然收到停工通知?这里发生了什么? 我相信重新启动可以解决问题,但这不应该是解决方案。将来我们可以做些什么来防止这种情况发生?我尝试刷新查询缓存和表-起作用了。 多亏了RDS:/ 我可以提供以下大量信息: 查询 INSERT INTO `myTable` (`firstName`, `lastName`, `email`) VALUES ('Travis', 'B...', '...@gmail.com') 错误信息 Lock wait timeout exceeded; try restarting transaction 表架构 CREATE TABLE IF NOT EXISTS `myTable` ( `id` int(15) NOT NULL AUTO_INCREMENT, `firstName` varchar(255) COLLATE utf8_unicode_ci NOT NULL, `lastName` varchar(255) COLLATE utf8_unicode_ci NOT NULL, …


2
慢的性能将几行插入到巨大的表
我们有一个流程,该流程从商店获取数据并更新公司范围的库存表。该表按日期和项目列出了每个商店的行。对于拥有许多商店的客户,此表可能会非常大-大约5亿行。 随着商店输入数据,此库存更新过程通常一天运行多次。这些运行仅更新来自少数商店的数据。但是,客户也可以运行此程序以更新例如过去30天中的所有商店。在这种情况下,该过程启动了10个线程,并在一个单独的线程中更新了每个商店的库存。 客户抱怨该过程需要很长时间。我已经概要分析了该过程,发现一个将INSERTs插入此表的查询所消耗的时间比我预期的要多得多。该插入有时会在30秒内完成。 当我对此表运行临时SQL INSERT命令(由BEGIN TRAN和ROLLBACK绑定)时,临时SQL完成的时间大约为毫秒。 执行缓慢的查询如下。这个想法是插入不存在的记录,然后在我们计算各种数据位时更新它们。该过程的上一步已确定了需要更新的项目,进行了一些计算,并将结果填充到tempdb表Update_Item_Work中。此过程在10个单独的线程中运行,并且每个线程在Update_Item_Work中都有其自己的GUID。 INSERT INTO Inventory ( Inv_Site_Key, Inv_Item_Key, Inv_Date, Inv_BusEnt_ID, Inv_End_WtAvg_Cost ) SELECT DISTINCT UpdItemWrk_Site_Key, UpdItemWrk_Item_Key, UpdItemWrk_Date, UpdItemWrk_BusEnt_ID, (CASE UpdItemWrk_Set_WtAvg_Cost WHEN 1 THEN UpdItemWrk_WtAvg_Cost ELSE 0 END) FROM tempdb..Update_Item_Work (NOLOCK) WHERE UpdItemWrk_GUID = @GUID AND NOT EXISTS -- Only insert for site/item/date combinations that don't …

2
如何获得视图的执行计划?
我有一个带有多个视图的架构。我需要检查执行计划,以确保适当的索引到位并正在使用。 我该怎么做呢? 我宁愿不必复制输出并将其粘贴show create view <viewname>到中explain,尤其是因为某些视图是建立在其他视图之上的,这会很痛苦。

3
mysql花费太长时间发送数据
我有一个简单的表,其中包含数百万个记录(14,000,000),而对于一个简单的查询,它花费了太多的时间“发送数据”。 桌子 CREATE TABLE IF NOT EXISTS details ( id int(11) NOT NULL, date date NOT NULL, time int(2) NOT NULL, minutes_online decimal(5,0) NOT NULL, minutes_playing decimal(5,0) NOT NULL, minutes_chatting decimal(5,0) NOT NULL, minutes_away decimal(5,0) NOT NULL PRIMARY KEY (id,date,time) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci; 简单查询 mysql> SELECT * FROM …

4
TempDB上的DDL争用
我有一个SQL Server 2005 Standard x64,在过去的几个月中,TempDB DDL争用一直遇到问题。服务器将在等待资源2:1:103(等待类型为PAGELATCH_EX)上发生争用。 当服务器处于正常负载时,该问题似乎偶尔发生。我一直在监视“销毁临时表”的速率,在我们在2:1:103遇到PAGELATCH_EX问题时,它的速率可能会跳到5,000+。根据我的阅读,该计数器在大多数情况下应该为0,但在大多数情况下,我们的计数器似乎保持在300-1100之间。仅当系统上用户很少时,计数器才会变为0。 我如何缩小在tempdb上导致DDL争用的原因,而不必在干草堆中寻找针头?

3
MySQL高性能,适用于许多SELECT / INSERT / UPDATE / DELETE
我正在创建一个模块,其中每个用户经常在10到300秒内将记录插入表中。 时间到时,记录将被删除。情况是:会有很多用户,记录会经常更改-这将如何影响此表的应用程序性能,因为记录会经常更改,我想知道mysql是否适合呢?就像索引会来来去去一样,此特定表的数据更改速度约为200次/秒。也许我正在为这种工作选择一个不好的解决方案。有什么建议么 ? 谢谢!

4
如何进一步优化此MySQL查询?
我的查询要花特别长的时间(15+秒),并且随着时间的推移,随着数据集的增长,查询只会变得越来越糟。我过去对此进行了优化,并添加了索引,代码级排序和其他优化,但是还需要进一步完善。 SELECT sounds.*, avg(ratings.rating) AS avg_rating, count(ratings.rating) AS votes FROM `sounds` INNER JOIN ratings ON sounds.id = ratings.rateable_id WHERE (ratings.rateable_type = 'Sound' AND sounds.blacklisted = false AND sounds.ready_for_deployment = true AND sounds.deployed = true AND sounds.type = "Sound" AND sounds.created_at > "2011-03-26 21:25:49") GROUP BY ratings.rateable_id 查询的目的是让我获得sound id以及最近发布的声音的平均评分。大约有1500种声音和200万种评级。 我有几个指数 sounds …

2
在Server Management Studio中显示查询计划
另一个SQL Server问题:自计数器重置以来,我有一个简单的查询,该查询为我提供了最多CPU密集型SQL: select top 10 sum(qs.total_worker_time) as total_cpu_time, sum(qs.execution_count) as total_execution_count, qs.plan_handle, st.text from sys.dm_exec_query_stats qs cross apply sys.dm_exec_sql_text(qs.plan_handle) as st group by qs.plan_handle, st.text order by sum(qs.total_worker_time) desc 问题1:究竟是什么plan_handle?它似乎不是计划的哈希,就像在Oracle中一样。我问是因为我希望能够发现陈述计划发生变化的情况。 问题2:一旦有了plan_handle,我会对实际计划感兴趣。因此,例如: select * from sys.dm_exec_query_plan (0x060006001F176406B8413043000000000000000000000000) 在query_plan列中,我获得了一个链接,单击该链接可显示XML文档。如果将它保存为磁盘上的what.sqlplan,则可以在Windows中双击它,并在Management Studio中正确显示。肯定有某种方法可以避免此步骤吗? 问题3:有没有办法像过去的SET SHOWPLAN_TEXT一样将XML转换回文本格式?我希望能够以图形方式查看它们,还希望以某种有意义的方式自动对它们进行比较。 谢谢!

2
如何有效地实现分页?
我有一个数据库查询,可能会导致结果集很大。显示数据的客户端通过网络接收数据,因此,其想法是通过仅从数据库中检索前50个结果并将其发送给客户端,以最大程度地减少传输的数据量。然后,我将提供一个可能性,跳到第二页以检索下一个50个结果,等等(类似于Google提供的内容) 问题是实现分页的有效方法是什么。我想确保mssql尽可能多地使用缓存,并且每次更改分页时都不会再次执行该缓存。 同时有更多客户端正在查询数据库。使用的SQL引擎:MS SQL 2005 我的想法是: 使用准备好的sql statemenst以确保执行计划共享 使用ROW_COUNT变量仅检索所需的行 但这真的是最有效的方法吗?还是您认为最好检索整个结果集并在将数据发送到客户端的代码中实现分页? 谢谢您的提示! 问候,托马斯

3
多个Oracle实例-这是一个好习惯吗?
我的一位客户将我们产品的数据库部署到了已经有3个Oracle实例的Solaris计算机上。因此,现在有4个Oracle实例在同一台计算机上运行。现在,我们遇到了性能问题。 我无权访问其他实例或计算机,并且我拥有的所有工具都是alert.log,AWR和ADDM。我知道有些情况与多个实例有关,但我无法证明这一点。 所以,我的问题是,您是否遇到过类似情况?我应该如何处理?如何确定与多个实例相关的性能问题的原因?

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.