---

Hej NG!

Jeg driver et website, som efterhånden har vokset sig så stort, at den
bagvedliggende MS SQL 7 server ikke længere kan følge med i peak.

Hvordan løser man nemmest og billigst dette problem?
Der er ikke resourcer til at købe en dyr SAN løsning, så flere forskellige
MS SQL servere arbejder med de samme filer konstant. Er der andre løsninger?

På forhånd tak.

--
Mvh. Jesper

---

Som svar på skriblerier forfattet af Jesper Nielsen

> Jeg driver et website, som efterhånden har vokset sig så stort, at den
> bagvedliggende MS SQL 7 server ikke længere kan følge med i peak.
>
> Hvordan løser man nemmest og billigst dette problem?
> Der er ikke resourcer til at købe en dyr SAN løsning, så flere
> forskellige MS SQL servere arbejder med de samme filer konstant. Er
> der andre løsninger?
>
Hvilket hardware/Raid setup kører du med
Har du tjekket med Profileren at der ikke er noget der "driller"
Hvad med indexes?
Check de langsomme queries med QA (Query Analyzer)
Kører du med OLEDB eller ODBC
Kører du med Named Pipes eller TCPIP
Kører du med flere Web servere der connecter til een MSSQL server?

Hvor ligger flaskehalsen
Disk? CPU? Andet?

mvh/Peter Lykkegaard

---

> Hvilket hardware/Raid setup kører du med

Dell PowerEdge 1400SC, 1 GHz, 512 MB ECC SDRAM, 18 GB SCSI i RAID 5.


> Har du tjekket med Profileren at der ikke er noget der "driller"

Jep, og der ser ikke ud til at være nogen problemer.


> Hvad med indexes?

De er optimerede.


> Check de langsomme queries med QA (Query Analyzer)

Er gjort, og vi har da også fået optimeret nogle indexes ved det.


> Kører du med OLEDB eller ODBC

OLEDB.


> Kører du med Named Pipes eller TCPIP

TCPIP.


> Kører du med flere Web servere der connecter til een MSSQL server?

