通过iostat命令发现某块磁盘的io使用率经常保持在100%，通过@L_502_0@后，最后发现是挂载点上的一个数据库表空间在占用大io。

现象

postgres@dbmaster:~$iostat-xm3|grep-vdm

avg-cpu:%user%nice%system%iowait%steal%idle
11.680.003.828.630.0075.87

Device:rrqm/swrqm/sr/sw/srMB/swMB/savgrq-szavgqu-szawaitr_awaitw_awaitsvctm%util
sda0.000.690.291.540.000.0118.010.001.454.340.910.570.10
sdb0.000.773.512.630.420.57329.190.034.230.619.070.520.32
sdc0.0012.9831.28283.841.175.4643.070.102.8821.270.850.5718.00
sdd0.000.080.010.950.000.42889.720.34358.7365.53361.074.140.40
sde0.4213.0458.26766.301.606.6320.450.710.864.560.580.8973.57
sdf0.118.6256.90217.503.022.5041.150.632.2810.760.070.8924.46

解决办法

现在知道个别磁盘io使用率很高，接下来就是需要修改个别表索引的表空间到空闲磁盘中。

通过alter index直接移动索引会锁住其它更新操作，大索引的移动需要很长时间，在生产环境中不可取。可以通过以下方式解决：

1。通过create index concurrently在新的表空间重建和原表空间定义一样的索引（名字不同）。

2。删除原表空间的索引。

create index concurrently的介绍可以参考这篇文章：http://my.oschina.net/Kenyon/blog/93465

实际操作

下面是原来一个表的索引详情，需要把除了主键外在indextbs上的索引移动到默认表空间。

Indexes:
"article_111_pkey" PRIMARY KEY,btree (aid),tablespace "indextbs"
"article_111_url_hash" UNIQUE CONSTRAINT,btree (url_hash),tablespace "indextbs"
"article_111_bid_titlehash_idx" btree (bid,title_hash),tablespace "indextbs"
......

1、移动article_111_bid_titlehash_idx索引

CREATEINDEXCONCURRENTLYarticle_111_bid_title_hash_idxONarticle_111USINGbtree(bid,title_hashCOLLATEpg_catalog."default")TABLESPACEpg_de
fault;
dropindexarticle_111_bid_titlehash_idx;

2、移动article_111_url_hash索引

这个索引有一个唯一性约束，和前面方法有些区别。

CREATEUNIQUEINDEXCONCURRENTLYarticle_111_urlhash_idxONarticle_111USINGbtree(url_hash);
altertablearticle_111dropconstraintarticle_111_url_hash,adduniqueusingindexarticle_111_urlhash_idx;

参考网址：

http://www.sijitao.net/1823.html

http://www.postgresql.org/docs/9.1/static/sql-altertable.html