pgeast 2010 - postgresql at my yearbook

19
PostgreSQL at myYearbook.com Gavin M. Roy Chief Technology Officer myYearbook.com pgEast 2010

Upload: gavin-m-roy

Post on 10-Apr-2015

99 views

Category:

Documents


4 download

TRANSCRIPT

Page 1: PgEast 2010 - PostgreSQL at My Yearbook

PostgreSQL at myYearbook.com

Gavin M. RoyChief Technology OfficermyYearbook.com

pgEast 2010

Page 2: PgEast 2010 - PostgreSQL at My Yearbook

About myYearbook.com

2007 - 100M Page views per Month

2010 - 1.5B Page views per Month

Top 5 Social Network in the United States as measured by Hitwise

In the Top 30 most trafficked sites in the United States as measured by ComScore

99% Uptime

Page 3: PgEast 2010 - PostgreSQL at My Yearbook

Growth is a double-edged sword.

2007: Midnight Calls2008: Sizing hardware2009: Complex2010: Connections

Page 4: PgEast 2010 - PostgreSQL at My Yearbook

“The best laid schemes o’ mice an’ menGang aft agley”

- Robert Burns, To a Mouse

SAN - Fiber ChannelRamSAN - Fiber ChanneliSCSI? Too slow

Started on DASFusionIO?

Page 5: PgEast 2010 - PostgreSQL at My Yearbook

Plan for Growth Things we’ve learned about concurrency & data growth

Concurrency:Too many backendsPool with pgBouncer

Page 6: PgEast 2010 - PostgreSQL at My Yearbook

Too Much Traffic

Too Many BackendsToo Much Lock ContentionSlow PostgreSQL Queries

pgBouncer to the Rescue

Page 7: PgEast 2010 - PostgreSQL at My Yearbook

Table Partitioning

• Supported in PostgreSQL as of 8.1

• Excellent method for maintaining data

• Allows for removal of aged data without bloat

• Focused SELECTS while allowing ad-hoc SELECT across all partitions

Page 8: PgEast 2010 - PostgreSQL at My Yearbook

Vertically Partitioning Data

• Isolate application data in different database servers

• Replicate common data needed for joins

Page 9: PgEast 2010 - PostgreSQL at My Yearbook

Spread table data across multiple database servers

Horizontally Partitioning Data

Page 10: PgEast 2010 - PostgreSQL at My Yearbook

Ancient Mountaineering Adage:

“Anything that can possibly go wrong, does.” - Jack Sack (1952)

Daily Backups and Offsite (worst)

Warm Standby

PostgreSQL 9.0 Hot+Stream

Page 11: PgEast 2010 - PostgreSQL at My Yearbook

How to kill PostgreSQL performance.

Page 12: PgEast 2010 - PostgreSQL at My Yearbook

Inadequate Hardware

Not Enough RamNot Enough Disk

ControllersSlow Communication

CPU Oversaturation

Page 13: PgEast 2010 - PostgreSQL at My Yearbook

Lock Contention == DeathLong Running ExclusiveHigh Share LocksReduce by partitioningconcurrent reindex, etc

Page 14: PgEast 2010 - PostgreSQL at My Yearbook

Bloat == Slower DeathMVCCHOT (Tuples)Index Bloat

Page 15: PgEast 2010 - PostgreSQL at My Yearbook

“Knowledge is Power”

- Sir Francis Bacon

Page 16: PgEast 2010 - PostgreSQL at My Yearbook

Reacting can be Proactive

• check_postgres.pl by Greg Mullane

• Nagios plugin

• Bloat

• Management activity such as last analyze and vacuum

• wal file count, txid wrap around, sequence exhaustion

• many other items it checks

Page 17: PgEast 2010 - PostgreSQL at My Yearbook

Be Trendy

• Know your database behavior over time

• Predict future issues and behavior

• Identify issues as they occur

• Review impact of maintenance

• Know if your heap use exceeds your index use

• Look for daily change

Page 18: PgEast 2010 - PostgreSQL at My Yearbook

Trending and Analysis at myYearbook.com

• Cacti - http://www.cacti.net

• Posuta - http://code.google.com/p/posuta/

• pgFouine - http://pgfouine.projects.postgresql.org/

• Staplr - http://github.com/myYearbook/staplr

Page 19: PgEast 2010 - PostgreSQL at My Yearbook

http://twitter.com/CradAny Questions?