PGCon 2009, 1.diena

PGCon 2009

PGCon 2009

Pirmā PostgreSQL konferences diena aizritējai visai mierīgi ar aptuveni 60-70 dalībniekiem.

Pirmais uzstājās Stephen Frost ar prezentāciju PostgreSQL Access Controls.  Frosts pats ir viens no PostgreSQL attīstītājiem, kurš piedalījies šo kontroles metožu programmēšanā. Prezentācijas laikā tika aplūkotas autentifikācijas  metodes, lietotāju lomas un autorizācijas metodes. Pirmējā vairāk skāra serveru konfigurāciju un komunikācijas, ar ko īpaši nav nācies nodarboties, tamdēļ dzirdēto daudz nekomentēšu, lai ‘neiebrauktu auzās’. Varu vien secināt, ka autentifikācijas iespēju ir pietiekoši daudz un dažādu, lai apmierinātu katra vajadzības. Kam interesē sīkāk, tad pilno prezentāciju var atrast šeit. Stāsts par lietotāju ‘lomām’ (roles) bija visai interesants un lietderīgs, jo līdz šim nebiju vēl redzējusi sakarīgu un pilnvērtīgu lomu izmantošanu. Smalka PostgreSQL sistēma var sastāvet no vesela lomu koka, kur hierarhiski pakārtotas lietotāju un lietotāju grupu tiesības darboties iekš datubāzes. Autorizācija praktiski kontrolē, kādas darbības (apskatīt, ievietot vai labot datus) katrs lietotājs var veikt, kā arī kurā vietā (shēmā, tabulā un kolonnā (junums PostgreSQL 8.4 ) ) darbības atļautas.

‘PostgreSQL access controls’ ir salīdzinoši vienkārša lieta. Īsts izaicinājums  ir datubāzu sistēmas uzstādīšana un konfigurēšana tā, lai tā darbotos ar maksimālo darbspēju un maksimali izmantotu pieejamos resursus. Josh Berkus prezentācija Performance Whack-a-Mole II aplūkoja, kā atrast ‘datubāzes lēnuma’ cēloņus jeb ‘kā nosist kurmi’.

Whack-a-Mole!

Whack-a-Mole!

Berkus izdala 4 likumus, kas jāpatur prātā meklējot veiktspējas problēmas cēloņus:

1) The Layer Cake

Datubāzes sistēma parasti sastāv no 5 slāņiem (hardware, operating system, PostgreSQL, middleware, application)  gluži kā kārtainā kūka nevis no PostgreSQL vienas pašas. Tādēļ visbiežāk datubāzes ‘lēnuma problēma’ nav PostgreSQL problēma, bet vaina drīzāk slēpjas kādā citā no atlikušajām 4 komponentēm.

2) Hockey Stick

Mazāk par 10% ‘kurmjiem’ ir atbildīgi par 90% datubāzes darbspējas zudumiem.

3) The Whack-a-Mole Effect

Vienlaicīgi var ieraudzīt tikai vienu, lielāko, ‘kurmi’. Lai ieraudzītu nākošo problēmu parasti jātiek galā ar iepriekšējo, kas ir lielāka par sekojošo.

4) Dažādiem aplikāciju veidiem (web aplikācijā, Online Transaction Procesing, data warehousing) parasti ir dažādi ‘kurmju’ veidi, attiecīgi, nepieciešama atšķirīga pieeja.

Problēmas cēloņi jāsāk meklēt ievācot sīku informācija par visām sistēmas komponentēm, ne tikai PostgreSQL konfigurāciju. Tālāk ‘kurmji’ var tikt medīti ar dažādiem operētājsistēmas un PostgreSQL darbības analīzes rīkiem.

Šādi tādi lietderīgi operētājsisēmas darbības analīzes rīki (monitoringam un žurnalēšanai):  ps, pg_top, pg_bench, mpstat, vmstat, iostat, sar, dtrace. Test-programmas: dd, bonnie++, iozone, pg_bench, dbt2, pgUnitTest, EAstress, BenchmarkSQL.

PostgreSQL datubāzes darbības ieskatiem pieejamas dažādas funkcijas un statistiku apkopojošas tabulas: pg_stat_databse, pg_database_size,  pg_relation_size, pg_stat_activity, pg_locks, pg_stat_user_tables, pg_stat_user_indexes, pg_stat_bgwriter, pg_stat_statements, pg_stat_user_functions, pg_log, pg_fouine (log parser) ) u.c.

Izrādās, ka reizēm tomēr ir vērts izmantot EXPLAIN ANALYZE, jo tas palīdz ieraudzīt, kur PostgreSQL nepareizi aprēķina tabulu izmērus vai nepareizi uzstāda ‘izmaksas’, respektīvi, ir tiešā veidā redzams, kamdēļ vaicājuma izpildīšana aizņem tik daudz laika.

Cerams, ka drīzumā šī vērtīgā prezentācija parādīsies šeit, kur varēsiet smelties vairāk informācijas par PostgreSQL datubāzes analīzes rīkiem.

Nosit pats savu kurmi te!

Dalies priekā:

Birkas: , ,

Viens komentārs to “PGCon 2009, 1.diena”

  1. Vēl jau priekšā Leo Hsu un Regina Obe, bet šitas ar ir labs :)

Atstāt savu komentāru