On 9.4.2014 23:28, Martijn van Oosterhout wrote: > On Wed, Apr 09, 2014 at 02:16:34PM -0700, Ken Tanzer wrote: >>> Any thoughts on how to pull this off for PostgreSQL stored data? >>> >>> I looked at this a while ago because I have clients who might >> require this in the future. ISTM you should be able to have your PG >> data directory stored on an encrypted filesystem. I believe this >> will decrease performance, but I have no idea by how much. > > FWIW, I have several databases running on encrypted filesystems. The > performance difference is negligable *if* you have hardware > acceleration for your encryption, which most modern processors have. > > Essentially, the processor can encrypt/decrypt data so much faster > than the cost of reading/writing to disk, you don't notice the > difference. There's surely a difference, but if this means you meet > your requirements it's an excellent solution. We're running a number of rather busy PostgreSQL boxes with encryption at filesystem (or more precisely dm-crypt/LUKS with LVM, IIRC). Support for encryption acceleration (AES-NI [1]) is an absolute must. The other thing that is essential for good performance is reasonably recent kernel. 2.6.x kernels have a single-threaded kcryptd, which means you can't get more than ~150 MB/s AES-256 (per partition). With other algorithms it's not much better (say, 170MB/s with AES-128, IIRC). Somewhere in 3.x (or maybe very late 2.6.x) kcryptd was improved to use multiple threads - that's a significant improvement, both for throughput and latencies. Clearly, it's going to eat (part of) your CPUs, but that's expected. The encryption still has impact on latencies, but with the multi-threaded kcryptd it's pretty-much negligible. regards Tomas [1] http://en.wikipedia.org/wiki/AES_instruction_set -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
