Low Latency "database" server.

[HeepH]

Mijn vader maakt in zijn bedrijf gebruik van een stukje software. Dit is eigenlijk een database met gegevens over planten, klanten, en afspraken.

Op het moment is er 2 man fulltime bezig met het werken in deze applicatie. De ene computer word gebruikt, en dient tevens ook als server voor de andere computer. De andere computer (en dus client van de server) ondervind hierdoor natuurlijk hinderlijke vertragingen.

Nu is het besluit genomen dat er een server komt. Sowieso omdat mail en agenda geschroniseert moeten (en willen). Nu was onze gedachte : Als deze server er dan toch komt, dan gelijk goed en dan richten we hem zo in dat we er onze applicatie op kunnen hosten, en dan wel zo dat er zo min mogelijk vertraging optreed in het gebruik. Dus,

Een server, met daarop de database

paar clients (2, misschien meer maar <5) die zo snel mogelijk toegang willen hebben tot de data. We hebben het hier over kleine bestanden maar de accestime is belangrijk. Records wil je zo snel mogelijk zien, foto's en afbeeldingkjes (<100 KB) moeten meteen op je scherm verschijnen en een databasje met plantennamen doorzoeken mag ook geen eeuwen duren zoals je begrijpt.

Dus de vraag is : Hoe richt ik mijn netwerk en server zo in dat ik de I/O op de server en op het netwerk zo low latency mogelijk is?

Tevens moet er natuurlijk ook gebackupped worden,maar het nadeel van backups door raid is dat het de latency verhoogt.

Ik moet er bij zeggen dat ik veel ervaring heb met raid,hardware, en io op desktop gebied.Op het servergebied heb ik me echter minder geconcentreerd dus welke hardware raid controller de snelste is weet ik niet uit mijn hoofd.

Ik had het grofweg zo in mijn hoofd :

- moederbordje met pci-e 16x aansluiting,
- processortje erop (hoeft niks geks te zijn),
- 2GB geheugen (4? kan je hdd-io cachen op je ram geheugen? en low latency,nut?)
- dikke raid controller (Areca ARC-1220 ?)
evt met nog meer cache als dat mogelijk is.
-Sowieso ook gbit internet maar evt zelfs losse netwerkkaarten als deze lagere latency hebben...

En welke disks wil ik in deze server? Erg veel storage is er voor die database niet nodig, en de backups kunnen wel op "gewone" disks...

Dan raid 5 denk ik, hoewel raid 0, en dus ook raid 5, theoritisch een _hogere_acces time ten gevolge kunnen hebben, dus dan zou ik eerder geneigd zijn voor raid 1 te gaan)

Welke tips and trics hebben jullie nog?

Edit : SHIT ik vergeet helemaal dat we tegenwoordig solid state schijven hebben, ik zie ze net staan in de pricewatch. Ik ken de techniek nu nog even naar de prijzen kijken.

[ Voor 5% gewijzigd door HeepH op 21-06-2008 14:40 ]

[Verwijderd]

Er missen nog wat belangrijke gegevens:

- Welke db? SQL?
- Hoe groot is de db?
- Meeste toegang is schrijven? Lezen? Of beide evenveel?

Verder zou ik al snel een standaard a-merk server nemen. Geen gedoe met zelfbouw als het stabiel moet zijn. Verder is een snelle RAID controller natuurlijk een vereiste en 15k SCSI disks. Wat is je budget trouwens? Verder zou je voor RAID 10 kunnen gaan. Kost je wat disks maar dan heb je wel de beste performance.

Verder kan eigenlijk alles de latency beinvloeden. Clients, NIC, switches, bekabeling, server etc etc.

[Jazzy]

Ga in ieder geval zelfs niets in elkaar knutselen maar koop een server bij een A-merk lverancier zoals HP of Dell. Doe er een eenvoudig service-contractje bij en je hebt 3 of 5 jaar gegarandeerd een server.

Met 2 man werken in een database die plaatjes van 100 kB serveert is werkelijk peanuts. Ik denk dat je je ten onrechte focust op details als latency en access time. Enerzijds door het feit dat de applicatie maar licht belast wordt, anderszijds omdat huidige SAS disken al snel zat zijn al zet je ze in RAID5.

