a bad kernel for postgresql-9.4???
Michael
On 19/08/15 10:00, Michael H wrote:
CentOS Linux release 7.1.1503 (Core)
3.10.0-229.11.1.el7.x86_64
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Hi Joshua,
On 18/08/15 16:12, Joshua D. Drake wrote:
On 08/18/2015 08:01 AM, Michael H wrote:
Hi,
I've been tuning our new database server, here's some info...
CentOS Linux release 7.1.1503 (Core)
3.10.0-229.11.1.el7.x86_64
8 x 16GB 1600MHz PC3-12800 DDR3- 128GB tot
Hi Alvaro,
On 18/08/15 17:41, Alvaro Herrera wrote:
Alvaro Herrera wrote:
One thing to look at is the rate of WAL generation for a set number of
transactions. Maybe the later releases are generating more WAL due to
multixacts, for instance (prior to 9.3 these weren't wal-logged.)
Also try 9
Hi Alvaro,
On 18/08/15 17:39, Alvaro Herrera wrote:
Joshua D. Drake wrote:
On 08/18/2015 09:19 AM, Melvin Davidson wrote:
8 x 16GB 1600MHz PC3-12800 DDR3 - 128GB total
shared_buffers=60GB
I would say 60GB is too high when you have 128GB system memory.
Try lowering it to sha
I have tested all different shared_buffers settings across both
versions, from 8GB - 60GB. 8-32GB were optimal. in reality the
difference from 8 - 32 was minimal.
On Tue, Aug 18, 2015 at 11:49 AM, Jeff Janes mailto:jeff.ja...@gmail.com>> wrote:
On Tue, Aug 18, 2015 at 8:01 AM, Michael H
wal_buffers=64MB
shared_buffers=60GB
work_mem64MB
Other settings were changed and reverted again due to performance decreases.
I also dropped shared_buffers down to 32GB, TPS dropped further.
On 18/08/15 16:12, Joshua D. Drake wrote:
On 08/18/2015 08:01 AM, Michael H wrote:
Hi
Hi,
I've been tuning our new database server, here's some info...
CentOS Linux release 7.1.1503 (Core)
3.10.0-229.11.1.el7.x86_64
8 x 16GB 1600MHz PC3-12800 DDR3 - 128GB total
2 x AMD Opteron 6386SE 2.8GHz/16-core/140w - 32 cores total
4 x 300GB SAS 10k HDD
8/15 19:07, Gordon Messmer wrote:
On 08/17/2015 03:34 AM, Michael H wrote:
the [Service] section -
[Service]
LimitSTACK=12288
...
By the errors I will assume that it should be in the [Service] section.
I couldn't find confirmation of this online...
Yes, it belongs in the [Service] section.
$ m
Hi Tom,
I've ran systemctl damon-reload; systemctl restart postgresql-9.4 and
also tried rebooting. none of these options are working.
Michael
On 17/08/15 14:47, Tom Lane wrote:
Michael H writes:
I've tried the instructions at this URL:
https://ma.ttias.be/increase-open-file
s and just report that number back?
attempting to adjust systemd LimitSTACK parameter for the service is
proving more difficult than anticipated.
thanks
Michael
On 17/08/15 09:16, Michael H wrote:
a little update,
I've tried the instructions at this URL:
https://ma.ttias.be/increase-o
a little update,
I've tried the instructions at this URL:
https://ma.ttias.be/increase-open-files-limit-in-mariadb-on-centos-7-with-systemd/
I either get the same errors appear when I run systemctl daemon-reload;
systemctl restart postgresql-9.4
Aug 17 09:08:49 db1 pg_ctl[3343]: < 2015-08-17
Hi Chris,
On 14/08/15 17:19, Chris Mair wrote:
Hi All,
I'm tuning up my database and need to increase the max_stack_depth
parameter in postgresql.conf.
I've edited the /etc/security/limits.conf and added
* softstack 12288
* hardstack 12288
but I noticed
Hi All,
I'm tuning up my database and need to increase the max_stack_depth
parameter in postgresql.conf.
I've edited the /etc/security/limits.conf and added
* softstack 12288
* hardstack 12288
but I noticed the comments at the top of the file -
#This fi
Hi All,
I've been performance tuning a new database server for the past couple
of weeks with very mixed results, I've read every guide to tuning I can
locate on Google aswell as Gregory Smiths - Postgresql 9.0 High
Performance book.
The server is a HP DL385P gen8, dual processor AMD Opteron
14 matches
Mail list logo
