|
|
 | Clustering af MSSQL 7 server
Fra : Henrik Back |
Dato : 08-02-01 10:36 |
|
Hej !
Jeg driver et stort website som er konfigureret således:
SQLServer: Dual P850 1 GB ram 2 raid 1 0 Arrays (tempDB på eget array)
6 stk. webserverer P 850 512 Mb
Vi har nu tunet og optimeret med storedprocedures og asp tuning i 2 mdr.
Dette har givet en del, men der kommer hele tiden flere brugerer på sitet.
Vi er nu i den situation at vores sqlserver er belastet med 100% næsten hele
tiden..
Vi går nu i overvejelser om at købe en 4 vejs xeon 700 1 mb cache, men en
sådan maskine koster i nabolaget af 250.000 Mit spørgsmål er om vi ved at
købe en maskine magen til den nuværende sqlserver vil kunne køre
clustering??
Lad os sige jeg har 250.000 og skal have løst mit problem... Hvordan skal de
bruges...
Mvh
Henrik
| |
 Thomas Jensen, pil.d~ (08-02-2001)
| Kommentar
Fra : Thomas Jensen, pil.d~ |
Dato : 08-02-01 10:46 |
|
On Thu, 8 Feb 2001 10:35:48 +0100, "Henrik Back" <henrik@back.dk>
wrote:
>Jeg driver et stort website som er konfigureret således:
>
>SQLServer: Dual P850 1 GB ram 2 raid 1 0 Arrays (tempDB på eget array)
>
>6 stk. webserverer P 850 512 Mb
>
>Vi har nu tunet og optimeret med storedprocedures og asp tuning i 2 mdr.
>Dette har givet en del, men der kommer hele tiden flere brugerer på sitet.
>Vi er nu i den situation at vores sqlserver er belastet med 100% næsten hele
>tiden..
>
>Vi går nu i overvejelser om at købe en 4 vejs xeon 700 1 mb cache, men en
>sådan maskine koster i nabolaget af 250.000 Mit spørgsmål er om vi ved at
>købe en maskine magen til den nuværende sqlserver vil kunne køre
>clustering??
>
>Lad os sige jeg har 250.000 og skal have løst mit problem... Hvordan skal de
>bruges...
Personligt ville jeg nok anbefale at få nogle 3. parts eksterne og
uvildige øjne til at kigge på implementationen... hardwareskalering
vil kun afhjælpe symptomerne, men ikke de reelle problemer.
At lade de oprindelige reviewe noget er ikke altid optimalt af
psykologiske årsager 
ps. har du ikke en url... det lyder noget voldsomt at det setup skulle
kunne presses i bund.
pps. jeg skal nok undlade at sige noget religiøst om mickey-platformen
og dennes krav til hardware
--
vh
Thomas Jensen
http://pil.dk/
| |
Peter Lykkegaard (08-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 08-02-01 11:26 |
|
"Thomas Jensen, pil.dk" <tj@dev.null> wrote in message
news:u5q48tsc06u85cq7l940f3d6vs2tqt8ooa@4ax.com...
>
> pps. jeg skal nok undlade at sige noget religiøst om mickey-platformen
> og dennes krav til hardware
Det er sandsynligvis database implementeringen der fejler
mvh/Peter Lykkegaard
| |
Henrik Back (08-02-2001)
| Kommentar
Fra : Henrik Back |
Dato : 08-02-01 14:37 |
|
>
> ps. har du ikke en url... det lyder noget voldsomt at det setup skulle
> kunne presses i bund.
>
Http://www.dating.dk
| |
Peter Lykkegaard (08-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 08-02-01 11:32 |
|
"Henrik Back" <henrik@back.dk> wrote in message
news:jLtg6.80$uw2.1667@news.get2net.dk...
>
> Vi har nu tunet og optimeret med storedprocedures og asp tuning i 2 mdr.
> Dette har givet en del, men der kommer hele tiden flere brugerer på sitet.
> Vi er nu i den situation at vores sqlserver er belastet med 100% næsten
hele
> tiden..
>
Det er sandsynligvis forkert implementering af databasen
I flæng kan nævnes
For meget brug af DISTINCT
Manglende indekses
Brug af SELECT *
Brede tabeller
Manglende WHERE clauses
Brug af bereregninger i WHERE clauses
Forkert brug af clustered indekses
Listen er uendelig lang
Kik evt på www.mssqlserver.com eller http://www.sql-server-performance.com/
Har du/I brugt Query Analyzer/Profiler der følger med MSSQL
Hvordan ser hitrate ud mht fange data i cache, hvis den erlav så smid mere
RAM efter maskineriet
Er MSSQL configureret til at bruge 1 Gb RAM?
Den optimale brug af RAID er
System på spejl
Data på read optiemret RAID
Log på write optimeret RAID
evet 3 seperate controllere
Få evt fat i en pusher der kan sin MSSQL til fingerspidserne
mvh/Peter Lykkegaard
| |
Henrik Back (08-02-2001)
| Kommentar
Fra : Henrik Back |
Dato : 08-02-01 14:48 |
|
> Kik evt på www.mssqlserver.com eller
http://www.sql-server-performance.com/
Vi har i næsten en måned tunet koden / sqlstatements og cachet masser af
opslag til sessionvar
> Har du/I brugt Query Analyzer/Profiler der følger med MSSQL
JA
> Hvordan ser hitrate ud mht fange data i cache, hvis den erlav så smid mere
> RAM efter maskineriet
Der er desværre ikke plads til mere i maskinen.. 4 256MB klodser
> Er MSSQL configureret til at bruge 1 Gb RAM?
Ja
> Den optimale brug af RAID er
> System på spejl
Vi ikke systemet på RAID
> Data på read optiemret RAID
> Log på write optimeret RAID
hmm. ok.. Vi har lagt temp DB'en på eget RAID
> evet 3 seperate controllere
>
Vi har 2 controllerer (Adaptec 2100)
> Få evt fat i en pusher der kan sin MSSQL til fingerspidserne
Kender du nogle der kan det??
Har snakket med Dell der siger maskine med 4 eller 8 CPU'er..
Henrik
| |
 Peter Lykkegaard (08-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 08-02-01 14:56 |
|
"Henrik Back" <henrik@back.dk> wrote in message
news:Trxg6.233$uw2.3964@news.get2net.dk...
> Har snakket med Dell der siger maskine med 4 eller 8 CPU'er..
>
Prøv lige at gange en MSSQL Ent processorlicens med 8
Du ryger langt over de 250K
Dell skal jo sælge hardware så det er deres "bedste" bud
mvh/Peter Lykkegaard
| |
Peter Lykkegaard (08-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 08-02-01 15:02 |
|
"Henrik Back" <henrik@back.dk> wrote in message
news:Trxg6.233$uw2.3964@news.get2net.dk...
> > Data på read optiemret RAID
> > Log på write optimeret RAID
>
> hmm. ok.. Vi har lagt temp DB'en på eget RAID
>
Det er *ikke* tempdb
Det er logfilerne til dine database
Laver du fx en database der hedder dating så vil du en fil der hedder
dating.mdf og fil der hedder dating.ldf
Se properties på din "dating" database - vælg andet faneblad "Transaction
Log"
Den filhenvisning skal være til eget Raid (sammen med evt andre log filer)
Efter min bedste overbevisning
mvh/Peter Lykkegaard
| |
Stig Johansen (08-02-2001)
| Kommentar
Fra : Stig Johansen |
Dato : 08-02-01 15:07 |
|
Hej.
"Peter Lykkegaard" <polonline@hotmail.com> wrote in message
news:%Cxg6.238$uw2.4456@news.get2net.dk...
>
> "Henrik Back" <henrik@back.dk> wrote in message
> news:Trxg6.233$uw2.3964@news.get2net.dk...
> > > Data på read optiemret RAID
> > > Log på write optimeret RAID
> >
> > hmm. ok.. Vi har lagt temp DB'en på eget RAID
> >
> Det er *ikke* tempdb
Du Peter, tempdb er lige så vigtig, da der er der alle mulige temporære data
såsom sorteringer osv. ligger.
> Det er logfilerne til dine database
>
<klip>
mvh
Stig Johansen.
| |
Peter Lykkegaard (08-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 08-02-01 15:15 |
|
"Stig Johansen" <e08@oes.dk> wrote in message
news:zKxg6.28812$zw.557091@twister.sunsite.dk...
>
> Du Peter, tempdb er lige så vigtig, da der er der alle mulige temporære
data
> såsom sorteringer osv. ligger.
>
Hmm, problemet med tempdb er at du både/læser og skriver
I følge de tykke bøger jeg har læst så er det RAID optimeret til skrivning
af logfiler der skulle gøre forskellen
Men som sagt så har ikke haft lejlighed (råd/brug for) til at afprøve det i
virkeligheden
Eller måske husker jeg forkert
mvh/Peter Lykkegaard
| |
Stig Johansen (08-02-2001)
| Kommentar
Fra : Stig Johansen |
Dato : 08-02-01 16:17 |
|
Hej.
"Peter Lykkegaard" <polonline@hotmail.com> wrote in message
news:iPxg6.252$uw2.4614@news.get2net.dk...
>
> "Stig Johansen" <e08@oes.dk> wrote in message
> news:zKxg6.28812$zw.557091@twister.sunsite.dk...
> >
> > Du Peter, tempdb er lige så vigtig, da der er der alle mulige temporære
> data
> > såsom sorteringer osv. ligger.
> >
> Hmm, problemet med tempdb er at du både/læser og skriver
> I følge de tykke bøger jeg har læst så er det RAID optimeret til skrivning
> af logfiler der skulle gøre forskellen
> Men som sagt så har ikke haft lejlighed (råd/brug for) til at afprøve det
i
> virkeligheden
>
Hvis der bliver brugt mange opslag, hvor der skal benyttes tempdb,
eksempelvis en select ... order by, hvor indexet ikke afspejler sorteringen,
bliver temdb voldtaget.
Den ultimative løsning for performance er derfor:
1 kanal til OS+virtuel memory
1 kanal til db-filer
1 kanal til log
1 kanal til temdb
Den ekstermt ultimative løsning er derudover at lægge indexer og data i hver
sin(e) filegroups, og sprede disse på hver sin kanal.
Vi er enige om at den første drastiske performance forbedring fås ved at
lægge logfilerne på separat drev. Og som du siger her er det
skrivehastigheden, der eer afgørende.
mvh
Stig Johansen.
| |
Claus (08-02-2001)
| Kommentar
Fra : Claus |
Dato : 08-02-01 16:23 |
|
> Hvis der bliver brugt mange opslag, hvor der skal benyttes tempdb,
> eksempelvis en select ... order by, hvor indexet ikke afspejler
sorteringen,
> bliver temdb voldtaget.
> Den ultimative løsning for performance er derfor:
> 1 kanal til OS+virtuel memory
> 1 kanal til db-filer
> 1 kanal til log
> 1 kanal til temdb
> Den ekstermt ultimative løsning er derudover at lægge indexer og data i
hver
> sin(e) filegroups, og sprede disse på hver sin kanal.
>
> Vi er enige om at den første drastiske performance forbedring fås ved at
> lægge logfilerne på separat drev. Og som du siger her er det
> skrivehastigheden, der eer afgørende.
Agree, men det hjælper sådan set ikke ret meget når det ikke er IO-systemet
der er flaskehalsen men derimod at cpu'erne konstant 'slår mod loftet'.
Btw. så mener jeg nu mere at tempdb'en bliver brugt i forbindelse med
joins...
| |
Peter Lykkegaard (08-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 08-02-01 16:40 |
|
"Claus" <claus@cyberdude.com> wrote in message
news:nSyg6.284$uw2.5080@news.get2net.dk...
>
> Btw. så mener jeg nu mere at tempdb'en bliver brugt i forbindelse med
> joins...
>
Den er holdeplads for midlertidige tabeller ved fx tablescans og andre
besynderligheder
Fra BOL
"tempdb holds all temporary tables and temporary stored procedures. It also
fills any other temporary storage needs such as work tables generated by SQL
Server. "
mvh/Peter
| |
Peter Lykkegaard (08-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 08-02-01 16:30 |
|
"Stig Johansen" <e08@oes.dk> wrote in message
news:xLyg6.28987$zw.563236@twister.sunsite.dk...
> Hvis der bliver brugt mange opslag, hvor der skal benyttes tempdb,
> eksempelvis en select ... order by, hvor indexet ikke afspejler
sorteringen,
> bliver temdb voldtaget.
Og netop er det så crucial at fedte med sine T-SQL ting 
Og gå langt uden om al brug af cursor ting
> Den ultimative løsning for performance er derfor:
> 1 kanal til OS+virtuel memory
> 1 kanal til db-filer
> 1 kanal til log
> 1 kanal til temdb
> Den ekstermt ultimative løsning er derudover at lægge indexer og data i
hver
> sin(e) filegroups, og sprede disse på hver sin kanal.
Ok , den er lidt udvidet i forhold til det jeg har set
Men som skrevet andetsteds så er det vist ikke IO systemet der driller
Henrik
>
> Vi er enige om at den første drastiske performance forbedring fås ved at
> lægge logfilerne på separat drev. Og som du siger her er det
> skrivehastigheden, der eer afgørende.
>
Ok, som sagt så har jeg ikke haft lejlighed til at afprøve det i praksis, så
jeg var en del nysgerrig efter nogle kommentarer - når der nu var en
mulighed - og tak for det
mvh/Peter Lykkegaard
| |
Stig Johansen (08-02-2001)
| Kommentar
Fra : Stig Johansen |
Dato : 08-02-01 16:37 |
|
"Peter Lykkegaard" <polonline@hotmail.com> wrote in message
news:WVyg6.286$uw2.4843@news.get2net.dk...
>
> "Stig Johansen" <e08@oes.dk> wrote in message
> news:xLyg6.28987$zw.563236@twister.sunsite.dk...
>
> > Hvis der bliver brugt mange opslag, hvor der skal benyttes tempdb,
> > eksempelvis en select ... order by, hvor indexet ikke afspejler
> sorteringen,
> > bliver temdb voldtaget.
>
> Og netop er det så crucial at fedte med sine T-SQL ting
> Og gå langt uden om al brug af cursor ting
>
> > Den ultimative løsning for performance er derfor:
> > 1 kanal til OS+virtuel memory
> > 1 kanal til db-filer
> > 1 kanal til log
> > 1 kanal til temdb
> > Den ekstermt ultimative løsning er derudover at lægge indexer og data i
> hver
> > sin(e) filegroups, og sprede disse på hver sin kanal.
>
> Ok , den er lidt udvidet i forhold til det jeg har set
> Men som skrevet andetsteds så er det vist ikke IO systemet der driller
> Henrik
Nej det så jeg lige efter jeg skrev det.
> >
> > Vi er enige om at den første drastiske performance forbedring fås ved at
> > lægge logfilerne på separat drev. Og som du siger her er det
> > skrivehastigheden, der eer afgørende.
> >
> Ok, som sagt så har jeg ikke haft lejlighed til at afprøve det i praksis,
så
> jeg var en del nysgerrig efter nogle kommentarer - når der nu var en
> mulighed - og tak for det
>
Det er også svært at afprøve præcist. Men jeg har det sidste halve år bla.
flyttet log-filer til et andet drev et utal af gange. Det er brugerne, der
oplever en forbedring, så det er skam sandt nok.
Jeg vil lige afrunde med, at der er placeringen af logfil på separat kanal,
der er afgørende og ikke så meget en 'superhurtig' disk.
mvh
Stig Johansen.
| |
Peter Lykkegaard (08-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 08-02-01 16:43 |
|
"Stig Johansen" <e08@oes.dk> wrote in message
news:P2zg6.29051$zw.564779@twister.sunsite.dk...
>
> Jeg vil lige afrunde med, at der er placeringen af logfil på separat
kanal,
> der er afgørende og ikke så meget en 'superhurtig' disk.
>
Ja det giver mening
Jeg muligvis lov til at afprøve det i praksis senere på året
Her har jeg anbefalet en separat RAID controller til logs (eller separat
kanal som mindste bud)
mvh/Peter Lykkegaard
| |
Stig Johansen (08-02-2001)
| Kommentar
Fra : Stig Johansen |
Dato : 08-02-01 16:43 |
|
"Peter Lykkegaard" <polonline@hotmail.com> wrote in message
news:WVyg6.286$uw2.4843@news.get2net.dk...
[klip]
> Og gå langt uden om al brug af cursor ting
BTW, du så i morges hvor vild Jakob var i d.e.i.w.s.asp over at bruge et
recordsæt baseret på select * .. efterfulgt af en ..addNew.
Det kan da godt være, at de ASP-folk elsker at voldtage de arme servere.
Det kan være performance skal hentes i behandlingen af ADO i deres
ASP-'programmer'.
mvh
Stig Johansen.
| |
Claus (08-02-2001)
| Kommentar
Fra : Claus |
Dato : 08-02-01 16:43 |
|
> BTW, du så i morges hvor vild Jakob var i d.e.i.w.s.asp over at bruge et
> recordsæt baseret på select * .. efterfulgt af en ..addNew.
>
> Det kan da godt være, at de ASP-folk elsker at voldtage de arme servere.
> Det kan være performance skal hentes i behandlingen af ADO i deres
> ASP-'programmer'.
*falder ned af stolen...*
| |
Stig Johansen (09-02-2001)
| Kommentar
Fra : Stig Johansen |
Dato : 09-02-01 07:03 |
|
Hej.
"Claus" <claus@cyberdude.com> wrote in message
news:g9zg6.301$uw2.5331@news.get2net.dk...
> > BTW, du så i morges hvor vild Jakob var i d.e.i.w.s.asp over at bruge et
> > recordsæt baseret på select * .. efterfulgt af en ..addNew.
> >
> > Det kan da godt være, at de ASP-folk elsker at voldtage de arme servere.
> > Det kan være performance skal hentes i behandlingen af ADO i deres
> > ASP-'programmer'.
>
> *falder ned af stolen...*
>
Du må endelig ikke opfatte det som en fornærmelse, nærmere som en
provokation til at få dig til at sige:
- Nej vi bruger helst ikke select *
- Ja bruger altid UPDATE/INSERT osv
- Ja vi bruger i videst muligt omfang fast forward only cursors
- Nej vi bruger aldrig scollable cursors etc., hvis vi kan undgå det.
- Ja vi benytter altid preparerede,parameterstyrede SQL's hvor det er
muligt.
- Vi passer på med brugen af clustered indexes.
osv...
--
Med venlig hilsen/Best Regards
Stig Johansen - stig@w3data.dk
W3 Data - mailto@w3data.dk
| |
Claus (09-02-2001)
| Kommentar
Fra : Claus |
Dato : 09-02-01 10:50 |
|
> Du må endelig ikke opfatte det som en fornærmelse, nærmere som en
> provokation til at få dig til at sige:
> - Nej vi bruger helst ikke select *
> - Ja bruger altid UPDATE/INSERT osv
> - Ja vi bruger i videst muligt omfang fast forward only cursors
> - Nej vi bruger aldrig scollable cursors etc., hvis vi kan undgå det.
> - Ja vi benytter altid preparerede,parameterstyrede SQL's hvor det er
> muligt.
> - Vi passer på med brugen af clustered indexes.
Jeg faldt mest ned af stolen pga. det jeg læste i den anden gruppe
Jeg er fuldstændigt enig i ovenstående...
/claus
| |
Peter Lykkegaard (08-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 08-02-01 16:49 |
|
"Stig Johansen" <e08@oes.dk> wrote in message
news:W7zg6.29063$zw.564889@twister.sunsite.dk...
> "Peter Lykkegaard" <polonline@hotmail.com> wrote in message
> news:WVyg6.286$uw2.4843@news.get2net.dk...
> [klip]
> > Og gå langt uden om al brug af cursor ting
>
> BTW, du så i morges hvor vild Jakob var i d.e.i.w.s.asp over at bruge et
> recordsæt baseret på select * .. efterfulgt af en ..addNew.
>
> Det kan da godt være, at de ASP-folk elsker at voldtage de arme servere.
> Det kan være performance skal hentes i behandlingen af ADO i deres
> ASP-'programmer'.
Hvis det er sådanne ting vi er oppe imod, så kæmper vi jo ret forgæves
Men sådan lige ummiddelbart så skrev Henrik at de havde været inde og kikke
på sp's og den slags ting men who knows
mvh/Peter Lykkegaard
| |
Stig Johansen (09-02-2001)
| Kommentar
Fra : Stig Johansen |
Dato : 09-02-01 06:57 |
|
Hej.
"Peter Lykkegaard" <polonline@hotmail.com> wrote in message
news:kbzg6.302$uw2.5273@news.get2net.dk...
>
> "Stig Johansen" <e08@oes.dk> wrote in message
> news:W7zg6.29063$zw.564889@twister.sunsite.dk...
> > "Peter Lykkegaard" <polonline@hotmail.com> wrote in message
> > news:WVyg6.286$uw2.4843@news.get2net.dk...
> > [klip]
> > > Og gå langt uden om al brug af cursor ting
> >
> > BTW, du så i morges hvor vild Jakob var i d.e.i.w.s.asp over at bruge et
> > recordsæt baseret på select * .. efterfulgt af en ..addNew.
> >
> > Det kan da godt være, at de ASP-folk elsker at voldtage de arme servere.
> > Det kan være performance skal hentes i behandlingen af ADO i deres
> > ASP-'programmer'.
>
> Hvis det er sådanne ting vi er oppe imod, så kæmper vi jo ret forgæves
> Men sådan lige ummiddelbart så skrev Henrik at de havde været inde og
kikke
> på sp's og den slags ting men who knows
>
Jeg vil lige understrege, at jeg IKKE er ude på at fornærme nogen. Vi har jo
ikke fået noget som helst at vide om applikationen. Jeg har været inde og
kigge på forsiden, men jeg ønsker ikke at logge ind for at se hvad der evt.
kunne forårsage evt. performance problemer.
Det kunne være rart at vide:
- Hvor mange brugere er der registreret?
- Hvordan fordeler læsninger/opdateringer sig?
- Hvor mange requests/sek klarer den?(SQL counter batchreq/sec)
Den nævnte kværn burde kunne klare noget i nærheden af 400-500. Jeg kender
heler ikke aktivitetsniveauet på siten, men det er fanme mange der skal til
hvis man skal lægge serveren ned.
Det er ikke nogen naturlov, at det giver noget med sp's. Hvis der er tale om
mere eller mindre enkeltstående queries, tvivler jeg på, at det giver meget
andet end besvær.
Personligt holder jeg mig helst fra sp's pga:
- Der er meget stor forskal på syntax på tværs af RDBMS'er.
- Man skal vedligeholde businesslogic 2 steder.
--
Med venlig hilsen/Best Regards
Stig Johansen - stig@w3data.dk
W3 Data - mailto@w3data.dk
| |
Jakob Andersen (09-02-2001)
| Kommentar
Fra : Jakob Andersen |
Dato : 09-02-01 00:59 |
|
"Stig Johansen" <e08@oes.dk> wrote
> BTW, du så i morges hvor vild Jakob var i d.e.i.w.s.asp over at bruge et
> recordsæt baseret på select * .. efterfulgt af en ..addNew.
Det var jo netop det jeg ville undgå: at skulle bruge en select for at pege
på en tabel.
Jeg ved godt at det er at foretrække at benytte en "insert into" i en sådan
sammenhæng men det var nu også mest fordi jeg undrede mig over at man skulle
eksekvere en SQLsætning for at skrive til en tabel vha. addnew.
--
Jakob Andersen
FAQ for webdesign gruppen på
< http://www.usenet.dk/oss/dk.edb.internet.webdesign>
"Det er rart at være vigtig, men det er vigtigere at være rar "
| |
Stig Johansen (09-02-2001)
| Kommentar
Fra : Stig Johansen |
Dato : 09-02-01 06:43 |
|
Hej.
"Jakob Andersen" <jakob@andersen.as> wrote in message
news:MoGg6.30173$zw.597574@twister.sunsite.dk...
> "Stig Johansen" <e08@oes.dk> wrote
> > BTW, du så i morges hvor vild Jakob var i d.e.i.w.s.asp over at bruge et
> > recordsæt baseret på select * .. efterfulgt af en ..addNew.
>
> Det var jo netop det jeg ville undgå: at skulle bruge en select for at
pege
> på en tabel.
>
> Jeg ved godt at det er at foretrække at benytte en "insert into" i en
sådan
> sammenhæng men det var nu også mest fordi jeg undrede mig over at man
skulle
> eksekvere en SQLsætning for at skrive til en tabel vha. addnew.
Det er fordi man skal have et aktivt recordset for at benytte addnew og
lignende.
Klientprogrammet kender ikke noget som helst til datastrukturen i databasen.
Den datastruktur, der opereres på er en afspejling af et select-statement.
Hvis du f.eks. skriver 'SELECT Kundenr,Navn FROM Kunder', indeholder dit
recordsæt kun disse 2 felter.
Den metode du vil bruger betyder endvidere, at serveren formentlig vil
udtage uforholdsmæssig mange låse-ressourcer.
--
Med venlig hilsen/Best Regards
Stig Johansen - stig@w3data.dk
W3 Data - mailto@w3data.dk
| |
Peter Lykkegaard (08-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 08-02-01 15:05 |
|
"Henrik Back" <henrik@back.dk> wrote in message
news:Trxg6.233$uw2.3964@news.get2net.dk...
>
> > Hvordan ser hitrate ud mht fange data i cache, hvis den erlav så smid
mere
> > RAM efter maskineriet
>
> Der er desværre ikke plads til mere i maskinen.. 4 256MB klodser
>
hmm, desværre - hiv dem ud og sæt 4 nye i
Btw - kun plads til 4 ram klodser og du siger dell - hvad er'et for en
maskine?
Normalt er der 8 huller i lidt større maskineri (Compaq)
mvh/Peter Lykkegaard
| |
Henrik Back (08-02-2001)
| Kommentar
Fra : Henrik Back |
Dato : 08-02-01 15:11 |
|
>
> Btw - kun plads til 4 ram klodser og du siger dell - hvad er'et for en
> maskine?
> Normalt er der 8 huller i lidt større maskineri (Compaq)
Den nuværende maskine er en bambus maskine med et asus board...
Henrik
| |
Thomas Jensen, pil.d~ (08-02-2001)
| Kommentar
Fra : Thomas Jensen, pil.d~ |
Dato : 08-02-01 15:09 |
|
On Thu, 8 Feb 2001 14:48:08 +0100, "Henrik Back" <henrik@back.dk>
wrote:
>> Få evt fat i en pusher der kan sin MSSQL til fingerspidserne
>
>Kender du nogle der kan det??
ja
Men for ikke at gøre usmagelig reklame, vil jeg anbefale
teknologisk.dk ... vi har tidligere i et projekt brugt dem til at
reviewe kode og setup. De har et par ganske hårde folk.
Smid en mail hvis du ønsker et konkret navn.
Men derudover skulle jeg da gerne æde min hat, hvis ikke det var
muligt at få til at køre på en brøkdel af hardwaren.
--
vh
Thomas Jensen
http://pil.dk/
| |
Peter Lykkegaard (08-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 08-02-01 15:19 |
|
"Thomas Jensen, pil.dk" <tj@dev.null> wrote in message
news:av958t4n8aljlf25a9plj9usmlt8k71spj@4ax.com...
> On Thu, 8 Feb 2001 14:48:08 +0100, "Henrik Back" <henrik@back.dk>
> wrote:
>
> >> Få evt fat i en pusher der kan sin MSSQL til fingerspidserne
> >
> >Kender du nogle der kan det??
>
> ja
>
> Men for ikke at gøre usmagelig reklame, vil jeg anbefale
> teknologisk.dk ... vi har tidligere i et projekt brugt dem til at
> reviewe kode og setup. De har et par ganske hårde folk.
>
En mulighed - men det er mange seriøse bud landet over
Men endnu flere der ikke kan...
mvh/Peter Lykkegaard
| |
Thomas Jensen, pil.d~ (08-02-2001)
| Kommentar
Fra : Thomas Jensen, pil.d~ |
Dato : 08-02-01 15:24 |
|
On Thu, 8 Feb 2001 15:18:41 +0100, "Peter Lykkegaard"
<polonline@hotmail.com> wrote:
>> ja
>>
>> Men for ikke at gøre usmagelig reklame, vil jeg anbefale
>> teknologisk.dk ... vi har tidligere i et projekt brugt dem til at
>> reviewe kode og setup. De har et par ganske hårde folk.
>>
>En mulighed - men det er mange seriøse bud landet over
>Men endnu flere der ikke kan...
<hint, hint>
Ligesom heller ikke alle laver reverse lookup, selvom man bør[tm]
</hint, hint>
--
vh
Thomas Jensen
http://pil.dk/
| |
Peter Lykkegaard (08-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 08-02-01 15:32 |
|
"Thomas Jensen, pil.dk" <tj@dev.null> wrote in message
news:oma58tslmbalj176cbidl7qgn3c17nggql@4ax.com...
>
> <hint, hint>
> Ligesom heller ikke alle laver reverse lookup, selvom man bør[tm]
> </hint, hint>
>
Jaja, bær over med en stakkels kodekarl
Jeg skal have fat i en pusher en af dagene - det der netværk går over min
forstand
btw - jeg/vi ville ikke tage en sådan opgave (MSSQL) - så det var egentlig
ikke ment på den måde
mvh/Peter Lykkegaard
| |
Peter Lykkegaard (08-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 08-02-01 15:12 |
|
"Henrik Back" <henrik@back.dk> wrote in message
news:Trxg6.233$uw2.3964@news.get2net.dk...
> Vi har 2 controllerer (Adaptec 2100)
>
hmm "RAID for Entry-Level Servers"
http://www.adaptec.com/worldwide/product/proddetail.html?prodkey=ASR-2100S&c
at=%2fTechnology%2fRAID%2fRAID+for+Entry-Level+Servers
(OBS broken link)
Måske skulle I kikke på nogle mere seriøse raid controllere?
Jeg har selv oplevet forskellen på fattigmands og professionelle raid
controllere
Forskellen er mer end mærkbar
mvh/Peter Lykkegaard
| |
Henrik Back (08-02-2001)
| Kommentar
Fra : Henrik Back |
Dato : 08-02-01 15:13 |
|
> Måske skulle I kikke på nogle mere seriøse raid controllere?
> Jeg har selv oplevet forskellen på fattigmands og professionelle raid
> controllere
> Forskellen er mer end mærkbar
Vi har målt på belastningen af diske / I/O.. Her ser ikke ud til overhovedet
at være flaskehalse...
Henrik
| |
Peter Lykkegaard (08-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 08-02-01 15:17 |
|
"Henrik Back" <henrik@back.dk> wrote in message
news:lPxg6.253$uw2.4591@news.get2net.dk...
> > Måske skulle I kikke på nogle mere seriøse raid controllere?
> > Jeg har selv oplevet forskellen på fattigmands og professionelle raid
> > controllere
> > Forskellen er mer end mærkbar
>
> Vi har målt på belastningen af diske / I/O.. Her ser ikke ud til
overhovedet
> at være flaskehalse...
>
Hvis CPU'erne er belastet og diskene står og hygger sig, så er der afgjort
noget galt med jeres brug af T-SQL sproget - efter min ydmyge mening forstås
mvh/Peter Lykkegaard
| |
Stig Johansen (08-02-2001)
| Kommentar
Fra : Stig Johansen |
Dato : 08-02-01 13:52 |
|
Hej.
"Henrik Back" <henrik@back.dk> wrote in message
news:jLtg6.80$uw2.1667@news.get2net.dk...
> Hej !
>
> Jeg driver et stort website som er konfigureret således:
>
> SQLServer: Dual P850 1 GB ram 2 raid 1 0 Arrays (tempDB på eget array)
>
> 6 stk. webserverer P 850 512 Mb
>
> Vi har nu tunet og optimeret med storedprocedures og asp tuning i 2 mdr.
> Dette har givet en del, men der kommer hele tiden flere brugerer på sitet.
> Vi er nu i den situation at vores sqlserver er belastet med 100% næsten
hele
> tiden..
>
> Vi går nu i overvejelser om at købe en 4 vejs xeon 700 1 mb cache, men en
> sådan maskine koster i nabolaget af 250.000 Mit spørgsmål er om vi ved at
> købe en maskine magen til den nuværende sqlserver vil kunne køre
> clustering??
>
> Lad os sige jeg har 250.000 og skal have løst mit problem... Hvordan skal
de
> bruges...
Hvis du køber en maskine til og laver cluster, kan du dårligt nok betale
licenserne med de penge.
Det bedste du umiddelbart kan gøre med SQLserver, er at fylde den op med
RAM.
Så hvis du kører STD-version, så smid en GB i. Hvis du kører ENT edition,
smid en ekstra GB eller 2 i.
Tag også et kig på cursor bruget i ASP(ADO).
Prøv i videst muligt omfang at benytte 'Fast Forward-only Cursors' (se BOL).
Brug i videst muligt omfang UPDATE/INSERT osv. statements i stedet for
cursors.
mvh
Stig Johansen.
| |
Stig Johansen (08-02-2001)
| Kommentar
Fra : Stig Johansen |
Dato : 08-02-01 14:12 |
|
"Stig Johansen" <e08@oes.dk> wrote in message
news:1Ewg6.28676$zw.552922@twister.sunsite.dk...
> Hej.
>
> "Henrik Back" <henrik@back.dk> wrote in message
> news:jLtg6.80$uw2.1667@news.get2net.dk...
> > Hej !
> >
> > Jeg driver et stort website som er konfigureret således:
> >
> > SQLServer: Dual P850 1 GB ram 2 raid 1 0 Arrays (tempDB på eget array)
> >
> > 6 stk. webserverer P 850 512 Mb
> >
> > Vi har nu tunet og optimeret med storedprocedures og asp tuning i 2 mdr.
> > Dette har givet en del, men der kommer hele tiden flere brugerer på
sitet.
> > Vi er nu i den situation at vores sqlserver er belastet med 100% næsten
> hele
> > tiden..
> >
> > Vi går nu i overvejelser om at købe en 4 vejs xeon 700 1 mb cache, men
en
> > sådan maskine koster i nabolaget af 250.000 Mit spørgsmål er om vi ved
at
> > købe en maskine magen til den nuværende sqlserver vil kunne køre
> > clustering??
> >
> > Lad os sige jeg har 250.000 og skal have løst mit problem... Hvordan
skal
> de
> > bruges...
>
> Hvis du køber en maskine til og laver cluster, kan du dårligt nok betale
> licenserne med de penge.
> Det bedste du umiddelbart kan gøre med SQLserver, er at fylde den op med
> RAM.
> Så hvis du kører STD-version, så smid en GB i. Hvis du kører ENT edition,
> smid en ekstra GB eller 2 i.
>
> Tag også et kig på cursor bruget i ASP(ADO).
>
> Prøv i videst muligt omfang at benytte 'Fast Forward-only Cursors' (se
BOL).
>
> Brug i videst muligt omfang UPDATE/INSERT osv. statements i stedet for
> cursors.
>
> mvh
> Stig Johansen.
>
>
Og som Peter skriver, smid log-filerne over på et eget, hurtigt drev.
| |
Peter Lykkegaard (08-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 08-02-01 14:30 |
|
"Stig Johansen" <e08@oes.dk> wrote in message news:zWwg6.28702>
>
> Og som Peter skriver, smid log-filerne over på et eget, hurtigt drev.
>
Husk det skal være *skrive* optimeret
Logfilerne bliver lagt ind sekventielt
Indtil nu har jeg "kun" læst om det, kunne være spændende at hører hvor
meget det gi'r live
Skrivehovedet er jo fri for at bevæge sig ret meget hvis logfilerne ligger
på eget "drev" læs det som RAID
btw kik lige på RAID systemet
Er det noget fattigmandsraid eller noget der sparker røv med masser af
cache??
Hvad med diskene er det 10.000 rpms??
mvh/Peter Lykkegaard
| |
Claus (08-02-2001)
| Kommentar
Fra : Claus |
Dato : 08-02-01 15:56 |
|
> Og som Peter skriver, smid log-filerne over på et eget, hurtigt drev.
Det er *IKKE* IO-systemet der er flaskehalsen....
| |
Stig Johansen (08-02-2001)
| Kommentar
Fra : Stig Johansen |
Dato : 08-02-01 16:24 |
|
Hej.
"Claus" <claus@cyberdude.com> wrote in message
news:3tyg6.272$uw2.4889@news.get2net.dk...
>
> > Og som Peter skriver, smid log-filerne over på et eget, hurtigt drev.
>
> Det er *IKKE* IO-systemet der er flaskehalsen....
>
Så må du ud med llidt flere oplysninger. Hvis du oprindeligt mente 100%
CPU-belastning på en SQL server, der ikke er belastet på I/O-siden, så der
der squ' efter min mening noget meget galt.
Vores erfaring (pt. 109 servere) siger, at det først er I/O, der bliver
flaskehalsen.
Hvis der ikke kører andet på serveren end SQL, så er der nok tale om et
uforholdsmæssigt stort ressourceforbrug på resultatsæt,cursors eller lign.
Kan du uddybe, om der er tale om 100% på CPU-siden, eller lange svartider?
mvh
Stig Johanssen.
| |
Claus (08-02-2001)
| Kommentar
Fra : Claus |
Dato : 08-02-01 16:41 |
|
> Så må du ud med llidt flere oplysninger. Hvis du oprindeligt mente 100%
> CPU-belastning på en SQL server, der ikke er belastet på I/O-siden, så der
> der squ' efter min mening noget meget galt.
> Vores erfaring (pt. 109 servere) siger, at det først er I/O, der bliver
> flaskehalsen.
>
> Hvis der ikke kører andet på serveren end SQL, så er der nok tale om et
> uforholdsmæssigt stort ressourceforbrug på resultatsæt,cursors eller lign.
>
> Kan du uddybe, om der er tale om 100% på CPU-siden, eller lange svartider?
Lige nu står cpu-belastningen og kører op og ned. Og samtidigt mener jeg
ikke der er noget at komme efter mht. IO-systemet.
Avg. Disk sec/Read: 11 ms
Avg. Disk sec/Write: 3 ms
Disk Reads/sec: 8
Disk Transfers/sec: 29
Disk Writes/sec: 21
CPU'erne er i snit på 62% men peaker ret kraftigt hele tiden.
| |
Stig Johansen (08-02-2001)
| Kommentar
Fra : Stig Johansen |
Dato : 08-02-01 16:52 |
|
"Claus" <claus@cyberdude.com> wrote in message
news:L6zg6.299$uw2.5192@news.get2net.dk...
> > Så må du ud med llidt flere oplysninger. Hvis du oprindeligt mente 100%
> > CPU-belastning på en SQL server, der ikke er belastet på I/O-siden, så
der
> > der squ' efter min mening noget meget galt.
> > Vores erfaring (pt. 109 servere) siger, at det først er I/O, der bliver
> > flaskehalsen.
> >
> > Hvis der ikke kører andet på serveren end SQL, så er der nok tale om et
> > uforholdsmæssigt stort ressourceforbrug på resultatsæt,cursors eller
lign.
> >
> > Kan du uddybe, om der er tale om 100% på CPU-siden, eller lange
svartider?
>
> Lige nu står cpu-belastningen og kører op og ned. Og samtidigt mener jeg
> ikke der er noget at komme efter mht. IO-systemet.
>
> Avg. Disk sec/Read: 11 ms
> Avg. Disk sec/Write: 3 ms
> Disk Reads/sec: 8
> Disk Transfers/sec: 29
> Disk Writes/sec: 21
>
> CPU'erne er i snit på 62% men peaker ret kraftigt hele tiden.
Jeg skal hjem fra denne her pind, og er først tilbage på torsdag.
Så jeg kan kun give dig en kort start.
Tjek
Disk time, den må godt peake på 100% en gang imellem ( lazy write osv), men
må ikke ligge over 90% i snit.
Disk avg queue length, den må helst aldrig komme over 1-2(gange antal
spindler).
Hvis der er meget swapping på din sys disk, er du short på ram.
Jeg har noget materiale fra en større stress-test, jeg lavede i efteråret,
så hvis du ikke er kommet videre på torsdag, så giv lyd.
mvh
Stig Johansen.
| |
Peter Lykkegaard (08-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 08-02-01 17:01 |
|
"Stig Johansen" <e08@oes.dk> wrote in message
news:mgzg6.29089$zw.565567@twister.sunsite.dk...
> Hvis der er meget swapping på din sys disk, er du short på ram.
>
Det ville også kunne give en del CPU load - jeg har set workstations med for
lidt ram gå totalt i knæ ved store excel regneark (større end fysisk ram)
mvh/Peter Lykkegaard
| |
Stig Johansen (08-02-2001)
| Kommentar
Fra : Stig Johansen |
Dato : 08-02-01 21:14 |
|
"Claus" <claus@cyberdude.com> wrote in message
news:L6zg6.299$uw2.5192@news.get2net.dk...
> > Så må du ud med llidt flere oplysninger. Hvis du oprindeligt mente 100%
> > CPU-belastning på en SQL server, der ikke er belastet på I/O-siden, så
der
> > der squ' efter min mening noget meget galt.
> > Vores erfaring (pt. 109 servere) siger, at det først er I/O, der bliver
> > flaskehalsen.
> >
> > Hvis der ikke kører andet på serveren end SQL, så er der nok tale om et
> > uforholdsmæssigt stort ressourceforbrug på resultatsæt,cursors eller
lign.
> >
> > Kan du uddybe, om der er tale om 100% på CPU-siden, eller lange
svartider?
>
> Lige nu står cpu-belastningen og kører op og ned. Og samtidigt mener jeg
> ikke der er noget at komme efter mht. IO-systemet.
>
> Avg. Disk sec/Read: 11 ms
> Avg. Disk sec/Write: 3 ms
> Disk Reads/sec: 8
> Disk Transfers/sec: 29
> Disk Writes/sec: 21
>
> CPU'erne er i snit på 62% men peaker ret kraftigt hele tiden.
Hvis jeg nu læser tilbage til det oprindelige indlæg står der:
SQLserver samt 6 web servere.
Det jeg mente med yderligere oplysninger var: Kører i også IIS/ASP på den
samme maskine?.
Eller
Skal det forstås som i har 6*IIS i et loadbalancing setup, der kommunikerer
med SQLServer?
Du skriver også et andet sted, at der er 4GB i maskinen, men at der 'kun' er
afsat 1GB til SQLserver.
Hvis i kører IIS/ASP på samme maskine, vil jeg anbefale at skille
IIS/ASP-delen ud på en separat maskine.
--
Med venlig hilsen/Best Regards
Stig Johansen - stig@w3data.dk
W3 Data - mailto@w3data.dk
| |
Peter Lykkegaard (09-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 09-02-01 08:11 |
|
"Stig Johansen" <stig@w3data.dk> wrote in message
news:w6Dg6.29521$zw.584353@twister.sunsite.dk...
>
> Skal det forstås som i har 6*IIS i et loadbalancing setup, der
kommunikerer
> med SQLServer?
I følge det oprindelige indlæg så skulle der være 7 maskiner
>
> Du skriver også et andet sted, at der er 4GB i maskinen, men at der 'kun'
er
> afsat 1GB til SQLserver.
>
Ikke ifølge det oprindelige indlæg
(De har 4 x 256Mb klodser i MSSQL maskinen)
mvh/Peter Lykkegaard
| |
Stig Johansen (09-02-2001)
| Kommentar
Fra : Stig Johansen |
Dato : 09-02-01 09:38 |
|
Hej.
"Peter Lykkegaard" <polonline@hotmail.com> wrote in message
news:iIMg6.14$WD3.1350@news.get2net.dk...
>
> "Stig Johansen" <stig@w3data.dk> wrote in message
> news:w6Dg6.29521$zw.584353@twister.sunsite.dk...
> >
> > Skal det forstås som i har 6*IIS i et loadbalancing setup, der
> kommunikerer
> > med SQLServer?
>
> I følge det oprindelige indlæg så skulle der være 7 maskiner
> >
> > Du skriver også et andet sted, at der er 4GB i maskinen, men at der
'kun'
> er
> > afsat 1GB til SQLserver.
> >
> Ikke ifølge det oprindelige indlæg
> (De har 4 x 256Mb klodser i MSSQL maskinen)
Sorry, jeg må være halvblind. (Gamle mand??!)
----> Der er desværre ikke plads til mere i maskinen.. 4 256MB klodser
fik jeg i farten til 4GB, jeg kan da godt se, der står 4*256 (nu).
--
Med venlig hilsen/Best Regards
Stig Johansen - stig@w3data.dk
W3 Data - mailto@w3data.dk
| |
Claus (09-02-2001)
| Kommentar
Fra : Claus |
Dato : 09-02-01 10:53 |
|
> Sorry, jeg må være halvblind. (Gamle mand??!)
> ----> Der er desværre ikke plads til mere i maskinen.. 4 256MB klodser
> fik jeg i farten til 4GB, jeg kan da godt se, der står 4*256 (nu).
Og der kører kun SQL server på maskinen...
| |
Peter Lykkegaard (08-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 08-02-01 16:46 |
|
"Stig Johansen" <e08@oes.dk> wrote in message
news:vSyg6.29007$zw.563779@twister.sunsite.dk...
>Vores erfaring (pt. 109 servere) siger, at det først er I/O, der bliver
>flaskehalsen.
Jeg læste andetsteds at der er tale noget bambus maskineri, sandsynligvis
med ringe processor cache - så det giver dig lissom sig selv
Jeg kan anbefale Henrik at kikke lidt på denne tekst
http://www.sql-server-performance.com/fixing_bottlenecks.asp
mvh/Peter Lykkegaard
| |
Peter Lykkegaard (08-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 08-02-01 17:04 |
|
"Peter Lykkegaard" <polonline@hotmail.com> wrote in message
news:W8zg6.300$uw2.5235@news.get2net.dk...
>
> "Stig Johansen" <e08@oes.dk> wrote in message
> news:vSyg6.29007$zw.563779@twister.sunsite.dk...
>
> >Vores erfaring (pt. 109 servere) siger, at det først er I/O, der bliver
> >flaskehalsen.
>
> Jeg læste andetsteds at der er tale noget bambus maskineri, sandsynligvis
> med ringe processor cache - så det giver dig lissom sig selv
>
Hmm jeg læste lige at der er tale om to gange P850
mvh/Peter Lykkegaard
| |
Peter Lykkegaard (08-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 08-02-01 17:06 |
|
"Henrik Back" <henrik@back.dk> wrote in message
news:jLtg6.80$uw2.1667@news.get2net.dk...
> Vi har nu tunet og optimeret med storedprocedures og asp tuning i 2 mdr.
> Dette har givet en del, men der kommer hele tiden flere brugerer på sitet.
> Vi er nu i den situation at vores sqlserver er belastet med 100% næsten
hele
> tiden..
>
Hvordan er databasen implementeret?
Bare sådan i hovedtræk - er den rimelig mht tabeller osv?
mvh/Peter Lykkegaard
| |
Lauritz Jensen (08-02-2001)
| Kommentar
Fra : Lauritz Jensen |
Dato : 08-02-01 17:46 |
|
Henrik Back wrote:
>
[...]
> Vi har nu tunet og optimeret med storedprocedures og asp tuning
> i 2 mdr.
> Dette har givet en del, men der kommer hele tiden flere brugerer
> på sitet.
> Vi er nu i den situation at vores sqlserver er belastet med
> 100% næsten hele tiden..
Nu har jeg naturlignok ikke set en profil af sql-kladene, men det virker
umidelbart, som et site, hvor stort set hele møget kan caches og
opdateringer kan sættes i kø (og batch opdateres).
Databasen kan vel også partitioneres ud i flere databaser (så man ikke
behøver at køre cluster, men kan dele data op på n servere), da data til
hver profil er rimeligt autonom (aka. kun brugeren selv må læse sine
breve, så der er ikke brug for at kunne søge på tværs af alle breve,
osv...).
Måske en ide at tage et skridt tilbage og kigge på designet. Det kan
naturligvis også være at I har styr på disse ting og i så fald håber jeg
ikke har har tisset for meget på jeres intelligens 
--
Lauritz
| |
Peter Lykkegaard (09-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 09-02-01 08:16 |
|
"Henrik Back" <henrik@back.dk> wrote in message
news:jLtg6.80$uw2.1667@news.get2net.dk...
>
> Vi har nu tunet og optimeret med storedprocedures og asp tuning i 2 mdr.
> Dette har givet en del, men der kommer hele tiden flere brugerer på sitet.
> Vi er nu i den situation at vores sqlserver er belastet med 100% næsten
hele
> tiden..
>
For at give det hele en lidt anden approach
Er der nogen del af sitet der giver problemer - dvs lange svartider =
belastning af MSSQL?
Eller er det bare et generelt "langsomt"?
Lige ummidelbart får man hurtig respons når man slår op på dating.dk's
forside
Hvor mange hits er der om dagen
Hvordan er svartider/belastning/IO performance hvor hitrate topper?
Hvad er belastningen på webserverne?
Kan netkortet være flaskehalsen?
mvh/Peter Lykkegaard
mvh/Peter Lykkegaard
| |
Stig Johansen (09-02-2001)
| Kommentar
Fra : Stig Johansen |
Dato : 09-02-01 09:44 |
|
Hej.
"Peter Lykkegaard" <polonline@hotmail.com> wrote in message
news:AMMg6.15$WD3.1589@news.get2net.dk...
>
> "Henrik Back" <henrik@back.dk> wrote in message
> news:jLtg6.80$uw2.1667@news.get2net.dk...
> >
> > Vi har nu tunet og optimeret med storedprocedures og asp tuning i 2 mdr.
> > Dette har givet en del, men der kommer hele tiden flere brugerer på
sitet.
> > Vi er nu i den situation at vores sqlserver er belastet med 100% næsten
> hele
> > tiden..
> >
> For at give det hele en lidt anden approach
Enig.
>
> Er der nogen del af sitet der giver problemer - dvs lange svartider =
> belastning af MSSQL?
> Eller er det bare et generelt "langsomt"?
> Lige ummidelbart får man hurtig respons når man slår op på dating.dk's
> forside
Enig.
>
> Hvor mange hits er der om dagen
> Hvordan er svartider/belastning/IO performance hvor hitrate topper?
>
> Hvad er belastningen på webserverne?
Ifølge netcraft, ser det ikke ud som om der køres loadbalancing på
webservere, så mon ikke der er tale om uafhængige webservere?
>
> Kan netkortet være flaskehalsen?
Det er vel (næsten) umulig at der skulle være tale om network congestions,
idet det vil kræve et kæmpe 'rør' ud i I*nettet.
--
Med venlig hilsen/Best Regards
Stig Johansen - stig@w3data.dk
W3 Data - mailto@w3data.dk
| |
Peter Lykkegaard (09-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 09-02-01 09:58 |
|
"Stig Johansen" <stig@w3data.dk> wrote in message
news:F5Og6.31684$zw.604931@twister.sunsite.dk...
> "Peter Lykkegaard" <polonline@hotmail.com> wrote in message
> news:AMMg6.15$WD3.1589@news.get2net.dk...
> >
> > Kan netkortet være flaskehalsen?
>
> Det er vel (næsten) umulig at der skulle være tale om network
congestions,
> idet det vil kræve et kæmpe 'rør' ud i I*nettet.
>
Mellem MSSQL og de 6 webservere?
Det er nok lidt tænkt - jeg er nok ude på lidt dybt vand lige nu - kan jeg
mærke
Bare gi' et rap over fingrene - jeg kan tåle det
mvh/Peter Lykkegaard
| |
Stig Johansen (09-02-2001)
| Kommentar
Fra : Stig Johansen |
Dato : 09-02-01 17:40 |
|
Hej.
"Peter Lykkegaard" <polonline@hotmail.com> wrote in message
news:dgOg6.35$WD3.3925@news.get2net.dk...
>
> "Stig Johansen" <stig@w3data.dk> wrote in message
> news:F5Og6.31684$zw.604931@twister.sunsite.dk...
>
> > "Peter Lykkegaard" <polonline@hotmail.com> wrote in message
> > news:AMMg6.15$WD3.1589@news.get2net.dk...
> > >
> > > Kan netkortet være flaskehalsen?
> >
> > Det er vel (næsten) umulig at der skulle være tale om network
> congestions,
> > idet det vil kræve et kæmpe 'rør' ud i I*nettet.
> >
> Mellem MSSQL og de 6 webservere?
>
> Det er nok lidt tænkt - jeg er nok ude på lidt dybt vand lige nu - kan jeg
> mærke
> Bare gi' et rap over fingrene - jeg kan tåle det
>
Kunne jeg ikke drømme om.
--
Med venlig hilsen/Best Regards
Stig Johansen - stig@w3data.dk
W3 Data - mailto@w3data.dk
| |
Peter Lykkegaard (11-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 11-02-01 11:23 |
|
"Stig Johansen" <stig@w3data.dk> wrote in message
news:f3Vg6.33036$zw.621798@twister.sunsite.dk...
> "Peter Lykkegaard" <polonline@hotmail.com> wrote in message
> news:dgOg6.35$WD3.3925@news.get2net.dk...
> >
>
> > Det er nok lidt tænkt - jeg er nok ude på lidt dybt vand lige nu - kan
jeg
> > mærke
> > Bare gi' et rap over fingrene - jeg kan tåle det
>
> Kunne jeg ikke drømme om.
>
Det var nu ikke på den måde
Hvis jeg er helt ude i skoven - vil jeg godt vide det - man skal lære hele
tiden
mvh/Peter Lykkegaard
| |
Stig Johansen (11-02-2001)
| Kommentar
Fra : Stig Johansen |
Dato : 11-02-01 18:00 |
|
Hej.
"Peter Lykkegaard" <polonline@hotmail.com> wrote in message
news:0Ith6.47$gR5.1623@news.get2net.dk...
>
> "Stig Johansen" <stig@w3data.dk> wrote in message
> news:f3Vg6.33036$zw.621798@twister.sunsite.dk...
>
> > "Peter Lykkegaard" <polonline@hotmail.com> wrote in message
> > news:dgOg6.35$WD3.3925@news.get2net.dk...
> > >
> >
> > > Det er nok lidt tænkt - jeg er nok ude på lidt dybt vand lige nu - kan
> jeg
> > > mærke
> > > Bare gi' et rap over fingrene - jeg kan tåle det
> >
> > Kunne jeg ikke drømme om.
> >
> Det var nu ikke på den måde
> Hvis jeg er helt ude i skoven - vil jeg godt vide det - man skal lære hele
> tiden
>
Nej, du er ikke helt ude i skoven.
Men, hvis du kigger på den tidligere
nævnte:Netcraft( http://uptime.netcraft.com/up/graph?site=www.dating.dk), vil
du se, at hvis de kørte load-balancing på 6 servere, ville de optræde som om
de skiftede IP-adresser ofte.
Det er ikke tilfældet, hvorfor vi må formode, at der er tale om en enkelt
W2K/IIS5.
--
Med venlig hilsen/Best Regards
Stig Johansen - stig@w3data.dk
W3 Data - mailto@w3data.dk
| |
Hendrik Hansen (11-02-2001)
| Kommentar
Fra : Hendrik Hansen |
Dato : 11-02-01 20:10 |
|
"Stig Johansen" <stig@w3data.dk> wrote in message
news:ayzh6.45870$zw.751097@twister.sunsite.dk...
> Nej, du er ikke helt ude i skoven.
> Men, hvis du kigger på den tidligere
> nævnte:Netcraft( http://uptime.netcraft.com/up/graph?site=www.dating.dk),
vil
> du se, at hvis de kørte load-balancing på 6 servere, ville de optræde som
om
> de skiftede IP-adresser ofte.
Hmmmm... Hvorfor egentlig det? Er en webfarm ikke oftest sat op med en
speciel router, f.eks. Cisco Local Director, på ydersiden, der så sender
requests videre til webservere på indersiden efter nærmere definerede
regler? I så fald vil det da udefra se ud som om der kun er én og samme
maskine med et enkelt IP-nummer, men i virkeligheden kan der jo stå
adskillige maskiner bag arbejdet.
Mvh. Hendrik
| |
Peter Lykkegaard (12-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 12-02-01 08:09 |
|
"Stig Johansen" <stig@w3data.dk> wrote in message
news:ayzh6.45870$zw.751097@twister.sunsite.dk...
>
> Nej, du er ikke helt ude i skoven.
> Men, hvis du kigger på den tidligere
> nævnte:Netcraft( http://uptime.netcraft.com/up/graph?site=www.dating.dk),
vil
> du se, at hvis de kørte load-balancing på 6 servere, ville de optræde som
om
> de skiftede IP-adresser ofte.
> Det er ikke tilfældet, hvorfor vi må formode, at der er tale om en enkelt
> W2K/IIS5.
>
Øhh, bagved en firewall, så har man typisk én ip-adresse - firewallens
Men det var nu ikke det jeg oprindeligt tågede rundt omkring
Kunne man forestille at de 6 webservere (nævnt i det indlæg der startede
tråden) kunne skabe netværksrelaterede problemer for MSSQL serveren?
Dvs pakketab med belastning af CPU til følge
En løsning kunne være to netkort i MSSQL serveren
Eller er jeg på gale veje?
mvh/Peter Lykkegaard
| |
Claus (12-02-2001)
| Kommentar
Fra : Claus |
Dato : 12-02-01 10:04 |
|
> Nej, du er ikke helt ude i skoven.
> Men, hvis du kigger på den tidligere
> nævnte:Netcraft( http://uptime.netcraft.com/up/graph?site=www.dating.dk),
vil
> du se, at hvis de kørte load-balancing på 6 servere, ville de optræde som
om
> de skiftede IP-adresser ofte.
> Det er ikke tilfældet, hvorfor vi må formode, at der er tale om en enkelt
> W2K/IIS5.
Der bliver kørt load balancing... tro det eller la' vær'...
/claus
| |
Peter Lykkegaard (12-02-2001)
| Kommentar
Fra : Peter Lykkegaard |
Dato : 12-02-01 10:36 |
|
"Peter Lykkegaard" <polonline@hotmail.com> wrote in message
news:AMMg6.15$WD3.1589@news.get2net.dk...
>
> For at give det hele en lidt anden approach
>
> Er der nogen del af sitet der giver problemer - dvs lange svartider =
> belastning af MSSQL?
> Eller er det bare et generelt "langsomt"?
>
> Hvor mange hits er der om dagen
> Hvordan er svartider/belastning/IO performance hvor hitrate topper?
>
Hej Claus og Henrik
Har I overvejet disse spørgsmål?
Jeg er lidt interesseret i diskussionen da jeg til sommer skal være med til
at implementere en større MSSQL ting til webbrug (online learning)
mvh/Peter Lykkegaard
| |
Stig Johansen (10-02-2001)
| Kommentar
Fra : Stig Johansen |
Dato : 10-02-01 07:33 |
|
Hej.
Lige at besvare det oprindelige spørgsmål vedr. clustering.
2 SQLservere sat i cluster betyder IKKE 2 gange hastighed. Det typiske setup
er hot stand by, hvilket betyder at den ene bare venter på den anden går
ned. Herefter overtager den anden.
Der er tale om fejltolerance på hardwaren.
Der er også en anden mulighed, nemlig at sætte dem op som aktiv-aktiv
(dobbelt licens her). Her skal du betraget den som to adskilte servere, dog
med den mulighed, at den anden tager over i tilfælde af fejl.
Forudsætningen for at køre i cluster er en enterprise licens, der til i*net
brug koster over 100K pr CPU.
Det vil sige i dit tilfælde et godt stykke over 400K.
--
Med venlig hilsen/Best Regards
Stig Johansen - stig@w3data.dk
W3 Data - mailto@w3data.dk
"Henrik Back" <henrik@back.dk> wrote in message
news:jLtg6.80$uw2.1667@news.get2net.dk...
> Hej !
>
> Jeg driver et stort website som er konfigureret således:
>
> SQLServer: Dual P850 1 GB ram 2 raid 1 0 Arrays (tempDB på eget array)
>
> 6 stk. webserverer P 850 512 Mb
>
> Vi har nu tunet og optimeret med storedprocedures og asp tuning i 2 mdr.
> Dette har givet en del, men der kommer hele tiden flere brugerer på sitet.
> Vi er nu i den situation at vores sqlserver er belastet med 100% næsten
hele
> tiden..
>
> Vi går nu i overvejelser om at købe en 4 vejs xeon 700 1 mb cache, men en
> sådan maskine koster i nabolaget af 250.000 Mit spørgsmål er om vi ved at
> købe en maskine magen til den nuværende sqlserver vil kunne køre
> clustering??
>
> Lad os sige jeg har 250.000 og skal have løst mit problem... Hvordan skal
de
> bruges...
>
> Mvh
>
> Henrik
>
>
>
| |
Jesper Frank Nemholt (10-02-2001)
| Kommentar
Fra : Jesper Frank Nemholt |
Dato : 10-02-01 14:36 |
|
"Stig Johansen" <stig@w3data.dk> wrote in message
news:Qg5h6.37697$zw.641712@twister.sunsite.dk...
> Hej.
>
> Lige at besvare det oprindelige spørgsmål vedr. clustering.
> 2 SQLservere sat i cluster betyder IKKE 2 gange hastighed. Det typiske
setup
> er hot stand by, hvilket betyder at den ene bare venter på den anden går
> ned. Herefter overtager den anden.
> Der er tale om fejltolerance på hardwaren.
>
> Der er også en anden mulighed, nemlig at sætte dem op som aktiv-aktiv
> (dobbelt licens her). Her skal du betraget den som to adskilte servere,
dog
> med den mulighed, at den anden tager over i tilfælde af fejl.
[clip]
Vil det sige at MS-SQL kun understøtter failover clustering og ikke
loadbalancing uden at man splitter sin database op med de ulemper dette
indebærer ?
Jeg kender intet til MS-SQL men er vant til at rode med operativsystemdelen
på clustre der kører Oracle Parallel Server. Her arbejder man med N
instanser på een database og de involverede maskiner (N = antal) snakker
sammen via en form for IPC der kører over en højhastighedsforbindelse
(MemoryChannel) mellem medlemmerne i clusteret.
l8r/Jspr
| |
Stig Johansen (10-02-2001)
| Kommentar
Fra : Stig Johansen |
Dato : 10-02-01 15:14 |
|
Hej.
"Jesper Frank Nemholt" <jfn@dassic.com> wrote in message
news:Osbh6.39696$zw.663115@twister.sunsite.dk...
> "Stig Johansen" <stig@w3data.dk> wrote in message
> news:Qg5h6.37697$zw.641712@twister.sunsite.dk...
> > Hej.
> >
> > Lige at besvare det oprindelige spørgsmål vedr. clustering.
> > 2 SQLservere sat i cluster betyder IKKE 2 gange hastighed. Det typiske
> setup
> > er hot stand by, hvilket betyder at den ene bare venter på den anden går
> > ned. Herefter overtager den anden.
> > Der er tale om fejltolerance på hardwaren.
> >
> > Der er også en anden mulighed, nemlig at sætte dem op som aktiv-aktiv
> > (dobbelt licens her). Her skal du betraget den som to adskilte servere,
> dog
> > med den mulighed, at den anden tager over i tilfælde af fejl.
> [clip]
>
> Vil det sige at MS-SQL kun understøtter failover clustering og ikke
> loadbalancing uden at man splitter sin database op med de ulemper dette
> indebærer ?
>
> Jeg kender intet til MS-SQL men er vant til at rode med
operativsystemdelen
> på clustre der kører Oracle Parallel Server. Her arbejder man med N
> instanser på een database og de involverede maskiner (N = antal) snakker
> sammen via en form for IPC der kører over en højhastighedsforbindelse
> (MemoryChannel) mellem medlemmerne i clusteret.
Ja, det er korrekt, der er kun tale om 2 maskiner. Ved aktiv-aktiv
opsætning, er den eneste forskel, at der er tale om en vis form for
fejltolerance.
Man kan altså ikke have 2+ instanser på den samme DB.
Jeg mener dog, det ligger på NT-niveauet. Den form for cluster, du omtaler
understøttes ikke på NT. For tiden implementerer vi 'kun' NT4, så hvorvidt
der er noget på vej i NT5(Win2000) ved jeg ikke.
Det er også muligt, at M$ får 'kuglerne' op i ganghøjde, og får færdiggjort
deres Win64. Eller snakker vi nok kun *nix.
--
Med venlig hilsen/Best Regards
Stig Johansen - stig@w3data.dk
W3 Data - mailto@w3data.dk
| |
Hendrik Hansen (12-02-2001)
| Kommentar
Fra : Hendrik Hansen |
Dato : 12-02-01 18:43 |
|
"Henrik Back" <henrik@back.dk> wrote in message
news:jLtg6.80$uw2.1667@news.get2net.dk...
> Vi har nu tunet og optimeret med storedprocedures og asp tuning i 2 mdr.
> Dette har givet en del, men der kommer hele tiden flere brugerer på sitet.
> Vi er nu i den situation at vores sqlserver er belastet med 100% næsten
hele
> tiden..
Jeg har været inde og kigge lidt på de forskellige funktioner (og "markedet"
bød på p.t. ) og én ting undrer mig når du snakker om asp tuning.
Søgefunktionen ser ud til at holde en stateinformation på sessionniveau,
idet det eneste argument der kræves for at bladre mellem de enkelte pages i
et søgeresultat er page-nummeret. Som jeg ser det kan det betyde forskellige
ting:
1. At forespørgslen gemmes et centralt sted (sandsynligvis i databasen) via
en hjemmelavet sessionfunktionalitet, der understøtter webfarms. Det er ikke
så slemt som nr. 2, men det koster en del ekstra data i databasen og et
ekstra opslag for hver sidevisning. Hvorfor ikke bare lade klienten sende
alle søgeparametre med hver gang - det bruges stort set alle andre steder og
fungerer glimrende.
2. Der køres med "sticky IP's" på webfarmen således at standard
sessionfunktionalitet kan bruges. Recordset'et med søgeresultatet gemmes i
en sessionvariabel. Denne er rigtig slem og kan sagtens være skyld i alle
dine problemer, hvis det er sådan det fungerer.
3. Varianter af ovenstående.
Det kunne være interessant at få at vide hvordan det rent faktisk fungerer.
Dernæst tror jeg at du skal henvende dig til professionelle konsulenter hvis
du vil have problemet løst hurtigt og smertefrit - evt. til Microsoft selv
(MCS - Microsoft Consulting Services) der enten selv kan sætte en konsulent
på opgaven eller kan henvise til en partner med den fornødne kompetence.
Opgaven er på så højt et niveau, at kun ganske få herhjemme har erfaringen
med sådanne set-ups - og jeg tvivler på at de er villige til at løse dine
problemer gratis i en newsgroup Sandsynligvis skal de bruge ihvertfald en
dags tid ude hos dig for at finde årsagen til problemerne, hvilket ligeledes
gør det mindre sandsynligt at problemet kan løses på fornuftig vis her.
Mvh. Hendrik
| |
|
|