3 ms·
>We aren't sure why, but when we tried to delete a lot of data (~200GB from each machine which each contain several TB of data), our databases become unresponsi
by fnord123 10y ago
>We aren't sure why, but when we tried to delete a lot of data (~200GB from each machine which each contain several TB of data), our databases become unresponsive for an hour.
There used to be an issue where users hitting their quota couldn't delete files since for some reason deleting a file meant creating a file somehow. The trick was to find some reasonably large file and `echo 1 > large_file` which truncates the file and frees up enough space that you can begin removing files. Maybe this kind of trick could help you guys.
That said, it's inadvisable to run a database on a btree file system like ZFS or btrfs if you're keeping an eye on the write performance.
cf Postgres 9.0 High Performance by Gregory Smith (https://www.amazon.com/PostgreSQL-High-Performance-Gregory-Smith/dp/184951030X https://www.amazon.com/PostgreSQL-High-Performance-Gregory-S...)
and
https://blog.pgaddict.com/posts/postgresql-performance-on-ext4-and-xfs https://blog.pgaddict.com/posts/postgresql-performance-on-ex...
- malisper 10y ago> That said, it's inadvisable to run a database on a btree file system like ZFS or btrfs if you're keeping an eye on the write performance. Our writes are actually heavily CPU bound because of how we architected the system[0]. We recently made some changes that dramatically improved our write throughput, so AFAICT, we aren't going to need to focus much on write performance in the near future. [0] http://blog.heapanalytics.com/running-10-million-postgresql-indexes-in-production/ http://blog.heapanalytics.com/running-10-million-postgresql-...