Questions tagged «performance»

有关服务器硬件和软件性能或网络性能的问题。

3
始终* 100%加载处理器内核有危险吗?
我打算在我的HFT软件中使用一个核心进行股票指数计算。那将是while(true)没有任何延迟的简单循环,它将尽可能频繁地(每秒数百万次)计算(求和和乘)分量,我计划每天执行8个小时。 我从来没有每天将计算机加载到100%全日制状态。可能很危险吗?处理器是否具有某种“资源”(当然很大),之后它才能停止工作?

3
邮政管理员使用过多的CPU和磁盘写入
使用PostgreSQL 9.1.2 我看到过多的CPU使用率以及来自邮局主管任务的大量磁盘写操作。即使我的应用程序几乎什么也不做(每分钟10次插入),也会发生这种情况。但是,有相当数量的连接打开。 我一直在尝试确定导致应用程序崩溃的原因。我对Postgresql相当陌生,到目前为止还没有到位。我在配置文件中打开了一些日志记录选项,并查看了pg_stat_activity表中的连接,但是它们都处于空闲状态。但是,每个连接消耗约50%的CPU,并且正在以每秒15M / s的速度向磁盘写入数据(不读取内容)。 我基本上是通过很少的调整来使用stock postgresql.conf。我将不胜感激,对我可以做些什么来寻求帮助。 这是top / iotop向我显示的示例: Cpu(s): 18.9%us, 14.4%sy, 0.0%ni, 53.4%id, 11.8%wa, 0.0%hi, 1.5%si, 0.0%st Mem: 32865916k total, 7263720k used, 25602196k free, 575608k buffers Swap: 16777208k total, 0k used, 16777208k free, 4464212k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND …

2
iSCSI / NFS性能非常差的故障排除策略
我们有一个新的Synology RS3412RPx,它为三个Windows 2008 R2盒提供iSCSI目标,为一个OpenBSD 5.0盒提供NFS。 使用ssh登录到RS3412并使用dd和各种块大小读取/写入小文件和6GB文件均显示出出色的磁盘I / O性能。 在iSCSI / NFS客户端上使用dd或iometer,我们可以达到20Mbps(不是错字。二十Mbps)。我们有点希望在Synology中更好地利用多个Gbit NIC。 我已验证交换机和NIC端口配置已设置为千兆位,而不是自动协商。我们已经尝试过和不使用巨型帧,两者之间没有差异。我通过ping验证了MTU当前为9000。已部署了两个固件升级。 我将尝试在iSCSI目标和启动器之间建立直接链接以排除交换机问题,但是我还有其他选择吗? 如果我中断了wireshark / tcpdump,我会寻找什么?

2
使用缓存时磁盘I / O较高?
几天前,我注意到磁盘I / O等待和磁盘活动下降(这很棒)。然后我还注意到我的缓存已满(*)且碎片化。然后我刷新了缓存。此后,磁盘延迟和磁盘活动跃升到以前的水平(这很糟糕)。 IOtop显示[jbd2 / sda2-8]和[flush-8:00]始终位于磁盘使用率之上。这是具有大量可用内存(总共16 GB,其中约8 GB是缓冲区/缓存)的Dell R210,硬件RAID 1(H200)。 (*)缓存是PHP的APC操作码缓存,它减少了PHP脚本执行的磁盘访问。缓存已满并且分散,因为它包含来自开发实例的文件。当我注意到时,我将它们过滤掉了。 问题是:为什么磁盘I / O从理论上讲应该减少?以下是穆宁的一些图表。从2月6日到8日,缓存已满。 在我注释掉apc.mmap_file_mask后,按照@ cyberx86的说明进行更改 几天后https://serverfault.com/a/362152/88934

2
日志记录会损害MySQL的性能-但是,为什么呢?
我很惊讶我在网站上的任何地方都没有找到答案,也没有在MySQL文档中找到答案(5.2节似乎已经很好地记录了日志!) 如果启用binlog,我会发现(主观地)性能受到较小的影响,这会带来一些额外的IO,但是,当我启用常规查询日志时,就会看到巨大的性能影响(运行查询的时间增加了一倍,甚至更糟),远远超过了我在二进制日志中看到的内容。当然,我现在正在记录每个SELECT以及每个UPDATE / INSERT,但是其他守护程序会记录其每个请求(Apache,Exim),而不会停顿。 在IO方面,我只是刚刚看到接近性能“临界点”的影响,还是在日志记录查询中从根本上造成某种困难呢?我希望能够记录所有查询以简化开发,但是我无法证明那种感觉是我们需要通过常规查询登录来恢复性能的硬件。 我确实会记录慢速查询,并且如果禁用此功能,则一般用法的改进可以忽略不计。 (所有这些都是在Ubuntu 10.04 LTS,MySQLd 5.1.49上进行的,但研究表明这是一个相当普遍的问题)

