Nu større ramforbrug, nu langsommere side.

Hvordan bliver den plads brugt? Det kunne godt lyde som om der ligger noget snavs og roder i RAM'en, evt. uafsluttede transaktioner?
(PS: Jeg bliver altså nødt til at sige det: Det hedder "*Jo* større ramforbrug, *desto* langsommere side" - det samme gælder resten af nu'erne.)

Hej ocp, hvad mener du med, "hvordan bliver den plads brugt?" Det kunne da godt tænkes at der ligger noget snavs og roder i RAM'en, men hvordan finder jeg ud af om det er tilfældet og hvad kan jeg gøre ved det? Det er nemlig ganske fast at hvergang ramforbruget ryger op på 850+ MB så bliver siden langsomere. Dette mærkes dog kun når der er mange brugere online. Når ramforbruget når så højt at siden bliver langsom bliver jeg nødt til at genstarte sql-server servicen, hvorefter det kører godt igen. Min transaction-log har i lang tid fyldt 147MB men er pludselig hoppet op på små 698MB. Databasen filen selv fylder 816MB.

Du kan gå ind i enterprise manageren, højreklikke på databasen og vælge options. Sørg for at "truncate log on checkpoints" er slået til. Flere brugere vil altid betyde ringere performance, men så skal der altså være en del brugere.
Det er meget almindeligt at RAM-fobruget vokser jo mere databasen benyttes - hvis der er RAM nok vil SQL Serveren såmænd lægge hele databasen i RAM da det er væsentlig hurtigere end en harddisk.

Hvor mange brugere er på ad gangen? Kører serveren andre tunge services (f.eks. IIS)? Kunne der være programfejl i ASP/Stored Procedures der starter processer som kører i det uendelige og dermed forringer performance?

Det er et par forslag til punkter du kan "kaste dig over".

Jeg kan ikke se noget der hedder "truncate log on checkpoints" under options for databasen. Det er sql server 2000.

Der er hver dag typisk op til 250 samtidige brugere på websiten (ifølge livestats 5.0). SQL server og IIS køres pt. på samme server, men vil snarest køre på hver sin server. IIS bruger typisk kun mellem 3-15% CPU. Serveren kører med 2 x PIII 1133 mhz processorer og har 3GB ram.

Der burde ikke være fejl i stored procedures/ASP. Nu er det godt nok ikke mig der har kodet siden, men hvad der kunne gå udover performance som SELECT * mv. er ændret.

Hov... truncate log on checkpoint er sgu røget ud i SQL Server 2000 - undskyld.
Det er problematisk at både IIS og SQL Server kører på samme maskine - de er begge "sultne". En løsning KAN være at gå ind på server properties og sætte en minimumstørrelse på SQL Serverens RAM-forbrug. Så er du sikker på at de tabeller SQL-serveren benytter kan blive liggende i RAM længst muligt.

Mht. performanceoptimering/troubleshooting er det er god ide at benytte følgende link:

http://support.microsoft.com/search/preview.aspx?scid=kb;en-us;Q110352

Det er en glimrende, kort fejlsøgningsmanual.

Tak for hjælpen.

Selvom spørgsmålet er lukket og jeg dermed antager at du er tilfreds med svaret, kan jeg ikke lade være med at kommentere, for jeg mener der er sagt lidt noget vrøvl. Og jeg synes altså at hov-kommentaren omkring "truncate log on breakpoint" i SQL Server 2000 indikerer at vedkommende ikke rigtig har fulgt med :-)

Truncate log on breakpoint svarer i SQL Server 2000 til "Simple Recovery Model". Denne vælges ganske rigtig på Options fanebladet som der henvises til.

Det lyder mere som om du er bange for CPU procenten end RAM forbruget og derfor kan jeg ikke se, at det skulle hjælpe at sætte en min. på RAM. SQL Server vil i øvrigt alligevel først allokere den specificerede min. mængde RAM, når den tvinges derop af aktiviteten på serveren.

Ud af de SQL Servere jeg arbejder med til dagligt, kører de 6 af dem også med IIS. Dette gælder både NT4/IIS4 og W2K/IIS5. Den mest belastede server kører med omkring 500 brugere om dagen, med peeks omkring ca. 150 samtidige brugere uden problemer. Derfor kan jeg slet ikke genkende skrækken for at køre med disse på samme server.

Til gengæld kan jeg genkende skrækken for 99% CPU til SQL Server, for det slår benene væk under mange mennesker. Men SQL Server er så snedig indrettet, at den tager al den CPU den "får lov til". Du kan derfor sagtens opleve at SQL Server tager 99% CPU på en maskine med én bruger, der laver simple forespørgsler.

Men er din konstatering af, at den kører langsom baseret på facts eller fornemmelse ? Har du kørt en trace i Profiler, i første omgang efterfulgt af en Performance Tuning Wizard ?
- rigtig mange problemer med performance ligger i database design og elendig SQL programmering. Mangel på- eller forkerte indexes og lad os så bare kalde det knap-så-heldige SQL statements, kan kvæle selv den mes kraftfulde database server.

Du kan iøvrigt finde mange gode performance tuning tips her:

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

Og jeg glemte lige at nævne, at serveren med de 150 samtidige brugere, kører på en 850 Mhz processor og 1 GB RAM :-)