On Thu, Oct 31, 2013 at 5:37 PM, Claudio Freire <klaussfreire@gmail.com> wrote:
On Thu, Oct 31, 2013 at 5:33 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
El 31/10/13 16:18, Claudio Freire escribió:
It's not a critical issue, of course, but I'm in a position to assist with tests, benchmarks and diagnostics... so... what do I need to do to provide useful info here?
You have to disable COW for databases and virtual machines, this is a known issue.
Yeah, did that.
chattr -R +C pgdata
I know nobody is paying attention, but I wanted to post some concrete results of a database restore of approximately 200GB, before I forgot: btrfs restore, async commit off: real 315m12.373s user 6m41.757s sys 0m39.985s thoughput sample Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 8.20 18.47 118.78 83.15 34.53 40.34 759.35 1904.12 9155.32 49.37 22163.54 4.95 100.00 sda 1.12 0.22 163.68 24.13 80.89 11.81 1010.85 2491.56 14155.78 73.21 109670.21 5.32 100.00 ext4 restore, async commit off: real 329m5.622s user 6m41.842s sys 0m40.509s thoughput sample Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 5.77 68.65 90.58 136.20 11.74 66.05 702.52 367.35 1609.36 15.17 2669.62 3.88 88.09 sda 15.60 7.75 268.27 52.50 33.77 25.09 375.84 780.36 2081.75 10.70 12664.46 3.12 100.00 sda 0.80 0.40 879.40 0.42 109.17 0.00 254.13 1.99 2.27 1.94 691.84 1.11 97.35 This restore has been performed with 4 parallel jobs, as usually recommended for this kind of task that ought to be somewhat CPU-bound. See that ext4 reflects this CPU-boundness by showing at least 2 samples out of 3 with %util below 100%. So, at least one conclusion can be drawn from this: Under heaving writing, btrfs induces noticeably higher read await times than ext4, resulting in the considerably sluggish system I reported initially. This could be due to the lower wrqm/s noticeable above, though those numbers could be prominently noise. I should emphasize, that COW has been disabled on this partition, and the partition is dedicated to this database (but not the whole disk, just the partition). I should repeat the test with async commit on, but I currently need this test DB for real work, so that could take some time. Yes, ext4 took longer (14 minutes longer). That could be noise, the system wasn't totally idle (I was browsing with firefox, painfully slowly, but inducing some extra load). It does look though to be an I/O scheduling issue more than a performance issue, because restore times are comparable. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org