On Fri, Jul 03, 2020 at 10:37:43AM -0600, Chris Murphy wrote: > On Thu, Jul 2, 2020 at 10:29 PM Scott Schmit <i.grok@xxxxxxxxxxx> wrote: > > > > On Sun, Jun 28, 2020 at 03:40:11PM -0600, Chris Murphy wrote: > > > Databases and VM images are things btrfs is bad at out of the box. > > > Most of this has to do with fsync dependency of other file systems. > > > Btrfs is equipped to deal with an fsync heavy world out of the box, > > > using treelog enabled by default. But can still be slow for some > > > workloads. > > > > Does this also impact mariadb databases? I've noticed that since > > reinstalling my machine with mediawiki installed, the performance of the > > wiki has dropped noticeably when the cache is cold (just loading the > > pages, not editing them). > > Good question. A complete answer leads to a lot more questions. > > Mariadb has a couple older docs on this: one suggests using 'noatime' > mount option on all file systems [1] as an optimization, and > additionally for Btrfs to use 'nodatacow' [2]. It can be set per > directory or per file using 'chattr +C' before files are created - it > won't work after the fact. 'chattr +C' will make files behave like > it's on any other filesystem: all writes are overwrites instead of > copy-on-write, no checksums, no compression. > > Is this stale information? Is there something unrelated going on in > your case? Should databases setup these optimizations on behalf of > users? Does storage type make a difference? I'm just going to set > those aside for now. FWIW, neither /var/lib/mysql nor any of the files under it were set up with +C. I'm not using noatime, but I am using relatime. This isn't a terribly large wiki -- just a personal setup (about 19M if I'm measuring the right files). It's also more of a server use case than a workstation one. That said, I'd imagine it's on the order of what a developer might set up for testing. > To give the nodatacow suggestion a try: > ## shutdown the database > # mkdir /var/lib/mysql2 > # chattr +C /var/lib/mysql2 > # cp /var/lib/mysql/* /var/lib/mysql2/ > # rm /var/lib/mysql/ > # mv /var/lib/mysql2/ /var/lib/mysql/ > ## resume operation Doing the manipulations to make it nocow doesn't appear to have made a significant difference: I still see a delay between the raw page (sans CSS) loading and the CSS loading to make it look right. I thought it had lessened when I tried it last night, but when I tried again today, it was back just as long. When I was running on LVM+ext4, I remember no delay. Maybe the database has nothing to do with it? For the record (since people are continuing to tweak the notional script above), my approach for turning off COW was (ignoring a bunch of ls's and such): # systemctl stop httpd mariadb # tar cfz /root/var-lib-mysql.tar.gz /var/lib/mysql ## sanity check that I shut down enough stuff # tar -d -f /root/var-lib-mysql.tar.gz -C / var/lib/mysql # mv /var/lib/mysql /var/lib/mysql.bak # mkdir /var/lib/mysql # restorecon /var/lib/mysql ## I realize this is unnecessary, but it made it look the same as before # chcon -u system_u /var/lib/mysql ## the tar below probably makes this unnecessary, but I didn't remember # chown mysql:mysql /var/lib/mysql # chattr +C /var/lib/mysql # tar -x -f /root/var-lib-mysql.tar.gz -C / var/lib/mysql # lsattr /var/lib/mysql # diff -ru /var/lib/mysql /var/lib/mysql.bak ## just in case subdirectories needed it # restorecon -R /var/lib/mysql # systemctl start httpd mariadb # rm -rf mysql.bak (I realize now that if I'd kept around the old copy, I could support more rigorous timing tests, but my intent was less to diagnose my specific case than to provide another directory/set of files needing extra support for handling btrfs better.) Incidently... how does one handle chattr +C as part of tar backups and the like? -- Scott Schmit _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
