xfs
[Top] [All Lists]

bad performance on touch/cp file on XFS system

To: xfs@xxxxxxxxxxx
Subject: bad performance on touch/cp file on XFS system
From: Zhang Qiang <zhangqiang.buaa@xxxxxxxxx>
Date: Mon, 25 Aug 2014 11:34:34 +0800
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=UXQhJiTAdPTaUQ4pPyzfgPurjiHVFk1SSN9GEAmUsM8=; b=wpK/geFwaVD9FNBq7/7NfbBWDaVtAZk7u/HB4Qd3aHaHJ4ESMMOUsoBjqifRdW51UX G9D8FD8aEjLTq5mHx5RqV4fWuZo//rVVXRuf6qEYtWUgpE8UD2NANqq9E4KEf+vPiDFC 8h9gJ8QvBp98AjVEyP05VdqZUam70ItltdLYNEwifBU2SkWSvKSDdSnvFTkRoQ4TTS2H RDBEirLZykSMP+S+vInZl+BP+J51NdvNMs0XS1UM2wNe78ZG4chy7AllHyDoQpvNIuTx vxYGxIuoinj20PW+rqOiCLDB483rMkKdoF0Kc4b739Tqzo8kW/RRYqOqAbtXIsw6V8nd qZYA==
Dear XFS community & developers,

I am using CentOS 6.3 and xfs as base file system and use RAID5 as hardware storage.

Detail environment as follow:
 ÂOS: CentOS 6.3
 ÂKernel: kernel-2.6.32-279.el6.x86_64
 ÂXFS option info(df output): /dev/sdb1 on /data type xfs (rw,noatime,nodiratime,nobarrier)

Detail phenomenon:
 ÂÂ
  # df
  Filesystem      ÂSize ÂUsed Avail Use% Mounted on
  /dev/sda1       Â29G  17G  11G Â61% /
  /dev/sdb1       893G Â803G  91G Â90% /data
  /dev/sda4       2.2T Â1.6T Â564G Â75% /data1
 ÂÂ
  # time touch /data1/1111
  real  Â0m23.043s
  user  Â0m0.001s
  sys   0m0.349s
 ÂÂ
  # perf top
  Events: 6K cycles
  Â16.96% Â[xfs]           [k] xfs_inobt_get_rec
  Â11.95% Â[xfs]           [k] xfs_btree_increment
  Â11.16% Â[xfs]           [k] xfs_btree_get_rec
   7.39% Â[xfs]           [k] xfs_btree_get_block
   5.02% Â[xfs]           [k] xfs_dialloc
   4.87% Â[xfs]           [k] xfs_btree_rec_offset
   4.33% Â[xfs]           [k] xfs_btree_readahead
   4.13% Â[xfs]           [k] _xfs_buf_find
   4.05% Â[kernel]         Â[k] intel_idle
   2.89% Â[xfs]           [k] xfs_btree_rec_addr
   1.04% Â[kernel]         Â[k] kmem_cache_free


It seems that some xfs kernel function spend much time (xfs_inobt_get_rec, xfs_btree_increment, etc.)

I found a bug in bugzilla [1], is that is the same issue like this?

It's very greatly appreciated if you can give constructive suggestion about this issue, as It's really hard to reproduce from another system and it's not possible to do upgrade on that online machine.



Thanks in advance
Qiang
<Prev in Thread] Current Thread [Next in Thread>