4
一台Apache服务器上有多少个域?
我在一台Apache服务器上为我的客户托管约300个域。它们都没有太多流量,因此服务器负载不是问题。 从理论上讲,服务器上可以有多少个此类低流量域,但我担心,如果服务器上的域过多,用于检查每个传入请求的大量域会减慢Apache的运行速度下。 有一个经验法则,Apache配置可以使用多长时间,并且可以处理多少个不同的域?500可以吗?5000? 澄清:我不是在问服务器可以处理多少流量。我知道这台特定的服务器至少可以处理两倍于当前流量的数据。我想知道域的数量是否是关键因素。

2
是否有一种标准方法可以从客户机OS内对Windows VM性能进行基准测试?
我们看到我们的软件在一个正在Windows 2008虚拟机中运行的客户中表现异常。主机是VMWare ESX Server。 我看到的最大问题是我们的进程丢弃套接字连接或套接字连接超时。我们的某些进程通过TCP套接字相互通信。在某些情况下,我们建立与远程系统的套接字连接(例如WMI,JDBC)。 我被认为是VM缺乏资源。我们无权访问ESX管理/性能仪表板。我还了解到,主机VM内perfmon或任务管理器提供的任何数字都不是主机OS运行状况的真实指示。 我可以编写一个程序,执行一堆浮点数学运算并打印出所用的时间。然后将该时间与在不同VM或实际Windows机器上获得的时间进行比较。 这种方法足以让我们确定根本原因是否确实是VM性能。但是,如果有一种标准的方法或工具可以使客户信服,那就容易得多。 有一个吗?

7
C:\用于操作系统,D:\用于数据?
“回到过去”,我们始终将操作系统驱动器(在Windows中)与数据驱动器分开。在Linux世界中,尽管我不太熟悉它,但是我知道,智慧决定了在最佳实践配置中定义和使用的卷甚至更多。 既然服务器存储很可能位于SAN(磁盘资源由许多单独的操作系统和应用程序共享)上,那么将OS和Data分区在卷级别上分离是否真的重要吗? 你怎么看?


6
如何识别大量写入磁盘?
服务器运行CakePHP应用程序时出现此问题。服务器异常缓慢,我首先以为这是应用程序问题,但随后我发现以5-6MB / s的速度不断写入磁盘。 查找如此大量写入原因的最简单方法是什么? 服务器正在运行Gentoo。

3
为文件共享使用较大的NTFS磁盘分配大小是否有所不同?
我正在使用NTFS格式化驱动器,该驱动器将专门用作文件共享,以便用户集中存储其文件。文件可能很大(10到100兆字节)。 有人建议使用比默认4k(例如64k)大的分配单元大小将使其性能更好。我想我了解它的基本原理,但是我不确定它在实践中是否有效。这是否真的会有所作为,或者这可能会导致更多问题而不是解决?

2
Azure虚拟机上的磁盘性能降低
好的,首先,我要说我不是操作人员,而是开发人员。所以我要进入这里一片未知的土地,所以请多多包涵。 我想使用Azure虚拟机从1.9 GB的zip文件中提取50 GB的XML文件。因此,我一直在测试我应该使用Azure上的哪种实例大小来获得良好的性能,同时又不会支付超出所需的费用。 但是,Azure VM的磁盘性能并没有达到惊人的水平,我想知道是我做错什么了,还是可以预期的结果。 首先,我一直在测试什么?我有一个自定义.NET控制台应用程序,除了将zip文件作为参数外,它什么也不做,并立即开始将zip文件解压缩到该zip文件所在的目录中。在进行提取时,该应用程序会计算多少兆字节应用程序已每秒写入目标文件并输出。 在我的本地开发机器上,此应用程序的写入速度达到160-210 MB / s,因此性能非常好。因此整个提取过程大约需要8分钟。我本地计算机的规格是Intel Core i7 950、3 GHz,4核(8逻辑),12 GB RAM,Samsung SSD 830系列250 GB。 好的,所以我开始测试不同的实例大小,这是我的结果。 在具有Windows Server 2012 Datacenter R2(8核,14 GB RAM)的A4实例上,使用相同的存储帐户在没有主机缓存的情况下使用4个虚拟磁盘进行条带化RAID,我得到了稳定的30-35 MB / s,这意味着提取花费了24分48秒。我还尝试了启用主机缓存,但实际上并没有任何区别。 在具有Windows Server 2012数据中心(8核,28 GB RAM,500 GB本地SSD磁盘)的D4实例上,我在开始的几分钟内获得了非常好的性能(150+ MB / s),然后以200 MB / s和山谷速度为9 MB / s。平均性能在70到100 MB / s之间。提取耗时9分40秒。 在具有Windows …

