Vi har både styr på IIS og SQL
server / ASP her i virksomheden og vore lønninger er noget anderledes end i DK,
en ikke helt uvæsentlig
detalje når der skal findes og løses fejl.
Vi har oplevet det samme problem. Hos os var det problemet at noget af koden der beyttes på site, ikke er optimeret. Derfor opstår der periodisk et problem med serveren.
Vi har løst det med et lille script der tjekker for dette og resetter IIS og derved RAM forbruget, alt i mens der sker en optimering af de sites der har skidt kode. Det er også set før ved MSSQL at den kan blive en slem RAM sluger, hvis ikke koden er sat ordentlig op i forhold til denne. MSSQL kan sættes op med trace, så vi kan se om der eventuelt skulle være SQL kald der giver problemet.
Jeg ville starte med at gennemgå jeres logs som det første, de kan typisk fortælle rigtig meget. Derudover er det vigtigt at I ser på ressouce forbruget, når denne fejl opstår. Selve Fejlsøgningen er oftes den største tidstrøver i sådan en process. Fejlretningen er efterfølgende nemmere at give en fast pris på.
Men langt det meste kan formentlig ordnes remote, og det gør det forholdsvist billigere at arbejde med.
Vi har folk placeret her i Danmark, hvor vi arbejder med dette til daglig til en fornuftig pris. Du er velkommen til at kontakte mig for en uforpligtigende snak om dette.
En måde at give jeres IIS lidt luft på, er at bruge den såkaldte /3gb switch. Sagen er den at selvom jeres maskine er har f.eks. 4 Gb, så kan IIS'en maskimalt få lov at bruge 2 Gb. Medmindre man sætter 3Gb switchen. Så får den lov at bruge 3 Gb.
Hvis man opgraderer til en 64-bit og tilhørende styrersystem. Så kan man få lov at bruge endnu mere ram.
Det lyder som om at jeres billeder måske, bliver serveret direkte fra databasen, det er en rigtigt dårlig ide hvis I har mange besøgende. Istedet bør de skrives til filer, og serveres derfra. IIS'en er hamrende hurtig til at serverer statiske filer. Billederne kan stadig ligge i databasen, men bør caches som filer.
Jeg tror ikke mere ram vil løse problemet, med mindre jeres cpu'er køre 100% hele tiden.
Det lyder umiddelbart som et resource leak, hvilket i burde kunne se i task manageren. Hvis VMSize bliver ved med at tælle op uden at den kommer ned igen, er selve leaket konstateret - så skal i "bare" finde ud af hvad der gør det. Typsisk et 3. parts produkt/library hvis i har nogen? Et andet "leak" problem kan være at serven er stresset med 100% cpu belastning hele tiden, og derfor ikke får frigivet resourcer. Men der kan også sagtens være andre problemer, og kombinationer af disse.
Jeg har arbejdet med performance/skalering i mange år, og vil relativt hurtigt kunne komme med løsningsforslag på jeres performance (og måske skalerings problemer), ud fra et code-review. At finde et resource leak er mere problematisk og kræver nok at være on site, kan i reproducere det i et andet miljø ?
Bliv gratis medlem
Opret bruger