Waar je verder om moet denken?
- Zorg dat je backup buiten de deur is en dat je goed over het restoren van data en recoveren van een hele server hebt nagedacht.
- Schaf een fatsoenlijk switchje aan, als je dat nog niet had gedaan, en zorg dat je kabels in orde zijn.
- Denk aan de mogelijkheid van SBS 2003, die biedt namelijk alle fucntionaliteit die je hierboven genoemd hebt. Schaf SA aan als je de nieuwste versie wilt gaan gebruiken die binnenkort uitkomt.

[Herko_ter_Horst]

Gezien de zeer geringe omvang van je wensen (<5 clients snel afhandelen gaat elke willekeurige server met groot gemak trekken) zou ik geen al te ingewikkelde dingen bedenken.

Hang voor de grap al test eens een desktop-class PC met een RAID 0 array van 7200 rpm disks via Gbit ethernet aan het netwerk en ik denk dat je al heel eind komt. Als dat klopt, kun voor iets meer betrouwbaarheid gaan voor een instap tower (of rack) server van bijv. Dell, met inderdaad een RAID 10 array.

Edit: ehh, what he said

[ Voor 3% gewijzigd door Herko_ter_Horst op 21-06-2008 14:58 ]

[HeepH]

Ik weet niet wat voor DB. Er zit namelijk een software schilletje omheen. Ga maar even uit van SQL.

De DB is <5 GB groot. Ik zit er dan ook aan te denken het geheel in het ram geheugen te cachen. Dan zit ik alleen nog met de backups van de rest van het systeem maar daar zitten niet zo'n hoge eisen aan. Of evt de database op een SSD en de rest op "urdinaire" 7200 rpm samsung w/e schijfjes (aan de raid controller dan wel)

De meeste toegang is lezen, ik denk 80 % lezen 20% schrijven.

Budget... 2000, 2500 max? Minder is beter maar wat moet dat moet.

Zijn er specifieke tips voor bijvoorbeeld NIC's? is het een idee om elke client zijn eigen nic te geven of is het gewoon server > switch > clients het snelst? ...

EDIT : Ik begrijp dat ik overkill aan het configuren ben. Maar zolang het budget het toestaat vind ik het geen probleem. Tuurlijk ga ik geen 15 scsi schijven aan een 32 poorts areca hangen met 2gb geheugen. Maar ik wil ook absoluut geen gedoe en gezeur. Gewoon snel, heel snel.

Ik neig steeds meer naar 2 x 32 GB SSD's in raid (seek time van die ssd's zijn geweldig), op een relatief eenvoudige controller maar met cache (of zeggen jullie : dat is niet nodig..). Dan een vlotte stand alone nic, en wat grotere disks ook op de raid controller (3 / 5 x 320/500 gb 7200rpm is wel genoeg data security).

Even ter verduidelijking de totale backup is rond de 200 GB. Dit is dan prive en zakelijk. De database is 5 GB.

Een snel switchje is leuk en ik ga zeker naar de mogelijkheden van Windows Server 2003 kijken. We schakelen misschien (waarschijnlijk) een extern adviesburo in voor de software configuratie.

Off-site backup is al geregeld en is meer dan afdoende.

[ Voor 40% gewijzigd door HeepH op 21-06-2008 15:05 ]

[Jazzy]

Ik weet niet of ik het al gezegd had, maar voor jouw eisen is iedere instapserver al voldoende. Lekker mijmeren over SSD is natuurlijk leuk maar hoort niet in het wat serieuzere PNS.

[Paul]

Met dat gebruik zou ik zeggen de simpelste Dell of HP die je kunt vinden met een paar SATA-schijven in raid1, 2gb ram, Windows 2003 Small Business Server R2 erop (Premium als je SQL of ISA nodig hebt en nog geen SQL-licentie hebt of met Express niet uit komt).

En dan het belangrijkste: de leverancier van die software schoppen dat ze hun pakket eens optimaliseren. Daarmee is VEEL meer winst te behalen. Simpel voorbeeldje: wij hadden een knopje in een pakket dat een halve minuut nodig had om 'iets' te doen als je er op klikte. 1 rondje met de query analyzer en 2 indexen later was hij in 0,002 seconde klaar...

[Gomez12]

Ik zie je probleem even niet. 2 clients, 5Gb dbase. Dat moet imho zelfs een pentium III nog wel trekken.
SSD etc is allemaal leuk en aardig maar heb je ooit wel eens gekeken wat nou echt het probleem is door gewoon eens heel simpel wat testjes te gaan doen?

