以下是我在cp大文件时，用vmstat 2 3后的结果 
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- 
r  b  swpd  free  buff  cache  si  so    bi    bo  in    cs us sy id wa 
0 17  4360 111184  4076 5553236    0    1    62    60    0    3  2  1 96  2 
0 16  4360  98384  4116 5564116    0    0    54 12784 1138  629  0  1  0 99 
0 17  4360  65424  4176 5597596    0    0  768  5710 1150  604  1  2 21 76 

大部分时候wa都在50左右，而id也在50左右，这时系统反映极其缓慢，其上的tomcat服务器经常访问超时。拷贝的文件比较大，往往在5G以上。 

而不拷贝大文件，正常情况下，vmstat 2 3的结果如下： 
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- 
r  b  swpd  free  buff  cache  si  so    bi    bo  in    cs us sy id wa 
1  0  12204 271720  89672 6030404    0    1    46    51    1    3  2  0 96  2 
1  0  12204 271464  89692 6030384    0    0    14  294 1234  880  5  2 93  1 
0  0  12204 271528  89712 6030884    0    0    48    0 1396  1032  2  1 96  1 

swpd free buff几列数字差别很大，是什么原因呢？


系统只有一个磁盘（阵列）： 
[root@** ~]# df 
Filesystem          1K-blocks      Used Available Use% Mounted on 
/dev/cciss/c0d0p1    478679640 307785180 146578880  68% / 
none                  4154940        0  4154940  0% /dev/shm 

这个文件中存放的是上千万数据的索引，需要经常更新。基本上无法减小。如果分为多个文件，则肯定会影响搜索性能。 
这么高的wa是否正常？ 
是否有其他办法可以改善这种状况呢？ 
比如让文件复制运行得“温柔”一些。（虽然我可以自己写cp命令，但索引系统更新索引的时候，会导致类似的问题） 


机器配置了8G内存，但只有2G交换分区。
[root@linuxcp10267 ~]# free 
            total      used      free    shared    buffers    cached 
Mem:      8309884    8153572    156312          0      82912    5990104 
-/+ buffers/cache:    2080556    6229328 
Swap:      2040244      12204    2028040 

nice命令没有效果，设置成最低(19)还是一样。

有没有好心人帮我试试看，如果在你的linux机器上复制10G这么大的一个文件，是否会造成系统缓慢（web服务器几乎不可用），或者告诉我vmstat 2 3的数据。

什么文件系统？

这样经常的复制大文件不太好

还是做成双机热备份的好。

这样的话，可以去复制备份好的文件

还不影响正常的使用。