Please consider work_mem too, 4mb is awfully low too. I may be too used to custom tuning instances for my work load. I'd generally set work_mem closer to 30-35mb for a 12-16gb instance with 100 connections.
On Tuesday, May 23, 2017 at 7:49:44 PM UTC-5, Ankush Agarwal wrote:
-- On Tuesday, May 23, 2017 at 7:49:44 PM UTC-5, Ankush Agarwal wrote:
Paul,Thank you for your feedback and for bringing up the random_page_cost parameter. We have filed a bug internally to investigate the performance impact of random_page_cost.Regarding shared_buffers, we currently have a default of 128MB for instances having < 60G RAM and 1/3*ram_size for instances with > 60G RAM. We have also started investigating setting an optimal shared_buffers for instances with < 60G RAM. Please let us know if you have any other questions or concerns.
On Tuesday, May 23, 2017 at 12:37:41 PM UTC-7, Paul Lamb wrote:Didn't find anyone asking about this already here or on stack overflow. I'm assuming that the default value of 4 is being used for random_page_cost (I created a new pg instance today with 2 cpu/13gb memory, 100gb of ssd). This might have just been overlooked but that's an awfully high number. Most of the time for more modern san's a number in the 1.5-2.0 is considered conservative. Also, how are are shared_buffers getting set? For this instance I created today it's set to have 128mb for shared buffers.
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/28a7346f-2fca-41da-8f93-bda539594432%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment