Questions tagged «performance»

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

1
更改“最大服务器内存”除了清除计划缓存并(显然)更改内存设置还有什么作用?
在32 GB内存和4个内核,60-80个并发连接上运行SQL Server 2012 SP3,同时具有很大的临时工作负载,我们看到SQL Server进程(CPU)高峰,并且每天在不可预测的时间高峰一次或两次。我们正在努力确定峰值的根本原因。同时,我们发现更改最大内存设置(向上或向下)似乎是使CPU负载恢复正常的唯一方法。 检查日志并搜索StackExchange(https://dba.stackexchange.com/a/183276),我们看到通过更改最大内存设置可以刷新计划缓存。但是,如果我们通过DBCC FREESYSTEMCACHE('SQL Plans')刷新计划缓存,则CPU负载不会恢复正常。 由于更改“最大内存”设置可以解决问题,无论天气如何增加或减少,该问题似乎都与“最大服务器内存”设置没有直接关系。因此,我们试图了解更改内存设置的其他作用,然后使用该信息来帮助确定CPU峰值的根本原因。

2
要分区还是不分区?
已经阅读了关于SO,外部博客文章和手册的几个问题 SO:Pg中分区表的外键约束 dba.SE:在Pg中处理FK到分区表的不同方法 手册:继承 手册:分区 手册:约束触发器 博客:具有继承性的Postgres建模 我仍然发现自己想知道是否应该考虑我的情况进行分区。 案例-简化 存储客户数据。为了清楚起见,下面提到的所有表名均已组成。 具有需要客户识别的非物理对象,以及需要将某些对象按需发送回客户或以其他方式进行处理的情况下,实际存储它们的物理对象。它们以多对多关系映射。objects_nonphysical,objects_physical,objects_mapping_table。 第二个多对多关系是这些非物理对象与其度量之间的关系。有些对象与某些指标绑定。metrics,metrics_objects_nonphysical 非物理对象和物理对象都有其子级关系表。objects_nonphysical_hierarchy,objects_physical_hierarchy 根据每个客户的需求和要求,可以提供有关物理对象的数据,或者可能需要从头开始创建。基本上,我需要做的是: 保持内部系统的快速运行INSERT和SELECT声明,因为这是要进行映射的地方。 维护系统以供外部客户查看和操作其非物理对象 -快速检索数据。报表高效性的需求SELECT -许多客户可以随时使用此数据进行搜索。 我的考虑 可以有一个客户,他们可以访问数据,查看数据并对其进行操作,但是不必是我们从中获取数据/正在处理数据的承包商。 考虑到我总是知道应该将哪些分区数据归入(针对承包商的分区),然后考虑到需要为客户进行分区的外部客户的维护系统,这导致我将表分区引入到我的系统中(某些情况下可以做到这一点)延迟使用自动化工具和一组规则以客户的方式重写数据,因此对于每个客户,我们只为每个表扫描一个分区。 数据量 我的数据将不断增长,尤其是在导入新客户的对象和指标时。从长远来看,目前无法预测新数据进入系统的速度。确实,没有知道谁将成为下一个客户,就无法衡量它。眼下正好有2客户提供更多或更少的1M行对每个表的每个客户。但是将来我预计新客户也将有1000万行左右。 问题 这些问题都是相互关联的。 应该在这里真正考虑分区,还是过大?我认为它很有用,因为我始终只扫描一个分区。 如果要进行分区,那么如何FK考虑到我的需求最有效地实施约束?我应该选择constraint triggers还是将其保留在内部系统的应用程序层中,或者使用其他方法? 如果无法进行分区,那我应该深入研究什么呢? 如果没有足够的数据,请在下面的评论中让我知道。

2
全文搜索速度慢,出现频率高
我有一个表,其中包含从文本文档中提取的数据。数据存储在名为"CONTENT"GIN 的列中,为此我创建了该索引: CREATE INDEX "File_contentIndex" ON "File" USING gin (setweight(to_tsvector('english'::regconfig , COALESCE("CONTENT", ''::character varying)::text), 'C'::"char")); 我使用以下查询在表上执行全文搜索: SELECT "ITEMID", ts_rank(setweight(to_tsvector('english', coalesce("CONTENT",'')), 'C') , plainto_tsquery('english', 'searchTerm')) AS "RANK" FROM "File" WHERE setweight(to_tsvector('english', coalesce("CONTENT",'')), 'C') @@ plainto_tsquery('english', 'searchTerm') ORDER BY "RANK" DESC LIMIT 5; “文件”表包含25万行,每个"CONTENT"条目均包含一个随机词和一个文本字符串,所有行均相同。 现在,当我搜索一个随机单词(整个表中有1个匹配项)时,查询运行非常快(<100毫秒)。但是,当我搜索所有行中都存在的单词时,查询运行非常慢(10分钟或更长时间)。 EXPLAIN ANALYZE显示对于1命中搜索,先执行位图索引扫描,再执行位图堆扫描。对于慢速搜索,将执行Seq扫描,这花费了很长时间。 当然,在所有行中都有相同的数据是不现实的。但是,由于我无法控制用户上载的文本文档,也无法控制用户执行的搜索,因此可能会出现类似的情况(搜索数据库中出现率很高的术语)。在这种情况下,如何提高搜索查询的性能? 运行PostgreSQL 9.3.4 查询计划EXPLAIN ANALYZE: …

6
创建SQL Server性能基准监视
为了获得概述和可比较的数据,我当前的任务是创建性能基准,以获取有关不同生产SQL Server实例的一些数据。 我的想法是: 我想使用几个DMV 我想包括一个探查器跟踪(包括执行计划) 我想包含性能数据 因此,我试图实现的是一个可启动和可停止(也可调度)的常规性能监视,该监视将返回: 识别正在进行的性能优化任务是否成功所需的所有信息 几个汇总的简单图形,有助于形象化长期进展。用于管理;-) 探查器跟踪中的可重新执行执行计划,以比较单个队列的更改和索引优化任务的改进 我发现了一些描述性能基准创建的信息。它们中的大多数要么非常复杂,要么仅关注所需的性能指标之一(主要是性能数据)。 最匹配的示例/描述如下:为SQL Server创建性能基准 问题是: 有没有人有以快速可行的方式创建这种性能监视器的经验?

