PGCon 2009, 1.diena
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!
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.
Birkas: Kanāda, konference, PostgreSQL
Vēl jau priekšā Leo Hsu un Regina Obe, bet šitas ar ir labs :)