ARCH在IO系统方面的性能实在是太差了

我经常碰到这样的情况：
- 高速BT下载资源，速度高于5MB/S以上，结果系统反应开始迟钝；
- 朋友拿U盘过来，我拷贝电影进去，电影很大（若干G），系统又开始卡了；

以上情况出现时，系统监视器中显示会有很多程序处于“磁盘睡眠“状态，基本上需要加载资源的（例如读取一些图片显示的AMOR小玩具，读取字库文件的fcitx）程序，都会不时进入这个状态。

严峻的情况下，我想切换进虚拟终端也难——login程序因为读取//etc/passwd文件进行检测而导致超时！！（估计一般人没见过吧？60秒超时）

此外，CPU占用率很高，双核，都持续地接近100%。

一直以来，我以为是LVM耗费了部分的CPU资源导致的（此外，笔记本的硬盘性能也不算好）。不过为什么往U盘里拷贝文件也会很卡（通常速度也很低很低）？我很不解，只能归咎于kernel对U盘的处理不够windows强了。

今天又是这样的情况。往同学的移动硬盘里拷贝2.5G的游戏，系统又很卡了（连韦诺之战都不得不停下来）。后来同学要我把他移动硬盘里的文件（15G的某个巨大文件）从A分区移动到B分区，这一次，写入速度只剩一半了（9MB/S），系统卡得我非常郁闷。

我切换到kubuntu 10.04，同样是在KDE4.4.3下，再次同样这行这样的操作（在dolphin中复制文件到B分区），CPU依然占用很高，可是系统完全不卡！！打开程序、浏览网页、游戏。。。ARCH下这些操作都需要进行磁盘IO，结果非常非常卡，而KUBUNTU下没有任何卡滞的体验！！！

总结：ARCH在IO系统方面的性能实在是太差了

求助：如何解决这个问题？？

PS: laptop-mode之类的，通通都没有开（一直觉得它没有作用）。

作者: 沈觅仁发布时间: 2010-05-24

用终端拷贝会不会卡？我用过arch、debian、ubuntu等等，在gui上操作大文件都不如win，但也没有你说的那么严重，终端就比win快多了

作者: chenzhen 发布时间: 2010-05-24

我拿一台Arch跑DB Server都没事啊，磁盘响应速度正常，每周产生1GB的新数据，每日维护的自动备份维持在10GB左右。我用的是ARCH的lts内核v2.6.27，数据库PostgreSQL v8.4.3。

作者: 没本发布时间: 2010-05-24

虽然我没有数据比较，但跟楼主的感觉差不多。
我的是 arch (kernel 2.33) + gnome (2.30)
比如浏览一堆 1MB 以上的图片时，切换到下一张大概要1-3秒，但在ubuntu下就明显快的多，进度条一闪就过去了...
另外就是读PDF文件，到现在都没找出解决办法

至于拷贝大文件时比较卡的现象，由于机器比较老（07年的本本），在ubuntu、fedora、arch下都差不多（我只用过 reiserfs 和 ext4）

作者: ha_ha_xiao 发布时间: 2010-05-24

我觉得只要我的磁盘操作是发生在X程序里的,就会很慢...
如果在终端里就不会

作者: gsli52 发布时间: 2010-05-24

引用:

作者: chenzhen

用终端拷贝会不会卡？我用过arch、debian、ubuntu等等，在gui上操作大文件都不如win，但也没有你说的那么严重，终端就比win快多了

目前我没有高速的大容量移动设备来测试了。

不过我测试了一下轻量级发行版（e17）中本地大文件复制（dolphin），虽然CPU占用还是很高，速度也不快（24MB/S的速度，感觉像是移动硬盘唉)，不过桌面系统的整体相应没有停滞下来，一切还算正常得样子。

以我以前得操作的经验来看，终端下复制文件（cp）似乎也不会快很多。

所以，我碰见得问题难道纯粹是KDE4引起的？？

作者: 沈觅仁发布时间: 2010-05-24

x的问题吧，我公司所有服务器都是arch，千兆网络里文件服务器每天数据流量上百G，性能很好啊

作者: qiang_liu8183 发布时间: 2010-05-24

引用:

作者: qiang_liu8183

x的问题吧，我公司所有服务器都是arch，千兆网络里文件服务器每天数据流量上百G，性能很好啊

可我总得用X啊！怎么办？

作者: 沈觅仁发布时间: 2010-05-24

引用:

