PostgreSQL database langsom

og hvis du kører dine forespørgsler på database serveren med psql er den ligeså langsom?

Det er jeg svar skyldigt.
Det er en databaseløsning som er købt og mange af de forespørgsler er skjult for menulinjen, samt er alle php-filerne encoded med Zend.
Men nogle forespørgsler er meget hurtige mens andre er ekstremt langsomme selv om man nærmest sidder på serveren.
Er der noget man selv kan gøre for at tune en sådan database?

Ok, men tak for hjælpen

.

Ved godt spørgsmålet er lukket, men jeg er næsten 100% sikker på, at den dårlige performance skyldes dårligt database-struktur. Hvis dem der har lavet systemet har struktureret data uhensigtsmæssigt, ikke anvendt index eller bare de forkerte steder, har det en voldsomt betydning for performance.

Hvis struktureren er dårlig, hjælper det end ikke at købe en 16-CPU server. En forkert SQL-sætning kan hvis den er helt grel, få en super-server til at crashe. Jeg har arbejdet profesionelt med database-optimeringer og fundet ud af, hvad dårlige struktur-beslutninger kan føre til. Et manglende index på en tabel med 10.000 tupler kan betyde at en forespørgsel varer 3 minutter i stedet for 30 millisekunder.

Måske burde du klage over det produkt du har købt - skylden ligger sandsynligvis ikke hos hverken PostgrSQL eller maskinen.

dsj -
Hvad gør man så hvis man står med sådan en database, hvis alle forespørgsler ligger i de filer som er encoded med Zend?
Vi kan jo ikke få lov til at se de forespørgsler.
Jeg kan oprette et nyt spm. med point hvis  du ønsker det.

Det er lige meget med pointene. Afhængig af din situation, om det er et nyduvikling du har betalt for eller et standardprodukt, kontrakt-/garanti-forhold og hvor lang tid siden du rekvirerede produktet, vil jeg mene du har mulighed for at klage over produktet til leverendøren. 30 sekunder til visning af en side (selvfølgelig afhængig af indholdet) er normalt helt uacceptabelt. Hvis leverendøren har gjort et dårligt stykke arbejde, må denne udbedre problemet eller dække skaden økonomisk.

Hvis dine forhold gør at du ingen rettigheder har overfor leverendøren, kan du få en professionel til at kigge på selve databasen. Ud fra tabellerne, deres attributter og evt. constraints, må det være muligt at lure problemerne. MÅSKE kan man oprette nogle manglende index og på den måde skabe bedre performance, men er tabel-strukturen ganske enkelt uhensigtsmæssig, er den eneste løsning at ændre dette.

Nu er jeg ikke så meget inde i driften af PostgreSQL, men med MySQL er det muligt at få logget al eksekveret SQL. Det skulle undre mig om ikke dette også er muligt med PostgrSQL - så vil det være muligt at se SQL'en fra dit program. Stadig hjælper det ikke, hvis eneste løsning er, at ændre programmet.

Du har næppe rettigheder til at ændre i det købte produkt, og Zend gør også dette temmelig svært, om end stadig muligt. Er løsningen at ændre i produktet, må du hive fat i leverendøren og gøre bestemt opmærksom på, at leverencen fungerer uacceptabelt.

Hvad er det for et produkt, standardsystem eller nyudvikling? Hvornår købte du det, og hvad er det for et produkt? Jeg har forstand på IT-købekontrakter, så måske kan jeg hjælpe på den front, hvis det er ønsket og nødvendigt.

Databasen er en vikardatabase til brug for vikarbranchen. Du har vist også arbejdet med sådan noget - tror jeg.
Databasen består af 302 tabeller og sequences. I starten var der jo ikke mange oplysninger i den - så derfor var den ok hurtig. Nu kører vi konstant med 10 - 20 åbne ordrer og 150 vikarer som man vælger imellem. Dertil er koblet et løn og faktureringsmodul. Nu stener den bare.
Selve databasen kostede i sin tid for 1½ år siden kr. 50.000,00 og L & F- modulet kr. 50.000,00 som er nyt. Samt opdateringsabonnement osv. til 10.000 - 15.000 om året.
Det er et standardsystem som er solgt til mange vikarbureauer, men jeg tror vi få som har købt det hele. Vi snakker sammen med nogle af de andre vikarbureauer, som også synes databasen er ekstrem langsom.
Jeg vil kigge i kontraktensom blev underskrevet i 2002 og lige melde tilbage.
Vi blev lovet mundtligt at det ikke ville være et problem at få adgang til sourcefilerne, men det kan vi jo ikke.
Vi har fået som undskyldning for at databasen er langsom, at det er fordi at nogle forespørgsler skal gennem de fleste tabeller i databasen. men 30 sek. til et min. er lidt lang tid.