1
对Redmine(Bitnami Stack)性能进行故障排除
我有一个Redmine实例(Bitnami Stack),它异常缓慢。因为我只是想深入了解这一点,所以我想在这里讨论一些理论。因此,如果有人对此有任何想法,请随时提供帮助:-) 系统: 带有Redmine 1.4.x的Bitnami Stack已升级为带有Redmine 2.1.0的Bitnami Stack,如下所示: mysqldump'd旧数据库 用Redmine 2.1.0安装了新的Bitnami Stack 通过重新创建所有表干净地导入转储 耙db:migrate等 堆栈在具有OpenSUSE 12.1的虚拟机上运行。资源应该没有问题,因为总是有数GB的可用RAM,并且Redmine请求上的CPU峰值仅占2个CPU内核的50%。另外,只有少数用户访问它。 可能完全重要:通过LDAP(ActiveDirectory)处理用户登录。 问题: 在每次请求时,Redmine反应异常缓慢。有时需要3秒,有时甚至需要10秒才能交付页面。 我的想法: 我不知道Redmine的LDAP设置中是否选中了“即时创建用户”,所以我只能在今天晚些时候进行检查。但是,这里缺少支票会成为问题吗?正常登录并确认身份验证时需要花一点时间。但是,当不动态创建用户时,它是仅保留会话还是针对每个请求重新进行身份验证,所以可能是问题所在? Redmine 2.x可能比1.4.x慢得多,以至于完全正常吗? Bitnami的Apache2 + Passenger配置是否存在错误? 考虑到MySQL在CPU上非常平静,MySQL索引不会成为问题,不是吗? 另一件事对我来说似乎很奇怪,但是可能是错误的测量结果(明天我看到机器时需要重新检查): 我试图检查这是否是网络问题(网络反应缓慢,可能是DNS或其他原因;服务器在本地网络中)。似乎在本地主机(直接在OpenSUSE VM上浏览器)上的请求很快,但是通过网络的请求却没有。通常,我会想到一个网络问题,但奇怪的是:实际测量连接时间时,网络的运行速度极快。Ping很好,静态交付时间也是如此。看来只有Redmine端计算出的页面是由应用服务器缓慢发送的,而Apache仍然是快速的-但仅在请求是远程LAN请求时才发送。非常奇怪……但是如上所述,我必须重新检查一下。对我来说似乎不合逻辑。

3
在Linux突袭5上mkfs操作花费很长时间
我已经设置了一个Linux软件突袭级别5,该级别由4 * 2 TB磁盘组成。创建的磁盘阵列的条带大小为64k,没有其他配置参数。初始重建后,我尝试创建一个文件系统,此步骤耗时很长(大约半小时或更长时间)。我尝试创建一个xfs和ext3文件系统,两者都花了很长时间,使用mkfs.ext3我观察到以下行为,这可能会有所帮助: 编写索引节点表的速度很快,直到达到1053(〜1秒),然后写入大约50,等待两秒钟,然后再写入下50(根据控制台显示) 当我尝试用Control + C取消操作时,它挂了半分钟才真正取消 单个磁盘的性能非常好,我已经分别在每个磁盘上运行bonnie ++,其读/写值约为95 / 110MB / s。即使当我在每个驱动器上并行运行bonnie ++时,其值也仅减少了约10 MB。因此,一般来说,我不将硬件/ I / O调度作为问题源。 我为stripe_cache_size和预读大小尝试了不同的配置参数,但没有成功,但是我认为它们与文件系统创建操作无关。 服务器详细信息: Linux服务器2.6.35-27-通用#48-Ubuntu SMP x86_64 GNU / Linux mdadm-v2.6.7.1 有没有人对如何进一步调试提出建议?

2
pg_restore比pg_dump花费更长的时间
我定期保存并稍后还原用于测试的较小的PostgreSQL数据库。测试会定期更新其数据,然后必须进行新的转储,并定期使用转储以良好定义的状态重新创建数据库。 我注意到转储(使用pg_dump -Fc database)仅需花费几秒钟,而还原(pg_restore -d database)则需要大约一分钟。这看起来很奇怪。我本来希望这两个过程都花费大约相同的时间(假设两个任务都受I / O约束)。 还原是否存在问题?我可以加快速度吗?还是恢复比转储花费更长的时间是正常的?(如果是,那为什么呢?) 转储文件通常具有大约3-4 MiB;DBMS是PostgreSQL V8.4,在Ubuntu Linux下运行于具有1GiB RAM的Pentium4 3GHz上。

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.