Want of je app is brak, of je Db is brak. Maar 100kb tussen 2 pc's in een lokaal lan verplaatsen mag nooit en te nimmer tot problemen leiden en vereist dus ook geen speciale middelen imho.

[Emmeau]

DB performance problemen moet je op (laten) lossen daar waar de problemen liggen, en niet met getruukte oplossingen.

Je roept 'SQL', bedoel je mssql? mysql? of een sql-achtig iets?

Ik heb het vage vermoeden dat die hele app rond een Access db geschreven is, en dat performt nu eenmaal niet lekker over een netwerk.

In het geval dat het daadwerkelijk een mysql, mssql, oracle or whatever fatsoenlijk rdbms is, dan wordt het hoog tijd om met de applicatie bouwer een babbeltje te gaan maken over de performance.

Geef eens wat meer (technische) info over die app?

[HeepH]

Mijn App is brak. Dat weet ik. Maar ik moet het er mee doen. Ondertussen ben ik zelf ook een paar stapjes terug gestapt.

Ik wil nog steeds een SSD (of 2) . Deels practisch en stiekem ook wel omdat het leuk is. Daarnaast voor de backups een aantal disks met een raid 5 controller puur voor redundancy en dan kom ik er wel.

Is er een manier om er achter te komen hoe de app is opgebouwd ? sql/acces/wiv ?

[ Voor 11% gewijzigd door HeepH op 21-06-2008 17:00 ]

[Gomez12]

Misschien een raar idee, maar gewoon vragen aan de ontwikkelaar?

En als ik het begrijp ga je nog steeds voor een zelfbouwbak? Moet je zelf weten, maar zou ik nooit doen. Gewoon een standaard instap servertje met een support contract.
Gaat er dan ooit eens hw stuk dan is het het probleem van HP en niet van jou...

[SKiLLa]

SQL is een taal, geen database-software, dan heb je het inderdaad over b.v. MSSQL over MySQL (of Oracle, Progress, etc.). Reken maar dat elke fatsoenlijke db-server afdoende caching heeft.

Het scenario dat je schetst moet inderdaad makkelijk te doen zijn. Als het nu traag is, dan heb je waarschijnlijk een gigantische bottleneck ergens zitten; 10 Mbps netwerk, veel te weinig RAM in de "server PC" (continue swapfile-access) en/of een trage/overbelaste HDD.

Elke moderne duo-core machine met 4 GB (RAM kost toch niets en DB-performance valt of staat oa. met voldoende RAM caching) en een simpele RAID5 oplossing voldoet. SSD is stoer, hip en leuk, maar het is onnodig; veel te duur voor je budget en levert amper performance-winst op in jou geval.

En valt die app niet simpel te tweaken ? Heb wel eens meegemaakt met een administratie pakket dat de DB server config op 64MB RAM cache stond ingesteld (met 2 GB RAM beschikbaar !), daar deze al jaren in gebruik was en simpelweg 1-op-1 overgezet was naar steeds moderne hw, zonder de config aan te passen aan de nieuwe situatie ...

PS: Altijd merk-server met service-contract kopen; goedkoper, betrouwbaarder en makkelijker dan zelfbouw. En je hebt geen gezeur als dingen stuk gaan en/of niet werken als verwacht, want wie gaat om 03:30 's nachts de server fixen als ie stuk is en wie gaat het dan betalen ? Etc, etc ...

[ Voor 11% gewijzigd door SKiLLa op 21-06-2008 17:08 . Reden: de PS ]

[Emmeau]

Heephstan schreef op zaterdag 21 juni 2008 @ 16:55:
Mijn App is brak. Dat weet ik. Maar ik moet het er mee doen.

Jouw app, als in 'door mij geschreven', of als in 'door de fabrikant aangeleverd'?

Ik wil nog steeds een SSD (of 2) . Deels practisch en stiekem ook wel omdat het leuk is. Daarnaast voor de backups een aantal disks met een raid 5 controller puur voor redundancy en dan kom ik er wel.

Dingen kopen omdat het 'leuk' is is 'leuk', maar hoeft totaal niet zinvol te zijn.
Als de DB dermate triest is, dat bij een SELECT statement, de hele dataset over de lijn moet, dan kan je de snelste van de snelste disks gebruiken, maar je bottleneck blijft je netwerk.

