Announcement

Collapse
No announcement yet.

Initial Fedora 32 vs. Fedora 33 Beta Benchmarks Point To Slightly Higher Performance

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • guglovich
    replied
    phoronix It's been a long time since the tests, it's 2022. I'm also interested in a comparison of the space savings for which BTRFS is advertised. The options of deduplication, compression, block redistribution.

    Leave a comment:


  • jospoortvliet
    replied
    Let me add that there are other ways for database devs to improve performance on btrfs - see this interesting blog on the subject:


    Summary:

    By using Write-Ahead Logging we can gain a 300% performance boost, compared to about 25-30% increase using the nocow attribute!.
    That should do the trick, bringing performance in line with other file systems while maintaining the benefits of btrfs.

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by skeevy420 View Post

    What about a (post-install) script or daemon that searches for databases and disables COW accordingly? Since it can be assumed that most databases are either under /var or $HOME it would (should) work with Fedora Atomic or Silverblue as well as regular editions.

    What's funny is that ZFS has this exact same issue with databases and other "exotic" formats. And that makes me wonder if other filesystems have database issues which then makes me wonder if the best solution is upstream patches per file system, a daemon, a post install script, or what???
    A post-install script is rather adhoc and has to be duplicated for every distro. Fedora developers have pushed patches upstream for libvirt, cp etc. There is no reason db developers can't add this for COW filesystems, the amount of code to do this is fairly minimal and afaik, it is safe to do

    Leave a comment:


  • oleid
    replied
    Originally posted by StefanBruens View Post

    No, the PTS compiles its own versions for the various DBs.
    One more reason get it upstreamed.

    Leave a comment:


  • StefanBruens
    replied
    Originally posted by oleid View Post

    Thinking about it : system sqlite could create its files with COW disabled. That would certainly not help for electron based AppImages, but at least the system browsers and phoronix test suite would benefit.
    No, the PTS compiles its own versions for the various DBs.

    Leave a comment:


  • StefanBruens
    replied
    Originally posted by Qaridarium View Post
    I use Fedora 32 and Btrfs really Looks Like a Sapontage in the Performance

    Btrfs should Not be the Default
    No, Michael is just not capable of doing a correct setup for database workloads:
    • If you use the database setup provided by the distribution, Postgres, MariaDB etc DBs end up on separate subvolumes with CoW disabled.
    • When you roll your own (like Michael/the PTS does), you have to do it yourself. Setting no-CoW on the DB directory is sufficient.
    This has shed a bad light on openSUSE for years, now its hitting Fedora as well.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by RahulSundaram View Post

    All the database servers including MySQL and PostgreSQL should do it but ideally this is handled upstream rather than through distro level patches
    What about a (post-install) script or daemon that searches for databases and disables COW accordingly? Since it can be assumed that most databases are either under /var or $HOME it would (should) work with Fedora Atomic or Silverblue as well as regular editions.

    What's funny is that ZFS has this exact same issue with databases and other "exotic" formats. And that makes me wonder if other filesystems have database issues which then makes me wonder if the best solution is upstream patches per file system, a daemon, a post install script, or what???

    Leave a comment:


  • Hi-Angel
    replied
    Originally posted by oleid View Post
    Originally posted by RahulSundaram View Post

    All the database servers including MySQL and PostgreSQL should do it but ideally this is handled upstream rather than through distro level patches
    Ack, but one has to start somewhere, I guess.
    Whether upstream or downstream, but this should be handled before Fedora 33 is released (or more specifically, before the "btrfs-by-default" proposal sees wide usage). Otherwise you'll get an year-worth number of Fedora installations with regressed performance (that is basically everyone who installs Fedora 33, and then whether implicitly or explicitly, creates DB files. Clearly, these "already existing" DB files will not get `chattr +C`ed upon getting updates because you never know if one didn't set the property for their own personal reasons)

    Leave a comment:


  • oleid
    replied
    Originally posted by RahulSundaram View Post

    All the database servers including MySQL and PostgreSQL should do it but ideally this is handled upstream rather than through distro level patches
    Ack, but one has to start somewhere, I guess.

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by oleid View Post

    Thinking about it : system sqlite could create its files with COW disabled. That would certainly not help for electron based AppImages, but at least the system browsers and phoronix test suite would benefit.
    All the database servers including MySQL and PostgreSQL should do it but ideally this is handled upstream rather than through distro level patches

    Leave a comment:

Working...
X