1
CPU利用率低但信号等待时间高
我有一台具有16个CPU的服务器,该服务器配置max degree of parallelism为8且max worker threads设置为零。 在给定的一个小时内,我的信号等待时间为20%,但在此期间我的OS CPU利用率从未超过25%。有人可以解释为什么我的信号等待如此之高吗? 我的供应商拥有同类最佳的评分系统,希望我们的信号等待率不超过10%,否则我们会感到不高兴。我该如何解决此问题(不添加其他CPU)? 每个NUMA节点我们的CPU不超过8个,因此跟踪标志8048不适用。 最大实例等待量是CXPACKET(70%),然后是PREEMPTIVE_OS_PIPEOPS(20%) cost threshold for parallelism设置为50。我应该提高它吗?要什么? 这是专用于SQL Server的物理计算机(不是VM)。 我正在使用监视工具来识别最频繁运行的查询和过程。我要查看较高的CPU,较高的I / O或较高的持续时间吗?通常,我们的应用程序是I / O密集型的,因此我会调整高I / O。但是,由于问题是信号等待,我是否需要查看较高的CPU? 我希望避免将Max Vernon的建议降低MAXDOP到4,因为该应用程序会执行一些需要额外线程的仓库样式查询。

2
优化MySQL SELECT语句中TIMESTAMP字段的WHERE条件
我正在为一个跟踪使用时间的分析系统设计一个模式,并且需要查看特定日期范围内的总使用时间。 举一个简单的例子,这种查询类型将经常运行: select sum(diff_ms) from writetest_table where time_on > ("2015-07-13 15:11:56"); 在人口众多的表上,此查询通常需要7秒钟左右。它有约3500万行,运行在Amazon RDS(db.m3.xlarge)上的MySQL上的MyISAM。 摆脱WHERE子句可以使查询仅花费4秒,而添加第二个子句(time_off> XXX)则需要增加1.5秒,从而使查询时间达到8.5秒。 因为我知道通常会完成这些类型的查询,所以我想优化一些东西,使其更快,最好在5秒以下。 我从在time_on上添加索引开始,尽管它大大加快了WHERE“ =”查询,但对“>”查询没有影响。有没有一种方法可以创建可以加快WHERE“>”或“ <”查询的索引? 或者,如果还有其他建议可以查询此类查询的性能,请告诉我。 注意:我使用“ diff_ms”字段作为非规范化步骤(它等于time_off-time_on),这将聚合的性能提高了大约30%-40%。 我正在使用以下命令创建索引: ALTER TABLE writetest_table ADD INDEX time_on (time_on) USING BTREE; 在原始查询上运行“ explain”(使用“ time_on>”)时,time_on是“ possible_key”,而select_type是“ SIMPLE”。“额外”列显示“在何处使用”,“类型”为“全部”。添加索引后,该表显示“ time_on”是“ MUL”键类型,由于同一时间可以出现两次,因此这似乎是正确的。 这是表模式: CREATE TABLE `writetest_table` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, …