作者: 沈觅仁

我经常碰到这样的情况：
- 高速BT下载资源，速度高于5MB/S以上，结果系统反应开始迟钝；
- 朋友拿U盘过来，我拷贝电影进去，电影很大（若干G），系统又开始卡了；

以上情况出现时，系统监视器中显示会有很多程序处于“磁盘睡眠“状态，基本上需要加载资源的（例如读取一些图片显示的AMOR小玩具，读取字库文件的fcitx）程序，都会不时进入这个状态。

严峻的情况下，我想切换进虚拟终端也难——login程序因为读取//etc/passwd文件进行检测而导致超时！！（估计一般人没见过吧？60秒超时）

此外，CPU占用率很高，双核，都持续地接近100%。

一直以来，我以为是LVM耗费了部分的CPU资源导致的（此外，笔记本的硬盘性能也不算好）。不过为什么往U盘里拷贝文件也会很卡（通常速度也很低很低）？我很不解，只能归咎于kernel对U盘的处理不够windows强了。

今天又是这样的情况。往同学的移动硬盘里拷贝2.5G的游戏，系统又很卡了（连韦诺之战都不得不停下来）。后来同学要我把他移动硬盘里的文件（15G的某个巨大文件）从A分区移动到B分区，这一次，写入速度只剩一半了（9MB/S），系统卡得我非常郁闷。

我切换到kubuntu 10.04，同样是在KDE4.4.3下，再次同样这行这样的操作（在dolphin中复制文件到B分区），CPU依然占用很高，可是系统完全不卡！！打开程序、浏览网页、游戏。。。ARCH下这些操作都需要进行磁盘IO，结果非常非常卡，而KUBUNTU下没有任何卡滞的体验！！！

总结：ARCH在IO系统方面的性能实在是太差了

求助：如何解决这个问题？？

PS: laptop-mode之类的，通通都没有开（一直觉得它没有作用）。

文件系统是啥？fstab参数？

作者: hurricanek 发布时间: 2010-05-24

是不是幻觉？我怎么觉得类似的文章看到了不止一次？

作者: stecue 发布时间: 2010-05-24

关注一下。楼主把fstab贴一下吧

作者: xsam 发布时间: 2010-05-24

偶也是感觉终端下会好一些

作者: 32idea 发布时间: 2010-05-24

deluge 下载 BT ，双核有一个核心偶而会占用100%。100k/s速度

作者: jmw778s 发布时间: 2010-05-24

我这边还好，用的E17桌面环境。

作者: usbtopc 发布时间: 2010-05-24

我的感觉正好相反，win7下拷贝超过1Ｇ的文件就卡死了。不过gui下确实比cli慢一点，大文件拷贝大家可以试一下rsync。

作者: zhuqin_83 发布时间: 2010-05-24

拷文件倒还没觉得什么，快慢也不至于操作其它应用程序卡滞。但有时候看U盘里的相片（几M的）速度确实不怎么样，就像上面那位兄弟说的一样，1-3秒可能有，特别是给相处转方向的时候，那叫一个慢啊，这一操作没法跟WIN比。没仔细研究，也许只跟X有关。

作者: smileoa 发布时间: 2010-05-24

我就是受不了arch的卡，才转向了ubuntu。当时是kde4，文件系统jfs。现在是ubuntu 10.04，/是ext4，home是reiserfs。速度很快。比xp快。

作者: playfish 发布时间: 2010-05-24

对于bt的问题，我想问下你用的什么软件。
开始我用的transmission，限速5.5M/s，一超过这个速度机器就基本上动不了了，然后换了rtorrent，结果比transmission还卡，校验的时候啥都干不了
现在用的qbittorrent-nogui，没限速，一般在11M/s，一点都不卡，校验hash都没什么感觉

作者: ulosggs 发布时间: 2010-05-24

引用:

作者: ulosggs

对于bt的问题，我想问下你用的什么软件。
开始我用的transmission，限速5.5M/s，一超过这个速度机器就基本上动不了了，然后换了rtorrent，结果比transmission还卡，校验的时候啥都干不了
现在用的qbittorrent-nogui，没限速，一般在11M/s，一点都不卡，校验hash都没什么感觉

BT使用的软件是ktorrent。下载速度是5MB/S是系统也还很好，只是更高速（如8~9MB/S）就很卡了。

/etc/fstab如下：

PHP 代码:

#/dev/system/swap        swap            swap        defaults            0 0
/dev/system/home        /home           reiserfs    defaults,noatime    0 0
/dev/system/zoo         /zoo            ext4        nobarrier,user,defaults,noatime,nobarrier    0 0
/dev/system/videos      /media/videos   ext4        nobarrier,user,defaults,noatime,nobarrier    0 0
UUID=16e398c2-bfd9-47b7-a50a-86700bf28a6f /     reiserfs    defaults,async,noatime    0 1

物理内存2GB，没有开SWAP。

有可能于KDE4有关，毕竟有时启动opera都需要狂读硬盘（硬盘指示灯闪啊闪得），然而在轻量级桌面下启动opera就很快了。

一般得卡滞，我是能够容忍的；但是严重到连虚拟终端也超时而登录不了，这恐怕就有很大问题了。

作者: 沈觅仁发布时间: 2010-05-24

不知道有谁可以向官网报告！看官方怎么说，有解决方案就回复一下。

作者: jmw778s 发布时间: 2010-05-24

kde的问题。我现在用xfce4,一点问题也没有。以前我用gnome，也碰到这个问题。

arch linux的测试周期太短，大的项目新鲜出炉的时候总有一些bug（资源消耗过多也是bug），archlinux就直接给你端上了。

作者: redguardtoo 发布时间: 2010-05-24

会不会和kernel有关系？
不过我没那么快的网速，测试不了

作者: xsam 发布时间: 2010-05-24

引用:

作者: 沈觅仁

目前我没有高速的大容量移动设备来测试了。

不过我测试了一下轻量级发行版（e17）中本地大文件复制（dolphin），虽然CPU占用还是很高，速度也不快（24MB/S的速度，感觉像是移动硬盘唉)，不过桌面系统的整体相应没有停滞下来，一切还算正常得样子。

以我以前得操作的经验来看，终端下复制文件（cp）似乎也不会快很多。

所以，我碰见得问题难道纯粹是KDE4引起的？？

kubuntu 和 openSUSE 很正常，所以不会是 KDE4 的问题。

作者: poet 发布时间: 2010-05-24

引用:

作者: 沈觅仁

有可能于KDE4有关，毕竟有时启动opera都需要狂读硬盘（硬盘指示灯闪啊闪得），然而在轻量级桌面下启动opera就很快了。

不知道你具体什么环境，不过KDE4里面唯一可能影响你这个问题的就是 strigi，缺省情况下，这个在 kubuntu 里面是关的，请检查你是否关闭了 strigi。

作者: poet 发布时间: 2010-05-24

我也一直有这个问题....最明显的就是操作大文件,win下没问题,arch下卡到其他程序都好慢,还有往U盘上拷贝大文件也是这样.

而且,好像和X没太大关系,不过是X的模拟终端上操作的,往U盘拷贝大文件,然后sync,比win下差很多.

作者: CnkknD 发布时间: 2010-05-24

拷文件居然要占用大量CPU？是不是DMA没有起作用？
同是KDE4的用户表示没有任何问题，而且几乎我所有同学都能感觉到我的Arch拷文件明显比Windows要快

作者: bhoppi 发布时间: 2010-05-24

这种现象貌似和缓存有关

作者: CnkknD 发布时间: 2010-05-24

也可能是硬盘dma没开。测试一下吧。我一台Arch用的是Maxtor的老硬盘，测试结果如下：

代码:

 $ sudo hdparm -itT /dev/sda

/dev/sda:

 Model=Maxtor 6Y160M0, FwRev=YAR51HW0, SerialNo={hide}
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=DualPortCache, BuffSize=7936kB, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=320173056
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
 AdvancedPM=yes: disabled (255) WriteCache=enabled
 Drive conforms to: ATA/ATAPI-7 T13 1532D revision 0: ATA/ATAPI-1,2,3,4,5,6,7

 * signifies the current active mode

 Timing cached reads: 1416 MB in 2.00 seconds = 707.93 MB/sec
 Timing buffered disk reads: 170 MB in 3.03 seconds = 56.14 MB/sec

楼主也测一下看看。

作者: 没本发布时间: 2010-05-24

我特别不能忍受的就是updatedb自动运行的时候，整个机子就卡死了......虽然我很不满，不过也一直懒得去理。终于有人挑头了～

作者: Alerander 发布时间: 2010-05-24

cli下用mc

作者: liwangli 发布时间: 2010-05-24

引用:

作者: poet

