Tregt økonomisystem (Visma)

[arne22]

Hei !

 

Jeg/vi har en installasjon av et Visma økonomiprogram på en forholdvis gammel (4-5 år ?) HP Proliant ML150 server med kun 1 GB RAM (3.0 MHz Xenon.)

 

Systemet har ikke så mange samtidige brukere, men det kjører tregt når det jobber med store datamengder.

 

Det dreier seg vel om en gratisversjon av en Microsoft Sql server i bunnen av det hele (dvs i bunnen av økonomiprogrammet.)

 

Hva vil være den enkleste måte å få litt mer fart på dette ? Vil det være noe større hjelp i å legge til noe mer ram ? (DDR 2700/333)

 

Vil det hjelpe noe større å skifte ut gratisversjonen av Sql server med en litt dyrere variant, eller er det noe annet man bør gjøre.

 

Kan det være at databasen har behov for noen form for vedlikehold for å bli raskere ?

[j--]

Svarer nå kun på spørsmålet med RAM.

 

Sjekk hvor mye ram som er i bruk når det går treigt. Om man har 4GB med RAM, men aldri bruker mer enn 2GB, så vil maskina ikke arbeide noe raskere med 8GB RAM enn med 4GB RAM.

 

-------

 

Kan jo også være en idé å sende en mail til Visma og høre?

[arne22]

Takker for svar.

 

Studium av minnebruk er gjort. Den har jo bare 1 Gb så det er vel mitt inntrykk at den "swapper" mot HD. (Er dog ikke sikker ettersom jeg aldri har lyktes i å løpe fort nok, når det har oppstått treghet.)

 

Visma er vel selvfølgelig kontaktet, men de svarer ikke noe fornuftig, selv om det dreier seg om en stadig vekk vedlikeholdt og opdatert lisens.

Endret 8. desember 2011 av arne22

[conundrum]

1 Gb er ikke mye for en SQL-server, men hvorvidt det er for lite eller ikke til ditt bruk, kommer an på belastningen. Kan du gi litt mer informasjon, som f.eks:

 

- operativsystem

- SQL-versjon (2005/2008/2008 R2)

- om serveren også har andre oppgaver (fil-/printserver, DC, andre applikasjoner)

- hvilket Visma-produkt det er snakk om

- hvor mange samtidige brukere dere har

- og ikke minst: Hvilke(n) operasjon(er) i Visma som går treigt, og hva "treigt" innebærer

 

Når det gjelder minnebruk, vil du nok oppdage at SQL-tjenesten legger beslag på alt minnet. Det skal den gjøre, for ytelsen blir best hvis mest mulig data caches i RAM. Setter du i en ekstra Gb RAM i serveren, vil også dette umiddelbart bli brukt opp, uten at det betyr at maskinen hadde for lite minne før oppgraderingen.

 

At du hører diskene arbeide tungt, behøver ikke å ha med mangel på minne å gjøre. Med mindre du har 100+ brukere som kjører spørringer kontinuerlig, er det mer sannsynlig at tregheten skyldes andre forhold. Her er noen klassikere:

 

- man bruker en applikasjon som kjører mange sekvensielle spørringer, men MSSQL-databasene er satt til "auto close" (standard i 2008+) slik at de lukkes og gjenåpnes for hver spørring

- man tar ut rapporter e.l. som kjører spørringer mot ikke-indekserte tabeller

- applikasjonens SQL-spørringer er autogenerert av et eller annet utviklingsverktøy, og resultatet er spørringer der selve spørringsteksten bare såvidt får plass på en A4-side (hei, Mamut)

 

Å bytte til en fullversjon av MSSQL vil neppe gjøre noen som helst forskjell. Express-versjonene har noen begrensninger sammenlignet med fullversjonen relatert til maksimal størrelse på en database, hvor mye minne SQL-tjenesten kan utnytte, og hvor mange prosessorkjerner den kan ta i bruk. Det er lite sannsynlig at du nærmer deg noen av disse begrensningene.

 

Edit: skrivefeil

Endret 8. desember 2011 av conundrum

[arne22]

Mange takk for svar !

 

Operativsystem .. selvfølgelig det er jo Windows 2003 server. (Oppdatert og med servicepakker.)

 

Det er ikke mer enn et par tre brukere. Det som skal gå tregt er visst nok å bruke enkle raporteringsverktøy.

 

Tror det dreier seg om Visma Global (Faktureringsprogram ?)

 

Har lite greie på økonomisystemer, som man kanskje forstår.

 

Leverandørens anbefaling var vel bare å kjøpe ett nytt og bedre databasesystem, i stedet for express versjonen, men sitter vel med en følelse av at de kanskje ikke ville hjelpe så mye.

 

