Reacties op: SSD performance improvements set LIVE http://jdevelopment.nl/postgresql/ssd-performance-improvements-set-live/ designing a new generation of software Mon, 02 Aug 2010 11:00:01 +0000 hourly 1 http://wordpress.org/?v=abc Door: development http://jdevelopment.nl/postgresql/ssd-performance-improvements-set-live/comment-page-1/#comment-488 development Mon, 01 Jun 2009 12:45:24 +0000 http://jdevelopment.nl/?p=241#comment-488 We did indeed make some changes in the postgresql.conf file too, but as always its hard to say whether we have hit the absolute sweet spot with respect to tuning. Off the top of my head we made the following changes: maintenance_work_mem from 256MB to 2GB temp_buffers from 8MB to 32MB work_mem from 32MB to 256MB vacuum_cost_delay from 50 to 0 max_stack_depth from 4M to 6MB random_page_cost from 2 to 1.5 (sequential_page_cost = 1) effective_cache_size from 4GB to 16GB autovacuum_vacuum_cost_delay from 20 to 40 I think these numbers are pretty accurate, but to be absolute sure I would have to verify the change logs. As for the total performance improvement, the new server is quite different from the old server. 64 bits instead of 32 bits, newer kernel, more memory, higher clocked CPUs with more cores and then of course the SSD storage system. With so many changes at once, it's hard to attribute a specific percentage of the performance improvements to the SSD storage system. As techies we would have loved to equip the old server with the new SSD storage system, in order to have a more apples to apples comparison. Unfortunately this wasn't an option. Nevertheless experience with previous upgrades where we also doubled the memory, doubled the number of cores, increased the clock frequency of the CPUs, etc never gave us such a large performance boost as we saw with this new server. We did indeed make some changes in the postgresql.conf file too, but as always its hard to say whether we have hit the absolute sweet spot with respect to tuning.

Off the top of my head we made the following changes:

maintenance_work_mem from 256MB to 2GB
temp_buffers from 8MB to 32MB
work_mem from 32MB to 256MB
vacuum_cost_delay from 50 to 0
max_stack_depth from 4M to 6MB
random_page_cost from 2 to 1.5 (sequential_page_cost = 1)
effective_cache_size from 4GB to 16GB
autovacuum_vacuum_cost_delay from 20 to 40

I think these numbers are pretty accurate, but to be absolute sure I would have to verify the change logs.

As for the total performance improvement, the new server is quite different from the old server. 64 bits instead of 32 bits, newer kernel, more memory, higher clocked CPUs with more cores and then of course the SSD storage system. With so many changes at once, it’s hard to attribute a specific percentage of the performance improvements to the SSD storage system.

As techies we would have loved to equip the old server with the new SSD storage system, in order to have a more apples to apples comparison. Unfortunately this wasn’t an option. Nevertheless experience with previous upgrades where we also doubled the memory, doubled the number of cores, increased the clock frequency of the CPUs, etc never gave us such a large performance boost as we saw with this new server.

]]> Door: Frank http://jdevelopment.nl/postgresql/ssd-performance-improvements-set-live/comment-page-1/#comment-482 Frank Wed, 27 May 2009 08:07:51 +0000 http://jdevelopment.nl/?p=241#comment-482 Nice impovements! Did you also made some changes in postgresql.conf? Your new server has more RAM, let the database use this extra RAM as well. These fast SSD's have a complete different write-behaviour compared to the former SAS-drives, the database should handle writes different as well. Changes in the configurationfile could speed things up even further. Good luck! Nice impovements! Did you also made some changes in postgresql.conf? Your new server has more RAM, let the database use this extra RAM as well. These fast SSD’s have a complete different write-behaviour compared to the former SAS-drives, the database should handle writes different as well. Changes in the configurationfile could speed things up even further.

Good luck!

]]>