不知道你具体什么环境，不过KDE4里面唯一可能影响你这个问题的就是 strigi，缺省情况下，这个在 kubuntu 里面是关的，请检查你是否关闭了 strigi。

strigi一直都是关闭的，否则那可就真的一直很卡了。不过nepomuk还开着。

引用:

作者: bhoppi

拷文件居然要占用大量CPU？是不是DMA没有起作用？
同是KDE4的用户表示没有任何问题，而且几乎我所有同学都能感觉到我的Arch拷文件明显比Windows要快

我也一度怀疑DMA没有起作用，但也无法确认。hdparm的测试结果如下：

PHP 代码:

16:16:59 ~ $ sudo hdparm -itT /dev/sda

/dev/sda:

Model=WDC WD3200BEVT-22ZCT0, FwRev=11.01A11, SerialNo=WD-WXE508FPA817
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=625142448
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes:  pio0 pio3 pio4
DMA modes:  mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: unknown setting WriteCache=enabled
Drive conforms to: Unspecified:  ATA/ATAPI-1,2,3,4,5,6,7

* signifies the current active mode

Timing cached reads:   2848 MB in  2.00 seconds = 1425.17 MB/sec
Timing buffered disk reads:  190 MB in  3.00 seconds =  63.26 MB/sec
22:25:42 ~ $

引用:

这种现象貌似和缓存有关

也有可能。不过你有更具体的配置/测试嘛？

作者: 沈觅仁发布时间: 2010-05-25

代码:

/dev/sda:

 Model=WDC WD5000AAKS-75A7B2, FwRev=01.03B01, SerialNo=WD-WMASY7025667
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
 BuffType=unknown, BuffSize=16384kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=976773168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio3 pio4
 DMA modes: mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7

 * signifies the current active mode

 Timing cached reads: 3480 MB in 2.00 seconds = 1740.10 MB/sec
 Timing buffered disk reads: 274 MB in 3.02 seconds = 90.84 MB/sec

贴一个我的

作者: hurricanek 发布时间: 2010-05-25

我这里还strigi开着呢……

没有遇见啥问题

笔记本慢一些，不过那个硬盘已经用了很久了，load cycle 都70万了

作者: hurricanek 发布时间: 2010-05-25

刚上一块移动硬盘，500G的，速度大于笔记本内部硬盘，所以一拷数据就悲剧了，系统完全停摆卡得要死，暂时只在XP下用了，回头测试下linux下的效果～

感觉卡不卡取决于硬盘的带宽是不是被耗尽了……
lz有没测试下linux下的实际拷贝速度？

作者: yafeng 发布时间: 2010-05-25

我测试了一下, 这个应该还跟文件系统有关
好像在那里看过说htparm测出的数据不一定代表真实速度,我就用dd

从/dev/zero dd 1G数据到ext4上能到70Ms/s, cpu占用不到10%
到ntfs上到现在还没完, 都几分钟了, cpu一直占99%

我以前出现慢的时候好像还真是大部分在ntfs分区上操作, 本地ext4的home没放什么大文件
还有我以前u盘因为有16G,也是分的ntfs,拷高清片系统就卡
昨天找到了linux下exfat的驱动,把u盘格成exfat,晚上测试了一下,写速度有10M/s,cpu占用10%左右,系统不卡.

继续观察......

作者: CnkknD 发布时间: 2010-05-25

ls ntfs-3g ntfs-progs来回换着用用，看看哪个性能高些

作者: yafeng 发布时间: 2010-05-25

和楼主遇到同样的问题，将文件系统从ext4换成ext3就好了，ext4在Arch上那个性能真是太差了。

没有做具体的测试，但是我感觉ext4比ext3要慢5倍以上，楼主也换成ext3吧，ext4现在还不成熟，至少在arch上是这样。

作者: sanyork 发布时间: 2010-05-26

楼主的磁盘性能方面没有问题，内核也正确使用了udma6这种最佳模式，按楼上几位的说法，那就应该在文件系统上找问题了。

作者: 没本发布时间: 2010-05-26

引用:

作者: sanyork

和楼主遇到同样的问题，将文件系统从ext4换成ext3就好了，ext4在Arch上那个性能真是太差了。

没有做具体的测试，但是我感觉ext4比ext3要慢5倍以上，楼主也换成ext3吧，ext4现在还不成熟，至少在arch上是这样。

哇，有没有那么夸张啊？

作者: 难免有错发布时间: 2010-05-26