Drop Down MenusCSS Drop Down MenuPure CSS Dropdown Menu

PostgreSQL memory allocation for 16 GB

-

------This Is For 16GB RAM BSNL CLOUD----------
shared_buffers = 1GB               (5-25 %)    
effective_cache_size =4GB  default (50-80 %)   ---->>(shared_buffers+page cache) for dedicated server only
work_mem = 128MB                   (0.3-1 %)
maintenance_work_mem = 1GB         (0.5-4 % )
temp_Buffer =  32MB                    ---->>default is better( setting can be changed within individual sessions)
max_wal_senders = 10
wal_keep_segments = 64
wal_buffers = 32MB                     ----->>leave this default 3% of shared buffer is better
random_page_cost = 3.0                 ----->>For fast disks you could reduce that to 3.0
max_connections = 1000

Comments

Post a Comment

Popular posts from this blog

PostgreSQL pgBadger

-
pgBadger is a PostgreSQL log analyzer built for speed with fully reports from your PostgreSQL log file. It's a single and small Perl script that outperforms any other PostgreSQL log analyzer.It is written in pure Perl and uses a JavaScript library (flotr2) to draw graphs so that you don't need to install any additional Perl modules or other packages. Furthermore, this library gives us more features such as zooming. pgBadger also uses the Bootstrap JavaScript library and the FontAwesome webfont for better design. Everything is embedded.pgBadger is able to autodetect your log file format (syslog, stderr or csvlog). It is designed to parse huge log files as well as gzip compressed files. See a complete list of features below. Supported compressed format are gzip, bzip2 and xz. For the xz format you must have an xz version upper than 5.05 that supports the --robot option.All charts are zoomable and can be saved as PNG images.You can also limit pgBadger to only report errors or rem…
Read more

PostgreSQL Pgbadger Installation On Linux

-
Image
PgBadger is a tool that analyzes PostgreSQL log files and generates reports on execution of SQL and server operation. Statistical reports analyzed from a number of perspectives can be useful not only for grasping the usual database operation but also as a hint for performance improvement.

The report output by pgBadger has the following features. Graph output in HTML format Many statistical objects Daily, Weekly unit creation possible 1.Graph output in HTML format
Many of the analysis results can be displayed in graph form by outputting the report in HTML format (output in text format or JSON format is also possible). By analyzing the log information graphed, it is much more prospective for people to see than the raw log data. So, if you do not need to handle it with another tool separately, we recommend report output in HTML format.

2.Many statistical objects A lot of data useful for database performance analysis is output in the report as shown below. Queries (total number of executions, maxi…
Read more

How to configure Replication Manager (repmgr) ?

-
`repmgr` is a suite of open-source tools to manage replication and failover within a cluster of PostgreSQL servers. It enhances PostgreSQL's built-in replication capabilities with utilities to set up standby servers, monitor replication, and perform administrative tasks such as failover or switchover operations. The current `repmgr` version (3.3) supports all PostgreSQL versions from 9.3 to 9.6. Overview The repmgr suite provides two main tools:1.repmgr - a command-line tool used to perform administrative tasks such as: - setting up standby servers - promoting a standby server to master - switching over master and standby servers - displaying the status of servers in the replication cluster 2.repmgrd is a daemon which actively monitors servers in a replication cluster and performs the following tasks: - monitoring and recording replication performance - performing failover by detecting failure of the master and promoting the most suitabl…
Read more

What's is the difference between streaming replication Vs hot standby vs warm standby ?

-
Warm Standby:
Its introduced in PostgreSQL 8.3(IIRC).
1. It is based on WAL log shipping which typically means WAL archives generated on Master will be transferred and applied at Standby side. So Warm Standby always waits for the WAL archive in which Master is currently writing and keeps throw messages like "cp: cannot stat <archive>: No such file or directory". So it is always one archive behind than Master and data loss will be max of 16MB(assuming a healthy warm standby by :-) )
2.called file based log shipping:only records in a filled file are shipped, what's referred to as file-based log-shipping
3.In postgresql.conf file, you would need to change just three parameters in master; wal_level to archive, archive_mode and archive_command, however nothing in postgresql.conf file at standby side.
On Master: wal_level = archive archive_mode = on archive_command = 'cp %p /path_to/archive/%f' 4. In recovery.conf file, three parameters; standby_mode, restore_…
Read more

Script to kill ALL IDLE Connection In postgreSQL

-
1.MORE I/O POSTGRESQL KILLING ALL IDLE CONNECTION FOR MONITORING PURPOSES:
This following script is used for killing all idle connection and you can use it as a monitoring puposes like how many idle query is running for a hour and how many 'idle', 'idle in transaction', 'idle in transaction (aborted)' and  'disabled' queries are running for a hour and when it killed and how many hours is taken,schedule this script every one hours don't schedule it every 2 minutes and 1 minutes because it will be taken more I/O(4 times) than following second script,if you want shedule this script every 1 or 2 minutes use second script it will take less I/O.
cat /home/postgres/idle.sh #!/bin/bash HOSTNAME=`hostname` PSQL="/opt/PostgreSQL/9.3/bin/psql" PORT=5432 HOST="localhost" DB="template1" USER="postgres" DATE2=`date +'%d%m%G'` DETAIL2="/tmp/KILL_ALL_IDLE_$DATE2.log" touch $DETAIL2 IDLECONNTIME2=`$PSQL -d $DB…
Read more