Det lyder til at der må være mulighed for at klage over et mangelfuldt produkt, men jeg er næsten sikker på, at de ikke i kontrakten lover noget omkring performance. På mig virker det som en uprofessionel og ikke-gennemtestet løsning. Det antal åbne ordre og vikarer nu nævner er ærlig talt ret små datamængder, som PostgreSQL snildt kan klare. Dog lyder 302 tabeller af ret meget, ja det svarer næsten til de større ERP-løsninger som Axapta.

Hvis du spørger mig, skyldes den dårlige performance et dårligt produkt, hvis problem ligger i database-designet.

Hvis de har lovet at du kan få adgang til sourcefilerne (vi må håbe de vil leve op til deres mundtlige løfter), må de vel kunne udlevere dem, men spørgsmålet er så, om du har rettigheder til at ændre i dem. Samtidig tror jeg, at det vil være en temmelig stor omgang at forbedre performance, medmindre det skyldes manglende indekseringer på tabellerne.

Nu ved jeg ikke hvor meget du er inde i databaser, men indekseringer anvendes på attributter der udføres joins på, således at databasen hurtigere kan finde frem til de ønskede tupler. PostgreSQL benytter som default binære træer, til at indeksere med, således et opslag på en tuppel, i gennemsnit vil tage en tidskompleksistet af log(n), hvor n er antallet af tupler. Hvis der ikke er lagt indekseringer på de attributter i tabellerne, som anvendes til at joine tabellerne i SQL'en, få man en linær tidskompleksitet, der svarer til antallet af kombinationsmuligheder tabellerne imellem. Joines f.eks. 3 tabeller, én med 10.000 tupler, én med 1.000 og den sidste med 100 tupler, giver det 1 milliard kombinationsmuligheder, der søges igennem fra ende til anden, til de forespurgte tupler er fundet.

Hvor ved du i øvrigt fra, at jeg vidst nok har arbejdet med sådan noget før? :)

Jeg talte med en af deres udviklere, som mente at det ville være at save den pind over de selv sad på, hvis de skulle udlevere noget som helst uden at det skulle koste penge.
Antallet af poster vokser stødt fra dag til dag og antallet af vikarer i alt siden sidste efterår tæller vel 1200. Dertil antal overenskomster som genereres til hver person som selvstændige poster, fuld historik, kunder, journal for hvert ring til vikar og kunde, mails, arbejdskalender, og vi har fat i folk hver dag og meget mere.
Hvordan tæller jeg alle poster i databasen?
Man kan se i menulinjen hvordan forespørgslen ser ud, men findes der et program der automatisk kan opsamle dem som de vil se ud?

Jeg var lige inde at kigge på dit website, derfor denne antydning ;-)

Jo, et sql-dump er vel på 30 Mb. efterhånden.

Egentlig mener jeg ikke, at du har noget at bruge sourcefilerne til, leverandøren bør selv udbedre performance-problemet, som godt kunne betragtes som en fejl i produktet. Den med at problemet ligger i mange tabeller der joines, er verdens dårligste undskyldning. Et stort ERP-system som Axapta kører på MS SQL-Server, der ikke regnes for at være hurtigere end PostgrSQL, og kan effektivt håndtere langt større datamængder i rigtig mange tabeller. Hvis de mange tabeller er et problem, måtte leverandøren vel have designet databasen anderledes - det er et spørgsmål om kompetence.

Som jeg ser det, har du nu 4 valg:

1. Tage kampen op med leverandøren, evt. allieret med andre brugere af samme produkt der enten allerede har samme problem, eller snart vil få det. Evt. kunne man forlange erstatning for tab grundet ringe drift eller skift til andet system - om du er i position til at kræve dette, afhænger selvfølgelig af købe-kontrakten.
2. Den ubehagelige: betale selv for skift til et nyt system, som også tager tid og vil volde virksomheden besvær.
3. Få en professionel til at kigge efter for mulige optimeringer direkte i databasen, ved f.eks. tilføjelse af indekseringer, dog uden at ændre på den eksisterende tabel-struktur. Dette koster mere begrænset, men du risikerer ikke at få noget ud af det. Et grundigt kig i alle tabellerne og deres constraints samt SQL-dumpet, vil kunne afsløre, om det er muligt at optimere noget.
4. Leve med den dårlige performance, der efter alt at dømme ikke bliver bedre i morgen.

Jeg kan godt være behjælpelig med nr. 3. Hvis skal finde ud af noget, kan du kontakte mig via email-adressen på mit website.

Den er besvaret før nedbruddet!

Jeg håber ikke at virke for nærgående, men jeg er egentlig vældig interesseret i at høre, hvordan det er gået siden. Har leverandøren valgt at gøre noget ved problemet, eller er problemet som det altid har været, eller værre?

Hej dsj
Leverandøren er gået konkurs men vi har fået kildekoden således, at vi selv kan udvikle på databasen inden for virksomheden.
Det er godt, at vi har fået kildefilerne - men ikke særlig smart, at ingen kan lave noget her og nu,
Jeg har forsøgt, at få databasen over på en FreeBSD server med nogle hurtigere diske.
Men det er svært, at compile den lidt specielle php-version til bsd. Så her står vi.

Det var noget af en drejning, må man sige. Måske man ser en sammenhæng mellem systemets duelighed (eller uduelighed) og virksomhedens success.

Når man har kildekoden, er det jo forholdsvis let at få optimeret databasen, og bl.a. se, om bedre indekseringer er løsningen, eller om der skal ændres i tabelstrukturen, og dermed også i PHP-koden.

Hvis jeg skal være ærlig, er jeg overbevist om, at ikke hurtigere diske vil løse dit problem, men er en relativ dyr og øjensynligt tidskrævende løsning, som i bedste fald vil give performance-forøgelser på 15-20%, hvor du egentlig har brug for flere 100%. De datamængder du nævner, kan betegnes som få, og bør kunne udtrækkes på millisekunder, medmindre vi snakker om store og krævende analyse-rapporter, som indeholder mange data - flere end hvad du beskriver.

Der skal andet end hardware-optimeringer til, for at vende performance. Jeg ville i første omgang se på følgende:

- Den logiske model, database-designet: Få afdækket de eventuelle flaske-halse, tabel-strukturen måtte have; f.eks. i form af for ren normalisering, eller forkert attribut-valg til nøgler.

- Den fysiske model: Hvordan primær-, fremmednøgler og indekseringer er opbygget.

- SQL-statements: Hvordan er de opbygget, og kan de uden at ændre i applikations-koden optimeres. SQL kan skrives på mange måder og stadig gøre præcis det samme, forskellen ligger i hastigheden, og det kræver kendskab til databasen måde at arbejde med SQl'en på, hvis den skal skrives godt.

- Selve applikationens design, altså PHP'en: Om koden er dårligt skrevet. Dog er de største gevinster sjældent at hente her, medmindre det står helt grælt til.

Ud fra en analyse af ovenstående områder, vil man så være i stand til at vælge de områder, der indenfor et rimeligt budget, vil kunne give det bedste resultat, altså den bedste performance-forøgelse.

Efterfølgende kunne man f.eks. supplere forbedringerne med bedre hardware, men du vil nok blive skuffet over resultatet, hvis ikke der også gennemføres andre software-optimeringer.

I første omgang ville det måske være en hjælp, at få udarbejdet en grov-analyse af problemstillinger, for uden de vilde omkostninger, at kortlægge hvor de største resultater kan hentes. Hvis du er interesseret heri, findes kontakt-info på mit CV, som du vi vidst har linket til - CV'et er i øvrigt ændret en del siden sidst :-)

I øvrigt, hvis tabel-strukturen viser sig at skulle ændres, er det i nogle tilfælde muligt at imulere den gamle struktur ved at oprette nogle views, således at PHP'en ikke skal ændres...