05. januar 2004 - 20:10Der er
18 kommentarer og 1 løsning
Har alle DBMS'er det samme problem som MySQL
Jeg har en MySQL 4 et-eller-andet kørende som DBMS for en del applikationer, mest web. En af applikationerne er dårligt kodet og kører ind imellem nogle nasty SELECT-statements med nogle nasty joins. Dette gør MySQL (kompileret til at anvende flere CPU'er) og dermed maskinen den kører på (dedikered maskine med dual CPU og 2 GB ram) bliver fuldstændig overbelastet, så belastet at de resten applikationer ikke får svar i 30-60 minutter.
Det jeg vil høre om er, om det blot er MySQL eller de andre kendte DBMS'er (PostgreSQL, DB2, Oracle, Interbase, MsSQL) også lider af det problem, at en enkelt applikation (én forbindelse) kan lægge beslag på alle ressourcer i så lang tid?
Problemet ligger vidst i at de joins der udføres er ret omfattende og at MySQL opretter en midlertidig tabel for at udføre de ønskede joins. Mens forespørgslen er under udførelse låses alle anvendte tabeller. Ret mig endelig, hvis denne opfattelse er forkert. Hvis det er rigtigt, gør de andre DBMS'er også sådan, eller har de en smartere måde. Her er jeg godt klar over, at de fleste andre kan finde ud af at låse på række-niveau i stedet for på tabel-niveau.
Hvis det er en ren select, så burde det slet ikke give nogen låse. Som regel vil permance gå ned på maskinen, men hvis en select skal køre så længe, så er der alvorlige problemer.
Jeg kender mest til Oracle, og som regel kan det løses - en omskrivning er selvfølgelig optimal, men alene trimning af maskineri og oracle kan løse meget.
Serveren skulle ikke være underdimensioneret, den kører Debian og MySQL svarer overhovedet ikke andre applikationer når problemet opstår, andre processer svarer næsten ikke. F.eks. tager det flere minutter at logge på med SSH.
De forskellige applikationer kører forskellige databaser og skulle derfor ikke låse ting for hinanden, med mindre MySQL laver et eller andet smart i baggrunden. Og jo, det er en query der skaber problemet. Det jeg bare godt vil vide er, om andre database ville gøre det bedre, således at en enkelt database-forbindelse kan lægge beslag på alle DBMS'ens ressourcer. Jeg ved godt hvordan tingene bør laves, men lige nu er det som det er.
At andre ikke-database processer hænger er ikke acceptabelt. Enten har den Debian en fejl i scheduleringen eller så har MySQL fået hævet sin prioritet.
Hvis det er samtdige database operationer, så er der principielt mulighed for konflikter p.g.a. låsninger.
Men du siger at de ikke opererer på samme data ????
Mystisk !
Kan det være mangel på memory således at der bruges roterende memory ?
Kan det være temporære tabeller der er flaskehalsen ?
Indtil problemet er specifikt identificeret er det meget svært at sige om en anden database vil håndtere det bedre.
Det kan meget vel være temporære tabeller der er problemet, det problem har jeg nemlig haft før med en anden applikation. Udfører andre DBMS'er også joins ved brug temporære tabeller?
From MySQL Version 3.23, you can use the TEMPORARY keyword when you create a table. The temporary table is visible only to the current connection, and will be deleted automatically when the connection is closed.
Det med temporære tabeller er ikke noget jeg decideret har læst, men hørt. Men ja, så vil en anden DBMS vel kunne klare det bedre. PostgreSQL skulle også være hurtigere til det krævende arbejde. Jeg har desuden hørt skarp kritik af MySQL's skaleringsevne.
Har du mulighed for at slå parallelisme fra på queries, så gør det. Query parallelisme giver ofte problemer pga synkronisering indenfor de enkelte dele af querien både på MS SQL og Oracle.
En anden ting, check om du kan omskrive din query så den er simplere - jeg kender ikke MySQLs parser og query rewriter i detaljer, men bestemte formuleringer performer typisk dårligere end andre.
Fx er IN () statements typisk langsommere end EXISTS() pga implicit sortering, OR statements (og alle ikke-determitistiske funktioner) forhindrer brugen af indeks etc.
Query parallelisme >> er det noget du har noget dokumentation på et eller andet sted på nettet evt.? Som nævnt kører maskinen dual CPU, så er det ikke helt rigtigt, risikerer jeg at sænke performance ved at slå det fra.
At disable Query parallelisme forhindrer ikke udnyttelse af flere cpu'er - det gør blot at den enkelte query kun kører på en cpu adgangen.
Mht links; Du vil kunne finde adskillige referencer til problemer i forb. det på Metalinks (Oracle) og Microsofts supportsider. Spørgsmålet er, om de er generelt tilgængelige...
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