Tror ikke at det finnes rapportgenereringer utover det som Visma har levert som "standard".

 

Kan det være slik at det kan være en innstilling for hvordan SQL databasen åpner og lukker som kan få mer speed på dette ?

Endret 8. desember 2011 av arne22

[conundrum]

Windows 2003 krever ikke mye minne til sine kjernetjenester, så med 1 Gb burde være nok RAM igjen til å kjøre en SQL-base også. Jeg må likevel ta forbehold om hva som ellers kjører på serveren; hvis man f.eks. kjører Windows Server Update Services og/eller Windows Deployment Services, har de sin egen SQL-base som da kommer i tillegg. Da kan 1 Gb fort bli lite.

 

Når det er sagt, bør Visma Global m/2-3 brukere knapt utgjøre noen belastning overhodet. Dette er nok et problem relatert til applikasjonen eller innstillinger på SQL-serveren.

 

Det er litt begrenset hva du kan gjøre selv, annet enn å kontrollere at "Auto Close" ikke er slått på for databasen. Du kan også sjekke at mappen med SQL-databasene og loggfilene er unntatt fra scanning av et eventuelt antivirusprogram på serveren, men det er mange år siden jeg sist så AV-systemer som prøvde å scanne SQL-filer.

 

Det er altså ikke veldig sannsynlig at tregheten skyldes noen av disse forholdene. Hvis du derimot kan snakke med brukerne og finne ut eksakt hvordan problemet kan reproduseres, er det faktisk en bagatell for en SQL-kyndig person å finne årsaken.

 

Dessverre er det generelt slik at når en applikasjonsleverandør blir forelagt slike problemstillinger, svarer de automatisk at serveren er for svak og må oppgraderes. Det er også generelt slik at det så godt som alltid er applikasjonen eller databasen som er det egentlige problemet. Å oppgradere serveren blir som å løse problemet med dårlig akselerasjon på bilen med å sette i kraftigere motor, mens det underliggende problemet er at du har punktert.

 

Forresten, har dette problemet oppstått relativt nylig, innen det siste halvåret eller så? Jeg har nemlig en kunde som melder om dårlig ytelse i Global, og der er det snakk om 1 - én - bruker og en mye kraftigere server.

[arne22]

Takker for informativt svar.

 

Jeg vil forsøke å snakke litt nærmere med brukerne av systemet, når disse "treghetene" egentlig oppstår. Jeg tror "tregheten" har kommet gradvis i løpet av 6-12 mnd.

 

Jeg misstenkte vel egentlig akkurat det samme "ut i fra instinkt og uten saklig begrunnelse" at det kan han noe med applikasjon/database å gjøre.

 

Det dreier seg ellers om en "small business server" som kjører "alle mulige tjenester" på en maskin. Belastningen er allikevel ganske liten, med kun et par tre brukere på økonomisystmet.

 

Tror på den annen side at det ligger forholdvis store datamengder på systemet.

Endret 9. desember 2011 av arne22

[conundrum]

Det dreier seg ellers om en "small business server" som kjører "alle mulige tjenester" på en maskin. Belastningen er allikevel ganske liten, med kun et par tre brukere på økonomisystmet.

OK, det betyr at også Exchange 2003 kjører på denne maskinen, og den representerer en ikke ubetydelig belastning. Jeg ser på en 2003 SBS-server jeg har tilgang til, at store.exe legger beslag på like i underkant av 600 Mb, og i tillegg kommer inetinfo.exe med 27 Mb og mad.exe med 20.

 

Jeg ville definitivt anbefalt mer minne i en server som skal kjøre SBS + SQL-databaser, men jeg tror likevel dine antakelser om at dette er applikasjonsrelatert, stemmer.

 

Tror på den annen side at det ligger forholdvis store datamengder på systemet.

Det burde ikke være relevant for SQL-data dersom tabellene er riktig indeksert. Vedlikehold av indeksene blir mer krevende ettersom datamengdene øker, men det vil man typisk bare merke dersom man legger inn større datamengder, f.eks. ved import.

 

Dersom dataene derimot ikke er korrekt indeksert... vel, da må serveren bla seg manuelt igjennom hele tabellen, og du vil se diskene jobbe intenst.

 

Sjekk Performance Monitor, og sett gjerne opp automatisk innsamling av data noen timer i arbeidstiden. Hvis maskinen er presset for minne, vil "Page Faults/sec" være høy. Hvis det derimot er SQL-tjenesten som jobber mot disken, vil du se "Average Disk Queue Length" gå i taket når tregheten oppstår.

[arne22]

Takker. Skal forsøke