Je zult dus echt een performance meting moeten gaan doen om te kijken waar de bottleneck zit.

Is er een manier om er achter te komen hoe de app is opgebouwd ? sql/acces/wiv ?

mysql, mssql oracle draaien als services. Die zijn makkelijk genoeg te spotten in de service manager bijvoorbeeld.

Komen er een *.mdb *.ldb bestandjes voorbij in de applicatie folder, dan zal het eerder access zijn.

[The Eagle]

Hoe heet die app die gebruikt wordt? Als een von ons die naam door Google heen haalt, zijn we er denk ik zo uit waar we nou precies over praten
Kunnen we ook een fatsoenlijk en onderbouwd advies geven, want dit blijft zo gissen namelijk.

[ Voor 24% gewijzigd door The Eagle op 21-06-2008 17:12 ]

[HeepH]

Hmm. Na mijn eigen constatering dat het eigenlijk niet moet kunnen, en tevens jullie benadrukkingen toch maar eens aan het tweaken geslagen en meer dan voldoende perfomancewinst geboekt.

Wireless (toch even proberen he ) was huilen. Bedraad maar via een switch was nog steeds traagjes maar ik vermoed dat de firewall op de pc's hier mee van doen heeft, en 1 op 1 aangesloten is het allemaal redelijk vlot. Ik vermoed dat de bottleneck die ik ga krijgen toch bij de software zit, aangezien de software wel over zijn nek gaat als je met 2e tegelijkertijd werkt, maar niet als je in je eentje op de server zit. Er zullen dus wel een paar (grote!) bugs in de software zitten.

Toch bedankt voor jullie reacties allemaal, ik pas de wensen aan mijn servertje aan...

[Emmeau]

Heephstan schreef op zaterdag 21 juni 2008 @ 17:12:
Hmm. Na mijn eigen constatering dat het eigenlijk niet moet kunnen, en tevens jullie benadrukkingen toch maar eens aan het tweaken geslagen en meer dan voldoende perfomancewinst geboekt.

Mischien handig om ons in te lichten hoe/wat je gedaan hebt?

Wireless (toch even proberen he ) was huilen. Bedraad maar via een switch was nog steeds traagjes maar ik vermoed dat de firewall op de pc's hier mee van doen heeft, en 1 op 1 aangesloten is het allemaal redelijk vlot. Ik vermoed dat de bottleneck die ik ga krijgen toch bij de software zit,

Dat de software de bottleneck is/was hebben we een aantal posts geleden al teruggestuurd. Je firewall zal trouwens niet echt in de wegzitten performance wise.
Het feit dat via wireless de performance nog trager was, leidt tot een 'voorlopige' conclusie van mijn kant dat de app geen fatsoenlijk rdbms gebruikt, maar eerder iets access achtig/flatfile/eigen db brouwsel.

aangezien de software wel over zijn nek gaat als je met 2e tegelijkertijd werkt, maar niet als je in je eentje op de server zit. Er zullen dus wel een paar (grote!) bugs in de software zitten.

Performance problemen en bugs zijn twee verschillende dingen.

Laat ik de vraag anders stellen, om de app te kunnen gebruiken op de niet-server, share je dan de netwerkdrive ?
of installeer je de applicatie op de machine (niet server) en geef je aan via ip adres waar de database staat?

En als laatste (en tevens mijn laatste post hier totdat je meer info geeft)
- WELKE app, wie heeft dat ding geschreven, etc etc. Het valt me op dat deze vraag diverse keren aan je gesteld is door meerdere mensen, maar je deze niet lijkt te willen beantwoorden.

[Yen]

Enkele opmerkingen.

• RAID is een (zeer) slechte manier op backups te maken.
• Gebruik een fatsoenlijke RDBMS.

[Equator]

Tja, als jij het verrekt om meer informatie te geven, dan gaat dit topic - wat toch al op het randje van sterven ligt - gewoon dicht.

PNS is niet bedoeld voor applicatie debugging, en een netwerkje met 2 PC's en een DB server is ook niet de doelgroep.

Als je de performance wilt debuggen en je wil daar toch over praten met anderen, dan zou ik als ik jou was met wat meer info op de proppen komen. En plaats je topic dan in een correct subforum.

Suc6