Also are you using FDE/LUKS? I guess not as it's "public" data but if you do check the block size, LUKS picked the wrong one and got only 20% of non-encrypted performance before we noticed then we got 80%, also the "cloudflare patches" are important (now mount flags not patches)
@Josh the database server also serves:
Infosec.space
Pixel.infosec.exchange
Infosec.place
Fedia.social
Infosec.town
Fedia.io
Meetup.infosec.exchange
Books.infosec.exchange
Infosec.pub
It’s a bit memory bound now, so I’ll upgrade to this one, and return one of the existing servers.
@jerry@Josh if the current DB server is memory bound without ZFS, you're going to need a lot more RAM for ZFS. As I understand it, ZFS needs a lot of RAM.
@jerry@xabean@Josh When I worked at Neo4j we generally recommended XFS as a slightly better ext4. I get it if you don’t want to touch the boat on this one, though.
@xabean@jerry@Josh My limited understanding of zfs is that it uses any extra ram for caching. It doesn't necessarily require more ram but it will use whatever you give it. Obviously more ram means more caching which means better performance.
@jerry@ithoughtisawa2@xabean@Josh don't do it. It can be done, but you're asking for headaches. In the future Postgres will actually have the ability to run optimally on ZFS when a direct I/O implementation is finished, but it's not ready yet
@jerry@feld
I was going to suggest btrfs as an alternative to zfs because the zfs cache isnt unified with the linux fs cache, but apparently performance is poor with postgres. They say copy on write kills it, which would also affect zfs.