Aniruddha Deshpande, Prajakta Dhote March 3, 2017 Case Study of Critical System – 9.4 PostgreSQL Performance
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Aniruddha Deshpande, Prajakta Dhote
March 3, 2017
Case Study of Critical System – 9.4
PostgreSQL Performance
©2
01
7 M
ast
erc
ard
. Pro
pri
eta
ry a
nd
Co
nfi
de
nti
al.
2MARCH 3, 2017
• PostgreSQL Performance Proactive and Reactive Proactive Approach
• Reactive ApproachWhat to follow and we have followed
Agenda
©2
01
7 M
ast
erc
ard
. Pro
pri
eta
ry a
nd
Co
nfi
de
nti
al.
3MARCH 3, 2017
• Bring Up Current Pain Points
Reactive Approach
©2
01
7 M
ast
erc
ard
. Pro
pri
eta
ry a
nd
Co
nfi
de
nti
al.
4MARCH 3, 2017
• Technical Analysis of entire systems
- Gather Disk/Memory info
- System Anlaysis with Splunk and Dynatracetools.
- Splunk tool gathers system stats including CPU, Memory, I/O etc.
-Dynatrace captures transaction flow of application from end user to application layer.
Reactive Approach
©2
01
7 M
ast
erc
ard
. Pro
pri
eta
ry a
nd
Co
nfi
de
nti
al.
5MARCH 3, 2017
• Database Findings
- Top SQL statements
- Ugly SQL’s
- Peak time hit ratio
- Partitioning
- DB growth Pattern
- Indexing
- Vacuum
Reactive Approach
Pull out data from DB end
©2
01
7 M
ast
erc
ard
. Pro
pri
eta
ry a
nd
Co
nfi
de
nti
al.
6MARCH 3, 2017
• Memory
• CPU
• Network
• Disk
Server data tells about your hosts’ health
Proactive Approach
©2
01
7 M
ast
erc
ard
. Pro
pri
eta
ry a
nd
Co
nfi
de
nti
al.
7MARCH 3, 2017
• Do not run anything besides PostgreSQL on the host
• If PostgreSQL is in a VM, remember all of the other VMs on the same host
• Disable the Linux OOM killer
• Sessions in the database
• Using the database as a filesystem
• Frequently-locked singleton records
• Very long-running transactions
• Using INSERT instead of COPY for a huge load of data
• Mixing transactional and data warehouse queries on the same database
What to avoid – Too small to notice but trust us.. They gives results.
Proactive approach
©2
01
7 M
ast
erc
ard
. Pro
pri
eta
ry a
nd
Co
nfi
de
nti
al.
8MARCH 3, 2017
• Unused indexes
• Bloated indexes
• Bloat
• Vacuuming
Do periodic checks for
Proactive Approach
©2
01
7 M
ast
erc
ard
. Pro
pri
eta
ry a
nd
Co
nfi
de
nti
al.
9MARCH 3, 2017
• Do you see these errors on your database server –ERROR: could not read block……….
ERROR: invalid page header in block…………
ERROR: missing chunk number 0 for toast value………..
• This suggests possible corruption
• What impact does it have on my database operation?- It may halt your complete database operation - Crash - Wrong results- Does that got into your backups as well?
Corruption
Proactive Approach
©2
01
7 M
ast
erc
ard
. Pro
pri
eta
ry a
nd
Co
nfi
de
nti
al.
10MARCH 3, 2017
• How corruption can be detected - pg_filedump- pg_dumpall/pg_dump and pg_restore- pg_catcheck – Catalog integrity check utility - Checksums
Corruption Part 2
Proactive Approach
©2
01
7 M
ast
erc
ard
. Pro
pri
eta
ry a
nd
Co
nfi
de
nti
al.
11MARCH 3, 2017
• Great tool
• Extract reports and do a detailed analysis even though no one reports problem
• Try to check for running queries. Optimize wherever you can.
• PgBadger can give you great hints about performance.
• Cron periodic pgbadger reports. Share with application teams.
PgBadger
Proactive Approach
©2
01
7 M
ast
erc
ard
. Pro
pri
eta
ry a
nd
Co
nfi
de
nti
al.
12MARCH 3, 2017
• Backups are very important.
• Can save you from all the bad possibilities after disaster.
• But are my backups really a backup? Or just a bunch of files?
• Ask yourself, when did you tried to restore the backup last time?
• Backups can really help you when they are valid.
• Do periodic restore of your backups on same hardware server.
• This can provide you RTO/RPO values.
Backups
Proactive Approach
©2
01
7 M
ast
erc
ard
. Pro
pri
eta
ry a
nd
Co
nfi
de
nti
al.
Questions
13
Related Documents