Nej, der er kun én server, som connecter til den (med mindre der er en som
administrerer SQL'en via EM.


> Hvor ligger flaskehalsen
> Disk? CPU? Andet?

Diskene har det fint - det er CPU'en, der er problemet.
Vi har ikke lyst til at skalere op ad - vi vil here skalere bredt, da det er
en mere langsigtet løsning. Der kommer jo et tidspunkt, hvor serveren ikke
længere kan opgraderes. Så hellere skalere bredt fra starten.

--
Mvh. Jesper

---

Som svar på skriblerier forfattet af Jesper Nielsen

>> Hvilket hardware/Raid setup kører du med
>
> Dell PowerEdge 1400SC, 1 GHz, 512 MB ECC SDRAM, 18 GB SCSI i RAID 5.
>
Ok, evt OS på et spejl og data på RAID 5
Evt ekstra spejl til transactionslog
Det er vel hardware raid?
>
>> Kører du med OLEDB eller ODBC
> OLEDB.
>> Kører du med Named Pipes eller TCPIP
> TCPIP.
>
Det er sgu OK
>
>> Hvor ligger flaskehalsen
>> Disk? CPU? Andet?
>
> Diskene har det fint - det er CPU'en, der er problemet.

MSSQL er designet til at tage sig kærligt af 2 cpu'ere, det kan varmt
anbefales
En ½Gig ram kan være en begrænsning på MSSQL
Hvad siger ram forbrug?
Hvad med netkortet hygger det sig eller er der run på?
Kører du med SP's eller ligger select statements i applikationen?

mvh/Peter Lykkegaard

---

> Det er vel hardware raid?

Jep.

> >> Kører du med OLEDB eller ODBC
> > OLEDB.
> >> Kører du med Named Pipes eller TCPIP
> > TCPIP.
> >
> Det er sgu OK

Ja, det skulle jeg også mene var den mest optimale opsætning.


> > Diskene har det fint - det er CPU'en, der er problemet.
>
> MSSQL er designet til at tage sig kærligt af 2 cpu'ere, det kan varmt
> anbefales

Kan MS SQL 7 Standard klare mere end 1 CPU?


> En ½Gig ram kan være en begrænsning på MSSQL
> Hvad siger ram forbrug?

Der er ca. 100 MB fri RAM på et hvilketsomhelst tidspunkt.


> Hvad med netkortet hygger det sig eller er der run på?

Lige nu er der 124 brugere online, og netkortet er på ingen måde
overbelastet. Så det hygger sig

> Kører du med SP's eller ligger select statements i applikationen?

Statements ligger i applikationen. Vi har tænkt på at gå over til SP, men
hvor stor betydning har det egentlig?

--
Mvh. Jesper

---

Som svar på skriblerier forfattet af Jesper Nielsen

>> MSSQL er designet til at tage sig kærligt af 2 cpu'ere, det kan varmt
>> anbefales
>
> Kan MS SQL 7 Standard klare mere end 1 CPU?
>
http://www.mssqlserver.com/articles/options_p1.asp
>
>> En ½Gig ram kan være en begrænsning på MSSQL
>> Hvad siger ram forbrug?
>
> Der er ca. 100 MB fri RAM på et hvilketsomhelst tidspunkt.
>
Det er vel total mem usage set i forhold til den halve Gig?
>
>> Hvad med netkortet hygger det sig eller er der run på?
>
> Lige nu er der 124 brugere online, og netkortet er på ingen måde
> overbelastet. Så det hygger sig

Øhh, hvor mange hits ligger de ca om dagen - og i spidserne?
>
>> Kører du med SP's eller ligger select statements i applikationen?
>
> Statements ligger i applikationen. Vi har tænkt på at gå over til SP,
> men hvor stor betydning har det egentlig?

Det skulle gerne give noget, da serveren ellers compiler og danner ny
queryplans hver gang

Hvordan kalder I egentlig databasen
Via command objectet eller via Connection/Recordset
Er der taget højde for adExecuteNoRecords ved opdateringer?
Er der taget højde for firehose recordset kontra updateable recordset?
Ligger cursoren clientside eller serverside?
Det kan også give lidt hvis man venter med at sortere til recordsettet er
hentet

En anden metode er danne statiske hml sider scheduleret ud fra databasen
fx http://www.4guysfromrolla.com kører på den måde

mvh/Peter Lykkegaard

---

> http://www.mssqlserver.com/articles/options_p1.asp

Det vil jeg lige kigge på.


> > Lige nu er der 124 brugere online, og netkortet er på ingen måde
> > overbelastet. Så det hygger sig
>
> Øhh, hvor mange hits ligger de ca om dagen - og i spidserne?

Der er et sted mellem 1.000 og 10.000 sidevisninger pr. time alt efter
tidspunktet. Tror det højeste vi har været oppe på er 15.000 sidevisninger
med 152 brugere online.


> Det skulle gerne give noget, da serveren ellers compiler og danner ny
> queryplans hver gang

Okay - det skal vi overveje igen, kan jeg se.


> Hvordan kalder I egentlig databasen
> Via command objectet eller via Connection/Recordset

Vi bruger de fleste steder ADODB.Connection.
Ét sted bruges dog ADODB.Recordset pga. paging af søgeresultat.


> Er der taget højde for adExecuteNoRecords ved opdateringer?
> Er der taget højde for firehose recordset kontra updateable recordset?
> Ligger cursoren clientside eller serverside?

Det er jeg ikke lige umiddelbart klar over.


> Det kan også give lidt hvis man venter med at sortere til recordsettet er
> hentet

Hvordan gøres dette?


> En anden metode er danne statiske hml sider scheduleret ud fra databasen
> fx http://www.4guysfromrolla.com kører på den måde

Det gør vi også på de mest belastende områder.
F.eks. vores online liste og listen over de nyeste medlemmer. Hvert 5.
sekund køres der en ASP fil, som læser forskellige informationer fra online
tabellen, timer inaktive brugere ud og til sidst laver den en array
bestående af de resterende aktive brugere, som web serveren herefter sørger
for at splitte og præsentere på den ønskede måde.

Således skal web serveren ikke belaste SQL serveren med 10.000 ekstra
forespørgsler pr. time i peak.

--
Mvh. Jesper

---

Som svar på skriblerier forfattet af Jesper Nielsen

>
>> Hvordan kalder I egentlig databasen
>> Via command objectet eller via Connection/Recordset
>
> Vi bruger de fleste steder ADODB.Connection.
> Ét sted bruges dog ADODB.Recordset pga. paging af søgeresultat.
>
Man kan med fordel benytte Command objectet
Det gir lidt ekstra ala sp's
>
>> Er der taget højde for adExecuteNoRecords ved opdateringer?
>> Er der taget højde for firehose recordset kontra updateable
>> recordset? Ligger cursoren clientside eller serverside?
>
> Det er jeg ikke lige umiddelbart klar over.
>
Brug firehose og clientside cursors hvor det er muligt
Evt gå et skridt videre og brug disconnected recordsets
>
>> Det kan også give lidt hvis man venter med at sortere til
>> recordsettet er hentet
>
> Hvordan gøres dette?

Metoden Sort på Recordset Objectet

mvh/Peter Lykkegaard

---

> Man kan med fordel benytte Command objectet
> Det gir lidt ekstra ala sp's

Okay. Jeg vil lige kigge på sagen.


> >> Det kan også give lidt hvis man venter med at sortere til
> >> recordsettet er hentet
> >
> > Hvordan gøres dette?
>
> Metoden Sort på Recordset Objectet

Recordsets undgår jeg helst pga. den overhead, det kan skabe.

--
Mvh. Jesper

---

"Jesper Nielsen" <jn@nielsenit.dk> wrote
> Recordsets undgår jeg helst pga. den overhead, det kan skabe.

Tør man spørge hvordan du viser dine data hvis du ikke bruger et Recordset?

--
Jakob Andersen

---

> > Recordsets undgår jeg helst pga. den overhead, det kan skabe.
>
> Tør man spørge hvordan du viser dine data hvis du ikke bruger et
Recordset?

Et lille eksempel:

<%
Option Explicit
Dim Conn, Qry, SQL

Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open Application("strConnect")

SQL = "SELECT felt1,felt2,felt3 FROM table WHERE ....;"
Set Qry = Conn.Execute(SQL)

If Qry.Eof = False Then
Do While Qry.Eof = False
Response.Write(Qry("felt1") & " " & Qry("felt2") & " " & Qry("felt3")
& "<br>")
Qry.MoveNext
Loop
Else
Response.Write("Jeg fandt ingen felter, som opfyldte kriterierne")
End If

Set Qry = Nothing
Conn.Close
Set Conn = Nothing
%>

--
Mvh. Jesper

---

"Jesper Nielsen" <jn@nielsenit.dk> wrote
> Set Qry = Conn.Execute(SQL)

Execute metoden på connection objektet returnerer netop et recordset, så
deeet:

<http://msdn.microsoft.com/library/en-us/ado270/htm/mdmthcnnexecute.asp>

--
Jakob Andersen

---

> Execute metoden på connection objektet returnerer netop et recordset, så
> deeet:

Ja, det er objektet ADODB.Recordset jeg snakker om.
Den undgår vi hvor vi kan.

--
Mvh. Jesper

---

"Jesper Nielsen" <jn@nielsenit.dk> wrote
> Ja, det er objektet ADODB.Recordset jeg snakker om.
> Den undgår vi hvor vi kan.

Det er sådan set det der bliver returneret også. Det jeg tror du mener er at
i forsøger _ikke_ at opnår recordsettene med Recordsettet's open metode, men
dette er sådan set også en fejl da dette nogen gange kan forbedre
performance fremfor at returnere Recordsettet fra Connection objektets open
metode.

Spørg evt. i ASP gruppen hvis du vil diskutere optimering af dataadgangen
fra ASP sider.

--
Jakob Andersen

---

Som svar på skriblerier forfattet af Jesper Nielsen

> Recordsets undgår jeg helst pga. den overhead, det kan skabe.

Øhh, please explain
Du har da skrevet at du bruger Connection.OpenRecordset eller
Connection.Execute og nogle få gange Recordset.Open
Ved at sætte dine options rigtigt så får du minimalt overhead
Dvs adForwardOnly og adUseClient - svjh

Men det er måske GetRows du tænker på?

Det er vist mere ASP end database så jeg lægger den videre diskussion
derover
XFUT: dk.edb.internet.webdesign.serverside.asp

mvh/Peter Lykkegaard

---

Men hvis man vil stille ekstra SQL servere op til at dele loadet, _skal_ de
så have shared storage? Eller kan det gøres på andre måder? Jeg kunne ikke
forestille mig, at replikering ville være optimalt - dataene skulle jo helst
være ens på alle servere.

--
Mvh. Jesper

---

Som svar på skriblerier forfattet af Jesper Nielsen

> Men hvis man vil stille ekstra SQL servere op til at dele loadet,
> _skal_ de så have shared storage? Eller kan det gøres på andre måder?
> Jeg kunne ikke forestille mig, at replikering ville være optimalt -
> dataene skulle jo helst være ens på alle servere.

Clustering og Win2K Advanced Server
http://www.sql-server-performance.com/q&a_clustering.asp

Men prøv lige med en ekstra processor først
Samt andre ting
http://www.sql-server-performance.com/q&a_performance.asp

Det er noget usædvanligt at een webserver kan trække mssql ned
Jeg går ud fra at webserveren ikke er ved at dø?

mvh/Peter Lykkegaard

---

> Clustering og Win2K Advanced Server
> http://www.sql-server-performance.com/q&a_clustering.asp

Det er godt nok også en ret dyr løsning...


> Men prøv lige med en ekstra processor først
> Samt andre ting
> http://www.sql-server-performance.com/q&a_performance.asp

Ja, tror også det bliver den umiddelbare løsning.


> Det er noget usædvanligt at een webserver kan trække mssql ned
> Jeg går ud fra at webserveren ikke er ved at dø?

Nej, webserveren har det fint - den keder sig selv i peak. Det er yderst
sjældent, at den bruger mere end 15% CPU.

--
Mvh. Jesper

---

Som svar på skriblerier forfattet af Jesper Nielsen

>> Det er noget usædvanligt at een webserver kan trække mssql ned
>> Jeg går ud fra at webserveren ikke er ved at dø?
>
> Nej, webserveren har det fint - den keder sig selv i peak. Det er
> yderst sjældent, at den bruger mere end 15% CPU.

Det får godt nok nogle alarmklokker til at ringe hos mig
Anyways
Nogle gange kan det drille hvis man ikke får reindekseret ens tabellerne
efter at man er gået i produktion med sin database

Prøv at køre den her mod databasen
Den er fra http://www.databasejournal.com/features/mssql/article.php/1438931
Du kan evt køre den på en tekstbox først
Den trækker sandsynligvis nogle tænder ud, så jeg vil ikke lige føre den af
during rushhour
Jeg har noget lign kørende scheduleret via SQL Server Agent på de
installationer jeg laver rundt omkring
Behovet er størst på databaser der kører med stor udskiftning af data

---------------------------------------------------------
declare @cmd varchar(255)
declare ic insensitive cursor for

select 'dbcc dbreindex (' + name + ')' from sysobjects where type = 'U'
open ic
fetch next from ic into @cmd

while @@fetch_status = 0
begin
exec (@cmd)
fetch next from ic into @cmd
end

close ic
deallocate ic
-------------------------------------------------------

mvh/Peter Lykkegaard

---

Som svar på skriblerier forfattet af Jesper Nielsen

> Men hvis man vil stille ekstra SQL servere op til at dele loadet,
> _skal_ de så have shared storage? Eller kan det gøres på andre måder?
> Jeg kunne ikke forestille mig, at replikering ville være optimalt -
> dataene skulle jo helst være ens på alle servere.

Btw mht clustering kan de smide slæverne forbi
dk.edb.system.ms-windows.server

Jeg har sat XFUT dertil

mvh/Peter Lykkegaard

---

Som svar på skriblerier nedfældet af Jesper Nielsen :

>> Kører du med SP's eller ligger select statements i applikationen?
>
> Statements ligger i applikationen. Vi har tænkt på at gå over til SP,
> men hvor stor betydning har det egentlig?

Lige en anden ting der slog mig
Du kan jo bruge Profileren til at fange de queries der rigtig langsomme
Profileren kan køre på en anden maskine, så du ikke belaster
databaseserveren unødigt

Når du har fundet de langsomme, så er det med stor sandsynlig nogle joins
indblandet
Jeg har med fordel anvendt nestede SQL statements fremfor joins hvor jeg kun
skulle fremfinde nogle få værdier (1-2)
fx
Select f.a, f.b, (select b.z from foobar b where f.a = b.a) as z from foo

Du bør også kikke på hvordan dine where clauses er sat sammen i forhold til
de eksisterende indexes

Jeg går ud fra at der er flest selects og nogle få updates eller?
For mange indexes specielt et forkert clustered index kan slå serveren ihjel
ved updates ved at stort antal records

mvh/Peter Lykkegaard

---

> Jeg går ud fra at der er flest selects og nogle få updates eller?
> For mange indexes specielt et forkert clustered index kan slå serveren
ihjel
> ved updates ved at stort antal records

Ja, det er rigtig mange selects og kun få updates.

Tak for hjælpen so far

--
Mvh. Jesper

---

"Jesper Nielsen" <jn@nielsenit.dk> wrote

> > Hvilket hardware/Raid setup kører du med
>
> Dell PowerEdge 1400SC, 1 GHz, 512 MB ECC SDRAM, 18 GB SCSI i RAID 5.

RAID 5 kan godt være et problem hvis der skrives meget til databasen, da
skrivning er en del langsommere end læsning pga. pariteten (også hardware
RAID).

18 Gb IAlt ? - Så tyder det på en del små og langsommme diske, måske mere fart
her...

Ellers ville jeg starte med at smide 2GB RAM i serveren, 512Mb er lige i
underkanten til høj performance, og som Peter Lykkegård skriver kunne en
ekstra CPU'er hjælpe godt til.


Rune

---

> 18 Gb IAlt ? - Så tyder det på en del små og langsommme diske, måske mere
fart
> her...

Der er SVJH 3 18 GB diske i serveren.
Diskene har ingen problemer - de har ikke travlt eller noget.


> Ellers ville jeg starte med at smide 2GB RAM i serveren, 512Mb er lige i
> underkanten til høj performance, og som Peter Lykkegård skriver kunne en
> ekstra CPU'er hjælpe godt til.

Jep, jeg vil prøve at skalere lidt opad, selvom jeg hellere ville skalere
bredt allerede nu, så fremtidige udvidelser blev lettere.

--
Mvh. Jesper

---

Som svar på skriblerier forfattet af Jesper Nielsen

> Jeg driver et website, som efterhånden har vokset sig så stort, at den
> bagvedliggende MS SQL 7 server ikke længere kan følge med i peak.
>
Der er lidt læsestof her

http://www.sql-server-performance.com
http://www.mssqlserver.com

Speed up your ASP pages: Turn Them into HTML with ASPTear!
http://www.4guysfromrolla.com/webtech/071800-1.shtml

mvh/Peter Lykkegaard