2
信任哪个?
我们正在解决与供应商长期存在的问题。他们的软件倾向于冻结并每周停止一次或两次工作,从而严重干扰我们的运营。尽管我们向他们发送了许多GB的日志和数据库备份,但他们无法确定原因。最近,他们开始暗示问题出在我们的维护上,而不是软件方面(尽管没有长期运行的查询,CPU / RAM / IO压力,甚至在出现问题时出现死锁)。特别是他们说我们的索引是一个问题。 尽管我认为MS不赞成使用该工具,但他们最喜欢使用的工具是DBCC showcontig。他们特别着迷于扫描密度和范围碎片。为了消除借口,我建立了一些积极的夜间维护措施,以小于90%的扫描密度或大于10%的碎片重建索引。这多少使它们脱离了扫描密度列,但是它们仍然专注于范围碎片。DBCC showcontig即使在几个小时之前重建的索引上也显示出高度碎片。下面是dbcc_showcontig和sys.dm_db_index_physical_stats的结果,它们指向的表是“可能的问题”。 DBCC SHOWCONTIG 已扫描的页面................................:1222108 扫描范围.....................:152964 范围开关.....................:180904 平均 每个范围的页数...........................:8.0 扫描密度[最佳计数:实际计数] ..:84.44%[152764:180905] 逻辑扫描碎片..................:3.24% 扩展扫描碎片....................:35.97% 平均 每页可用字节数.....................:692.5 平均 页面密度(完整).....................:91.44% sys.dm_db_index_physical_stats index_type_desc alloc_unit_type_desc Avg_fragmentation_in_percent page_count CLUSTERED INDEX IN_ROW_DATA 3.236803129 1222070 NONCLUSTERED INDEX IN_ROW_DATA 0.680074642 48230 NONCLUSTERED INDEX IN_ROW_DATA 0.093237195 48264 NONCLUSTERED INDEX IN_ROW_DATA 0.03315856 48253 NONCLUSTERED INDEX …

3
BLOB合并复制期间的高tempdb磁盘I / O
拥有用于复制BLOB(类型image)的合并发布,就我的数据量而言,tempdb磁盘I / O很高。发布是仅下载的,没有筛选器。 高磁盘I / O是由同步引起的(当没有订阅者进行同步时,一切正常),这与订阅者数量密切相关。即使同步之间在Publisher上没有任何数据更改,也会发生这种情况,这使我感到困扰。 复制表的大小:7MB(总行数约为100) tempdb I / O:写入速度约为30 MB /秒(日志和数据文件) 订户数量:略多于100个,每个订户每30分钟同步一次(或多或少均匀)。 保留期限设置为14天 在发布服务器上使用SQL Server 2008,在订阅服务器上使用SQL Server 2005-2008R2。所有订户都使用Web同步。 此外,在订户处进行同步需要花费大量时间,并且多次发生replmerg.log以下情况: DatabaseReconciler, 2015/04/21 12:13:40.348, 3604, 25088, S2, INFO: [WEBSYNC_PROTOCOL] Sending client ReconcilerPhase WebSyncReconcilerPhase_RegularDownload DatabaseReconciler, 2015/04/21 12:13:47.063, 3604, 25194, S2, INFO: [WEBSYNC_PROTOCOL] Received server ReconcilerPhase WebSyncReconcilerPhase_LastRegularDownload 尝试@stream_blob_columns打开和关闭设置无效。 该问题是:这是个好主意,用合并复制到这些斑点发送到用户?我们还有其他出版物(尽管它们没有BLOB列),其中包含大量数据,而没有tempdb问题。是SQL Server缺陷还是安装错误? 发布服务器和分发服务器位于同一实例SQL Server …

1
共享驱动器上的即时文件初始化
之前我曾问过类似的问题,但以前我曾问过有关将备份移到共享位置的问题。这次我很好奇:如果要还原共享驱动器上的数据库,是否需要在该服务器上或仅在运行SQL Server的服务器上启用IFI? 我问的原因是我正在还原一个非常大的数据库,并且在最近几个小时内一直处于100%恢复状态。等待类型sp_whoisactive为: (28472716ms) `PREEMPTIVE_OS_WRITEFILEGATHER. 我唯一看到的是未启用IFI的情况,但是我确实在SQL Server上启用了该功能,但在共享驱动器服务器上却未启用它。

4
我应该在什么时候拆分或分割一个很大但很简单的表
我们的网站上有一些大而简单的统计表(INT,INT,DATE)。每个表最多有300,000,000行,并且每天都在增加。 托管服务提供商建议我们拆分表或对表进行分区,而我在许多场合也看到了此建议。 然而... 我正在努力使建议与SQL Server的最大容量(数据库大小为524,272 TB)保持一致,而表行仅受“可用存储”限制。 根据这些数字,上述表格可以轻松地拥有数以百万计的行(10 等于 303的幂)。 啊哈,您可能会说,CAPABILITY和PERFORMANCE之间是有区别的。 但是,实际上在每个有关SQL Server性能的问题中,答案都是“这取决于表设计和查询设计”。 这就是为什么我问这个问题。桌子的设计再简单不过了。基于索引ID字段的简单count(*)操作查询也不能。

1
最新服务器上的性能降低
我们有几个生产中的数据库服务器,其中有四个具有非常相似的硬件配置。Dell PowerEdge R620,唯一的不同是2个最新的(购买和配置3个月前)具有RAID控制器v710、256GB RAM和CPU,是2个物理Xeon E5-2680 2.80GHz。旧版本(大约在1年前购买和配置)具有RAID控制器v700、128GB RAM并运行在第2台物理Xeon E5-2690 2.90GHz上。BIOS已更新,所有驱动程序已更新为最新版本,等等。所有正在运行的SQL Server 2008R2 Enterprise(SP1)已更新为最新CU和Windows 2012R2 Standard。两者都在200 GB SSD x5 RAID10上运行。每个数据库上仅运行一个数据库,使用调用SSIS程序包的作业进行同步。我们的系统管理员已进行了大量性能和压力测试,以确保我们没有任何硬件或网络遗漏配置或故障。不出所料,最新的表现出更好的性能结果。到目前为止,一切都很好。 在Kibana的屏幕截图中可以看到我们遇到的问题。黄色和橙色是2台较新的服务器(表上为6.7),在所有其他服务器之下。完全可见这2台新服务器的响应时间较慢。不仅如此,而且这2台服务器的负载也比2台旧服务器(表上的浅蓝色和深蓝色线-4,5)要少一些。 有几个监视脚本,用于收集有关性能计数器的信息。尽可能地利用DMV和第三个监视工具进行挖掘,我掌握了很多信息。但是这里应该有(ofc)我缺少的东西,因为我找不到这种较慢的响应时间的答案。 这两个最新的服务器使用的RAM较少,但是与其他较旧的服务器相比,这是可以预期的,因为它们的负载较低。 | Server Name| Mem_MB | Mem_GB | Server_RAM_GB | SQL_max_mem_GB| SQL_min_mem_GB | |------------|--------|--------------|---------------|---------------|----------------| | 4 | 41108 | 40.145263671 | 128 | 120 | 16 | | 5 | …

1
两台服务器中MySQL性能的巨大差异
我们有一个安装在两台不同机器上的MySQL服务器,分别是测试服务器和生产服务器,这两个窗口都是Web应用程序使用的窗口。 问题在于,执行某些查询时,两台计算机之间存在巨大的性能差异(生产服务器是速度较慢的服务器)。两台服务器中的MySQL版本相同,甚至配置文件也相同(唯一的区别是数据的路径以及生产服务器除了错误外不记录任何东西)。我所说的性能差异要大3或4个数量级(例如,测试服务器中的查询执行时间为0.2 s,而生产服务器中的查询执行时间为84 s)。 令人讨厌的查询大量使用了带有“ WHERE [...] IN [...]”的子句,据我所知,它们通常非常慢,应将其替换为JOIN。但是,我们使用的MySQL版本是5.6.19,它会自动优化那些查询,这就是为什么它们在测试服务器中能快速执行的原因(而且它们属于程序的一部分,我们无法更改,因此我们无法手动对其进行优化)无论如何)。 就像我说的那样,MySQL的安装和配置是相同的,因此对于问题可能出在哪里我一无所知。一方面,我怀疑这一定是某种配置问题,因为程序和DB相同,另一方面,由于配置相同,所以这没有意义。 服务器上的一些数据: 测试服务器: 英特尔酷睿2四核Q9400 @ 2.66GHz 8GB RAM Windows Server 2008 R2标准 生产服务器: 英特尔至强E5530 @ 2.40GHz 5GB RAM Windows Server 2012 R2标准 编辑:我忘了说一件重要的事情:还有更多的查询正在执行,这些查询使用“ WHERE ... IN”子句作为“违规”子句。它们在两台计算机上都可以快速执行,这表明我已经通过MySQL对其进行了优化。如果这是实际问题(我不确定),那么对某些查询进行优化(而不对其他查询进行优化)的事实对我来说是个谜。 编辑#2:这是两个服务器的配置文件:http : //pastebin.ca/2834906 编辑#3:这是慢速查询之一的解释:https ://mariadb.org/ea/v36zj EXPLAIN在测试和产品中完全相同。查询本身在这里:http : //pastebin.com/VXgBxXmt它已经使用自动格式化程序进行了格式化,因此可能不是很清楚。如您所见,它相当长且复杂。它不是手动生成的,而是由软件自动生成的,该软件使用标准SQL的方言和某些功能。 另外,更多信息:我们通过减少生产服务器中的数据并删除了数据库中将不使用的大多数旧数据来临时修补了该问题。当然,这不是解决方案,因为我们还需要旧数据,将来会成为问题。DB并不是那么大:完整的DB为1308MB,目前正在生产的精简版本为332MB。 更新:已解决? 我想我已经解决了问题。由于尚未使用生产服务器,因此我尚未对其进行测试,但是可能的问题是参数“ innodb_buffer_pool_size”,该参数设置为182M。实际上,配置文件中的行显示:innodb_buffer_pool_size = 321这是一个错误,因为它没有单位前缀,给出了无效的值(根据文档,最小值为5242880),然后将其置于先前的值。测试服务器中的该值设置为所需的321M。 如我所说,我还没有完全测试过。我所做的是降低测试价值并尝试应用程序。一切都变慢了,我发布的特定查询将在3分钟内执行。 …

1
请求使用SQL Server进行慢速DELETE的说明
我想对SQL Server删除行为获得一些额外的见解/理由。我们有一个相当大的数据库,超过1800 GB。 在其中有一些非常浅的表(只有几个整数列),具有数百万行。当我们从这些浅表中删除10,000行时,删除查询通常非常快(最多几秒钟)。 我们还有一个表,其中的类型字段image存储平均100 KB的图像。当我们仅从该表中删除几千行时,则需要一分钟多的时间。 尽管区别很明显(删除了更多的按大小分配的数据),但我还是渴望了解更多有关SQL Server内部发生的情况。这样我才能更好地理解后者的删除速度要慢得多。 谁能给我一些启示?

2
MySQL为什么要进行串行同步I / O?
当在MyISAM表上查看一个特别烦人的查询时,在许多情况下要花很长时间才能执行,我注意到MySQL似乎暴露出一种相当奇怪的I / O模式:执行单个查询时,必须要做很多事情I / O量(例如,对于表扫描或由于高速缓存而导致缓存为空,echo 3 > /proc/sys/vm/drop_caches因此需要首先从磁盘加载索引)时,基础块设备的队列大小接近于值1,而性能则极差仅4-5 MB / s: root@mysql-test:~# iostat -xdm 5 /dev/sda Linux 3.2.0-40-generic (mysql-test) 04/30/2014 _x86_64_ (4 CPU) Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.14 24.82 18.26 88.79 0.75 4.61 102.56 2.83 26.39 19.29 27.85 2.46 …

2
使用MAX分组,而不是MAX
我是一名程序员,正在处理一个具有以下方案的大表: UpdateTime, PK, datetime, notnull Name, PK, char(14), notnull TheData, float 上有一个聚集索引 Name, UpdateTime 我想知道什么应该更快: SELECT MAX(UpdateTime) FROM [MyTable] 要么 SELECT MAX([UpdateTime]) AS value from ( SELECT [UpdateTime] FROM [MyTable] group by [UpdateTime] ) as t 此表的插入是50,000行中具有相同日期的数据块。因此,我认为分组依据可能会简化MAX计算。 与其尝试查找最多150,000行,不如将其分组为3行,然后计算MAX会更快?我的假设是正确的还是分组依据也代价高昂?

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.