[DB] 1200 records p/sec inserten?

dinsdag 13 juni 2006 17:17

Tring Tring!

Topicstarter

lier schreef op dinsdag 13 juni 2006 @ 15:17:
Met name is je disk IO hier van belang, misschien kan je je OT even uitbreiden met welke discs / IO controller / indeling in schijven / verdeling van de files over de verschillende volumes ?

Daarnaast (ik ben helaas niet bekend met bovengenoemde producten) is het verstandig om te kijken wat de bottleneck voor deze situatie is, maar dat kan alleen op locatie gebeuren.

Ik heb de machine zelf niet ingericht, en ik weet niet wat voor schijven er op dit moment in zitten. Ik zal vandaag en morgen even een aantal dingen checken. De processorbelasting komt iig niet boven de 60% uit op dit moment.

AtleX schreef op dinsdag 13 juni 2006 @ 15:20:
Moeten het er per sé 1200 per seconde zijn? Of neem ook genoeg met zeg 900 of 1000 per seconde? En waarom die je meerdere updates na een insert, is dat nodig?

Nee het moet echt 1200 en liefst nog meer. Die insert update volgorde is zeker van belang en kan niet gewijzigd worden.

bakkerl schreef op dinsdag 13 juni 2006 @ 15:27:
Wat is de rest van de hardware?
Je wil nogal veel opslaan of wijzigen, dus alleen met CPU en MEM ben je er nog niet.

Wat voor HD controller zit erin? wat voor HDs zitten erin (15k rpm?), in raid config, zoja wat voor. Wat is de indeling van de HDs.
Wat voor Xeon's? in HT ingeschakeld? zijn het dualcores?
Wat is het OS en wat draait er nog meer voor services op dit machine.

Hoe is mysql geinstalleerd, standaard package of een eigen compilatie (met wat voor settings).

Hoe connecten de 8 clients naar de server? 100mbit hubje of 1Gb switch? full- of half-duplex

Allemaal factoren die nog mee kunnen spelen. Mysql moet nog wel meer dan die 1200 updates/insert per sec kunnen halen.

Standaard 100mbit link via switch. Overigens ben ik verkeerd geinformeerd en ga ik nu ff de OT herschrijven

Verstand van Voip? Ik heb een leuke baan voor je!

Acties:

djc

Uhm, waarom wil je per se een DB gebruiken? Als je write mostly doet, kan je dan niet beter een of ander eenvoudig CSV-achtig bestand schrijven, en eventueel daar later data uittrekken?

Rustacean

dinsdag 13 juni 2006 17:42

Acties:

dinsdag 13 juni 2006 20:30

Tring Tring!

Topicstarter

Manuzhai schreef op dinsdag 13 juni 2006 @ 17:17:
Uhm, waarom wil je per se een DB gebruiken? Als je write mostly doet, kan je dan niet beter een of ander eenvoudig CSV-achtig bestand schrijven, en eventueel daar later data uittrekken?

Ik heb de DB gewoon nodig. Het zijn oa statistieken

Verstand van Voip? Ik heb een leuke baan voor je!

Acties:

MSalters

Waarschijnlijk be je het verkeerde probleem aan het oplossen. Je probleem is namelijk niet dat je bestaande hardware te langzaam is, en dat je per se een zuivere MySQL software oplossing moet hebben. Jou 2 jaar MySQL laten tweaken kost je baas meer dan een hardware upgrade. Sterker nog, met de huidige hardware prijzen wordt dat al vrij snel bereikt.

Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein

dinsdag 13 juni 2006 20:42

Acties:

dinsdag 13 juni 2006 22:28

Security!

MSalters schreef op dinsdag 13 juni 2006 @ 20:30:
Waarschijnlijk be je het verkeerde probleem aan het oplossen. Je probleem is namelijk niet dat je bestaande hardware te langzaam is, en dat je per se een zuivere MySQL software oplossing moet hebben. Jou 2 jaar MySQL laten tweaken kost je baas meer dan een hardware upgrade. Sterker nog, met de huidige hardware prijzen wordt dat al vrij snel bereikt.

Dit is een ding wat zeker is!

Ik zou die bestaande disk op zijn minst los gooien van het systeem schrijf gebeuren.
Je kan de data files dan lekker op een aparte snelle disk neer zetten. Een 10k schijf SCSI bijv. presteert al snel net zoveel als de snelle raptors simpelweg vanwege de optimalisaties in de hardware. En dat soort dingen ga je merken. Desnoods op RAID-0 en dan altijd trouw en zeker iedere dag een backup draaien!

Hoe zit dat met dat netwerk? Worden die record over die 100Mbit/s heen gepompt? Dat wordt niet altijd veel sneller met Gigabit netwerk spul.
Je moet je netwerk frames wel fatsoenlijk vullen voor je de volledige performance er uit haalt. Met 100Mbit heb je altijd wel een goede vullingsgraad, ga je sneller, dan moet je in zo'n burst wel voldoende data te versturen hebben. Dus laat je nooit 1-2-3 opnaaien dat je naar gigabit moet, onderzoek het eerst effe

I've visited the Mothership @ Cupertino

Acties:

bakkerl

Let there be light.

Als ik alles zo lees zou ik de gehele database server vervangen voor een nieuwe.

Zonder dat we hier diverse gegevens hebben gezien van alle stats (netwerk, disk, cpu), durf ik toch wel te beweren dat een nieuwe beter (voor database werk) ingerichte machine beter zal presteren en de prerformance eisen halen die je stelt.

ps Doe ook eens een netwerk IO meting. Wel op server als de clients, je heb best kans dat de clients weing staat te doen. 8x100mbit proppen door 1x100mbit van de server past niet.

woensdag 14 juni 2006 07:14

Acties:

Verwijderd

MSalters schreef op dinsdag 13 juni 2006 @ 20:30:
Waarschijnlijk be je het verkeerde probleem aan het oplossen. Je probleem is namelijk niet dat je bestaande hardware te langzaam is, en dat je per se een zuivere MySQL software oplossing moet hebben. Jou 2 jaar MySQL laten tweaken kost je baas meer dan een hardware upgrade. Sterker nog, met de huidige hardware prijzen wordt dat al vrij snel bereikt.

Ik vind dat een beetje afhangen van de grootte van het probleem.
Als hij nu 100 rows/s heeft en hij moet 1200 rows/s, dan red je het niet met een hardware upgrade.

--edit--
Als ik verhaal doorlees (maar ik heb alleen MSSQL-ervaring) is je probleem meer locking/blocking? Ik zou de PK (clustered als je dat iets zegt) samenvoegen met een andere kolom om zo meerdere hotspots te creeeren...

[ Voor 16% gewijzigd door Verwijderd op 14-06-2006 07:20 ]

woensdag 14 juni 2006 08:22

Acties:

woensdag 14 juni 2006 12:02

Software Architect

Werkt hier

megamuch schreef op dinsdag 13 juni 2006 @ 15:14:
8 machines moeten binnen zeer korte tijd (max 5 minuten) 1200 records p seconde inserten. (Dwz, insert, update update, update, insert, update, update, update etc).

Is er na die 5 mins een pauze of gaat het continu door?
Als er een pauze zou zijn kan je nog die gegevens eerst in losse tabellen opslaan en daarna samenvoegen.

Wat voor updates zijn dat? Toch geen updates op het net geinserte record he, want dan had je net zo goed gelijk het goede record kunnen inserten? Verpak je verder die insert+updates in een transactie of laat je innodb de transactieoverhead voor elke query los uitvoeren?

Gebeuren die updates een where op die ene index die je hebt? En misschien kan je je updates combineren zodat er minder algemene overhead is?

De tabel is op dit moment 8 miljoen records groot en wordt uiteindelijk op jaarbasis zo'n 52 miljoen.

En wat voor records zijn het? Getalletjes? Lange stukken tekst?

Hardware: single p4 3ghz HT enabled met 1gb ram op SATA 2 schijf onder debian linux 3.1 (rev1)

Ik vind dat eerlijk gezegd vrij krap. Als je zoveel i/o wilt kunnen verwerken moet je er ook wel voor zorgen dat je bijpassende hardware hebt. Vergeet niet dat je met die 1200rec/s je niet netjes sequentieel aan het schrijven bent, maar grotendeels random en je dus erg veel disk-head-movements zal hebben. Een goede raid-controller (areca bijv) met een paar snelle disks (WD raptor's of scsi/sas) gaat je al een stuk meer schrijfprestaties opleveren.

Zolang er 1 client aan de DB hangt, gaat het prima. Zowel onder MySQL 4 en 5 innoDB en MyISAM. Echter 8 clients gaat volledig de mist in bij innoDB mysql5. Te traag. MyIsam trekt het op dit moment net, maar de vraag is of het bij 52 miljoen ook nog gaat.

En doet die ene client dan 1200 rec/s of doet ie er dan 1200/8 rec/s ? Dat MyISAM het met 8 clients trekt vind ik trouwens knap, want die kan helemaal niet met concurrent writers overweg, die moeten allemaal op hun beurt wachten.

Qcache staat uit, key buffer size 16m, 400 threads (die zijn ook nodig) naar de DB, logging uit.

Heb je verder voor innodb nog tuning gedaan? Met name de grootte van de logfile van innodb (ander soort log) is waarsch wel vrij belangrijk.

Mijn vraag is eigenlijk in het algemeen: Wat voor trucs kan je uithalen op een MyIsam danwel InnoDB write mostly Database. Welke settings zijn nog van invloed op de performance, of heb ik gewoon snellere hardware nodig.

Query- en transactieoverhead verlagen, o.a. door meer queries in een enkele transactie te verpakken en eventueel lichtere queryvarianten te nemen (batch-insert/updates bijv), aantal queries verlagen.

En verder heb je grote kans dat je snellere hardware nodig hebt ja.

EDIT: Na de opening van dit topic is de TS aangepast!!! Ik dacht dat een dual xeon was, maar dat zijn de clients die verbinden naar de DB. Bij deze aangepast

Dus de clients zijn sneller dan je server, dat is wel een interessante constructie

Verwijderd schreef op woensdag 14 juni 2006 @ 07:14:
Ik vind dat een beetje afhangen van de grootte van het probleem.
Als hij nu 100 rows/s heeft en hij moet 1200 rows/s, dan red je het niet met een hardware upgrade.

Waarom niet? De kans is best groot dat je met een WD raptor al 3x de performance haalt, meer geheugen erin je nog wat oplevert en verder wat tuning aan de queries en procedures de rest oplevert.
Als het dan nog niet genoeg is kan je kijken naar een goede raid-controller met write-caching aan zodat ie de commando's netjes kan op de goede volgorde kan zetten en de losse disks dus meer sequentieel aan de slag kunnen en je dus veel meer schrijfprestaties haalt.

Acties:

woensdag 14 juni 2006 20:41

Tring Tring!

Topicstarter

ACM schreef op woensdag 14 juni 2006 @ 08:22:
[...]

Is er na die 5 mins een pauze of gaat het continu door?
Als er een pauze zou zijn kan je nog die gegevens eerst in losse tabellen opslaan en daarna samenvoegen.

Wat voor updates zijn dat? Toch geen updates op het net geinserte record he, want dan had je net zo goed gelijk het goede record kunnen inserten? Verpak je verder die insert+updates in een transactie of laat je innodb de transactieoverhead voor elke query los uitvoeren?

Gebeuren die updates een where op die ene index die je hebt? En misschien kan je je updates combineren zodat er minder algemene overhead is?

Het zou in feite nog langer kunnen doorgaan. Ik merk dat ik toch een duidelijkere beschrijving moet geven van het platform. Bij deze:

Het gaat hier om het afhandelen van een grote hoeveelheid telefoon gesprekken.
8 machines nemen gesprekken aan en moeten uit dezelfde DB gegevens ophalen. Per machine zijn er 50 threads naar de mysql machine. In totaal dus 400. Deze threads blijven openstaan, en worden dus niet continue opnieuw opgebouwd.

Goed wat gebeurd er allemaal:

Iemand belt, wij nemen op en schrijven record in DB met daarin oa starttijd en welk nummer er gebelt wordt. DB maakt nieuw record aan. We halen last insert id op. Nu voeren we een 2 updates uit op een zeer kleine tabel (max 2k records). Beller hangt op, we updaten het eerder geschreven record en schrijven eindtijd erbij.

En wat voor records zijn het? Getalletjes? Lange stukken tekst?

Dat zijn datetime, ints, en een enkel varchar veldje.

Ik vind dat eerlijk gezegd vrij krap. Als je zoveel i/o wilt kunnen verwerken moet je er ook wel voor zorgen dat je bijpassende hardware hebt. Vergeet niet dat je met die 1200rec/s je niet netjes sequentieel aan het schrijven bent, maar grotendeels random en je dus erg veel disk-head-movements zal hebben. Een goede raid-controller (areca bijv) met een paar snelle disks (WD raptor's of scsi/sas) gaat je al een stuk meer schrijfprestaties opleveren.

Mee eens. De opzet was in eerste instantie ook voor max 4 clients, maarja, things happen. Er staat overigens wel een upgrade geplanned, maar toch willen we proberen te kijken naar mogelijke oplossingen voor de huidige situatie. Het zit hem namelijk niet in de complexiteit van de queries. Alleen de hoeveelheid.

En doet die ene client dan 1200 rec/s of doet ie er dan 1200/8 rec/s ? Dat MyISAM het met 8 clients trekt vind ik trouwens knap, want die kan helemaal niet met concurrent writers overweg, die moeten allemaal op hun beurt wachten.

Die ene client doet dan 1200/8. De situatie is moeilijk na te bootsen. Ik heb niet zomaar 8 extra machines beschikbaar om een 1 op 1 test uit te voeren. Het is zeker mogelijk om een applicatie te schrijven die de situatie nabootst, maar de vraag is dan in hoeverre je je echt vergelijkbare resultaten gaat halen tov je live platform.

Heb je verder voor innodb nog tuning gedaan? Met name de grootte van de logfile van innodb (ander soort log) is waarsch wel vrij belangrijk.

InnoDB heeft geen tuning gehad. (tijdsgebrek) Ik ben op dit moment een kopie van de DB aan het maken zodat we de InnoDB even flink kunnen stresstesten. Vandaar ook dit topic. Welke trucjes kan je uithalen bij InnoDB. Ik ben zelf niet zo heel erg bekend met deze storage engine omdat MyISAM altijd voor mij afdoende is geweest. In dit geval probeer ik wat collega's te helpen en als je naar de voordelen van InnoDB kijkt, dan lijkt het idd de ideale oplossing voor onze situatie. (Oa row level locking tov table locking).

Query- en transactieoverhead verlagen, o.a. door meer queries in een enkele transactie te verpakken en eventueel lichtere queryvarianten te nemen (batch-insert/updates bijv), aantal queries verlagen.

En verder heb je grote kans dat je snellere hardware nodig hebt ja.

Meer queries in een enkele transactie zal niet gaan denk ik. Om het even te illustreren. Per client worden er 330 calls aangenomen. Die 330 calls hebben een threadpool van 50 op de MySQL machine. 8 x 50 = 400 threadconnects op MySQL. Die threadpool wordt continue gevoed door de clients. Ik zal straks is wat meetingen doen vwb de traffic van en naar de machine.

Dus de clients zijn sneller dan je server, dat is wel een interessante constructie

I know. Nou doen de clients vrij veel werk. Oa Voice recognition, text-2-speech, voip, soundrecording, dus zo gek is het niet. Ben het wel met je eens dat de MySQL machine een upgrade moet hebben. Zeker omdat er over een paar dagen 7 clients bij gaan komen!

Waarom niet? De kans is best groot dat je met een WD raptor al 3x de performance haalt, meer geheugen erin je nog wat oplevert en verder wat tuning aan de queries en procedures de rest oplevert.
Als het dan nog niet genoeg is kan je kijken naar een goede raid-controller met write-caching aan zodat ie de commando's netjes kan op de goede volgorde kan zetten en de losse disks dus meer sequentieel aan de slag kunnen en je dus veel meer schrijfprestaties haalt.

Daar ben ik het wederom (het wordt saai) helemaal mee eens. Maar $$ is ook een factor. Die clients zijn per stuk al ruim 12k het stuk, en ergens ligt de grens. Die grens moet natuurlijk wel goed getrokken worden, maar als het even kan willen we toch proberen de maximale performance uit de beschikbare hardware te halen. (En deze kop ik zelf maar even in, Ja is de hardware niet snel genoeg is zal je toch echt een andere machine neer moeten zetten).

Nogmaals, thanks voor alle input.

Verstand van Voip? Ik heb een leuke baan voor je!

Acties:

donderdag 15 juni 2006 02:07

Software Architect

Werkt hier

megamuch schreef op woensdag 14 juni 2006 @ 12:02:
Iemand belt, wij nemen op en schrijven record in DB met daarin oa starttijd en welk nummer er gebelt wordt. DB maakt nieuw record aan. We halen last insert id op. Nu voeren we een 2 updates uit op een zeer kleine tabel (max 2k records). Beller hangt op, we updaten het eerder geschreven record en schrijven eindtijd erbij.

En wanneer zijn die gegevens nodig? In principe alleen als naslag/loggegevens?

Is het niet een idee om dan een "dag" of "uur"-tabel bij te houden voor elke client en die gegevens van afgeronde gesprekken periodiek in je master-tabel te integreren? Die master-tabel zou je zelfs nog op een 2e server kunnen zetten.
Of je zou die minitabel bij kunnen houden op je clients zelf, afhankelijk van hoeveel gegevens ze van je master-db nodig hebben.

Belangrijkste voordeel is dat je maar 1 keer zo'n record aanraakt als je het in je master-db zet. Niet ook nog eens een update er op etc.

Het zit hem namelijk niet in de complexiteit van de queries. Alleen de hoeveelheid.

Klopt, maar die tabel wordt wel snel en steeds sneller groter lijkt me? Dus je probleem wordt alleen maar erger, zeker nog met meer clients erbij.

Meer queries in een enkele transactie zal niet gaan denk ik. Om het even te illustreren. Per client worden er 330 calls aangenomen. Die 330 calls hebben een threadpool van 50 op de MySQL machine. 8 x 50 = 400 threadconnects op MySQL. Die threadpool wordt continue gevoed door de clients. Ik zal straks is wat meetingen doen vwb de traffic van en naar de machine.

Daar is idd weinig aan te doen. Ik zou toch kijken naar kleine "tijdelijke" tabelletjes per client en/of tijdseenheid. Maar dat moet natuurlijk met je applicatie wel mogelijk zijn dan.

Een andere optie is bijvoorbeeld om open gesprekken in een en gesloten gesprekken in een andere tabel te hebben.

Het grootste voordeel wat ik daarvan zie is dat je updates en inserts op hele kleine tabellen blijven en dat je de grote tabellen "wanneer het je uitkomt" met een enkele thread bij kan werken.

Acties:

donderdag 15 juni 2006 03:00

Tring Tring!

Topicstarter

ACM schreef op woensdag 14 juni 2006 @ 20:41:
[...]

En wanneer zijn die gegevens nodig? In principe alleen als naslag/loggegevens?

Is het niet een idee om dan een "dag" of "uur"-tabel bij te houden voor elke client en die gegevens van afgeronde gesprekken periodiek in je master-tabel te integreren? Die master-tabel zou je zelfs nog op een 2e server kunnen zetten.
Of je zou die minitabel bij kunnen houden op je clients zelf, afhankelijk van hoeveel gegevens ze van je master-db nodig hebben.

Belangrijkste voordeel is dat je maar 1 keer zo'n record aanraakt als je het in je master-db zet. Niet ook nog eens een update er op etc.

We hebben er idd aan zitten denken om een dag tabel te maken. En deze dagelijks 's nachts over te gooien naar 'het archief'. Het 'probleem' hierbij is dat je weer een extra process erbij krijgt, wat ook weer monitoring / onderhoud en storingen op kan leveren.

Klopt, maar die tabel wordt wel snel en steeds sneller groter lijkt me? Dus je probleem wordt alleen maar erger, zeker nog met meer clients erbij.

Jep, nu 8 systemen, volgende week 11 en eind vd maand wellicht al 15 systemen. Dat gaat die machine (die nu overigens weer op mysql5 icm MyISAM runt) natuurlijk never nooit trekken.

Daar is idd weinig aan te doen. Ik zou toch kijken naar kleine "tijdelijke" tabelletjes per client en/of tijdseenheid. Maar dat moet natuurlijk met je applicatie wel mogelijk zijn dan.

Een andere optie is bijvoorbeeld om open gesprekken in een en gesloten gesprekken in een andere tabel te hebben.

Het grootste voordeel wat ik daarvan zie is dat je updates en inserts op hele kleine tabellen blijven en dat je de grote tabellen "wanneer het je uitkomt" met een enkele thread bij kan werken.

Tabellen per client zal niet gaan. Mede ook omdat er bepaalde relaties tussen de verschillende systemen kunnen ontstaan. Het inserten van het record is oa belangrijk bij de start vd call omdat het autoinc veld gebruikt kan worden voor vele interne toepassingen zoals: Voice recording, (Sla de file op met naam $id.wav), Schrijf antwoord op vraag weg in file $id.txt etc.

De statistieken zijn tevens direct nodig vanwege realtime stats. Adhv die stats worden er tijdens pieken ook beslissingen genomen. Als de stats dus al meer dan 10 seconden achterlopen, kan dat best wel invloed hebben voor het verloop van een actie.

Overigens heb ik vandaag even flink bij gelezen over InnoDB. Mysql roept zelf dat Buffer pool size ongeveer 80% van je ram moet zijn. tsja.. Als die machine dan ingesteld staat op 16mb (default value) en er zit 1GB in dan gaat dat dus niet goed.

Ik moet me nog even verdiepen in het splitsen van de ibdata en de iblog delen en het eventueel splitsen daarvan over verschillende volumes. Dat kan natuurlijk erg helpen.

Vandaar ook als eerste dit topic, welke software params hebben de grootste invloed op de snelheid van InnoDB.

Misschien dat iemand anders deze vraag wel kan beantwoorden:

Waarvoor dient de Log file size. Heb ik die wel nodig? Wil ik wel een log? Dat kost disk i/o. Of is dat gewoon vanwege de transaction support in InnoDB om rollbacks uit te voeren? In dit geval wil ik helemaal geen transaction support. Het gaat me meer om de row level locking. Kan ik dat flushen dus helemaal achterwege laten?

Goed genoeg om over na te denken.

Laatste vraag: iemand een goeie applicatie om sql te testen gevonden? (dus niet de standaard perl sql bench).

Verstand van Voip? Ik heb een leuke baan voor je!

Acties:

Gomez12

megamuch schreef op donderdag 15 juni 2006 @ 02:07:
[...]

Tabellen per client zal niet gaan. Mede ook omdat er bepaalde relaties tussen de verschillende systemen kunnen ontstaan. Het inserten van het record is oa belangrijk bij de start vd call omdat het autoinc veld gebruikt kan worden voor vele interne toepassingen zoals: Voice recording, (Sla de file op met naam $id.wav), Schrijf antwoord op vraag weg in file $id.txt etc.

Stap af van autoinc velden, maak 1 tabel extra aan genaamd counters. Per client 1 row. Definieer per client een eigen id-range ( bijv client 1 heeft 10.000 tot 19.999 client 2 heeft 20.000 tot 29.999 ) houd de counters bij in de counter tabel, kost je 1 select/update per client ( in een tabel van 8 records zonder indexen iets ) maar scheelt je de locking die op kan treden als 8 clients op hetzelfde moment om een autoinc vragen. IMHO experience is dit sneller ( alhoewel ik met iets meer clients (150) werk )

De statistieken zijn tevens direct nodig vanwege realtime stats. Adhv die stats worden er tijdens pieken ook beslissingen genomen. Als de stats dus al meer dan 10 seconden achterlopen, kan dat best wel invloed hebben voor het verloop van een actie.

Client-side is krachtig, server-side niet echt. Is er niet een mogelijkheid om client-side een andere aktie te doen indien drukte , vereist extra (simpele bijv alleen huidige aantal calls ) tabel waaruit de clients 1 extra select doen en je de noodzaak voor de realtime stats terugdringt ( want waarschijnlijk drukken realtime stat ook redelijk op je performance ) waardoor je wel iets kan doen met periodieke stats ( 1x per 5 minuten )

Overigens heb ik vandaag even flink bij gelezen over InnoDB. Mysql roept zelf dat Buffer pool size ongeveer 80% van je ram moet zijn. tsja.. Als die machine dan ingesteld staat op 16mb (default value) en er zit 1GB in dan gaat dat dus niet goed.

Dus tweak eerst innodb eens. Kijk naar logs / transacties / pools / moeten alle tabellen wel op innodb staan ( myisam is sneller, maar onbetrouwbaarder )

Waarvoor dient de Log file size. Heb ik die wel nodig? Wil ik wel een log? Dat kost disk i/o. Of is dat gewoon vanwege de transaction support in InnoDB om rollbacks uit te voeren? In dit geval wil ik helemaal geen transaction support. Het gaat me meer om de row level locking. Kan ik dat flushen dus helemaal achterwege laten?

Mijn idee : Logging is super belangrijk. Kost dit een nieuwe server, dan moet dat maar. Wat gebeurt er op dit moment als 2 minuten voor de backup ( 's nachts ) de raid array / schijf het helemaal opgeeft? ( Met onafhankelijke logging ( aparte machine / hdd ) kan je je dbase weer opbouwen uit een backup van gisteren tot een situatie als dat er net was, zonder kost je dit een dag gegevens hoeveel is dit waard? ) Logging is bij ons gewoon onderdeel van het backup-recoveryplan.
Plus dat een log in een geoptimaliseerde database net iets minder info kan geven dan de log zelf, vb in dbase sla ik niet op wie het record inserte vanwege snelheid. Maar in log is dit wel op te slaan, is toch flat-file, rampzalig met zoeken maar snel met toevoegen.

Trouwens : Klopt het getal van 1200 inserts per seconde wel ???
1200 per sec =
72.000 per minuut =
4.320.000 per uur =
34.560.000 per dag ( dag = 8 uur ).
Dus je draait nog niet eens 2 uur???
Zelfs als ik insert, update, update, update pak en het getal deel door 4 dan draai je nog maar 8 uur.

Maar copieer de logging eens na een uur, kijk welke transacties veel tijd kosten en optimaliseer deze.

Nog een paar tips
1 . probeer je insert / update / update / update om te bouwen
2 . Zet elke stap ( dus insert en update en update en update ) om naar een stored procedure ( MYSQL 5 ondersteunt dit ), dit optimaliseert over het algemeen beter.
3 . Lever vanaf de client zoveel mogelijk in batches ( transacties ) aan aan de mysql server.dan hoeft de mysql server niet te zoeken naar een optimaal pad voor een insert actie, daarna voor een update actie etc, maar kan er in 1 keer gezocht worden naar het beste pad voor een insert / update / update / update /update sequentie ( en dan nog het liefst met stored procedures )
4 . Bovenal als er geen geld is voor een nieuwe server en je client is krachtiger dan je server probeer dan meer werk bij de client neer te leggen. Je server trekt het niet

donderdag 15 juni 2006 09:34

Acties:

donderdag 15 juni 2006 10:05

Software Architect

Werkt hier

megamuch schreef op donderdag 15 juni 2006 @ 02:07:
Waarvoor dient de Log file size. Heb ik die wel nodig? Wil ik wel een log? Dat kost disk i/o. Of is dat gewoon vanwege de transaction support in InnoDB om rollbacks uit te voeren? In dit geval wil ik helemaal geen transaction support. Het gaat me meer om de row level locking. Kan ik dat flushen dus helemaal achterwege laten?

Logs zijn inderdaad nodig voor transacties. Maar vergeet niet dat transacties nodig zijn voor atomical handelingen. Als jij een record insert, dan wil je toch wel zeker weten dat ie ook in je database staat?
Door de transactionele werking van innodb heb je die zekerheid, bij myisam is die zekerheid er niet. Als je DB precies tijdens het schrijven van een record crasht is het maar de vraag of je tabelbestanden daarna uberhaupt nog leesbaar zijn, bij innodb ben je alleen dat ene record kwijt als ie nog niet volledig in de log was opgenomen en start ie daarna weer vrolijk op.
Maar het kunnen bepalen of een specifieke row gewijzigd was etc etc is ook weer iets dat er op leunt danwel mee samenhangt.

Het is dus niet of-of, maar en-en, het hangt te veel samen om een deel uit te kunnen schakelen.

In theorie is het ook zo dat door logging de schrijfoverhead op de tabel zelf af kan nemen omdat ie minder afhankelijk van willekeur is en zelf een leuke schrijfvolgorde kan bedenken en/of verschillende operaties samen kan pakken. Maar ik weet niet in hoeverre mysql van dat soort dingen gebruik kan maken.

Laatste vraag: iemand een goeie applicatie om sql te testen gevonden? (dus niet de standaard perl sql bench).

Apache's jmeter heeft wel aardige functionaliteit, maar of het doet wat je wil is natuurlijk maar de vraag

Acties:

donderdag 15 juni 2006 23:04

Security!

Ik heb ook een redelijk rappe logging database om de standaard logs te vervangen met gerelationele equivalent als extra tool.

Ik gebruik de strategie om de informatie op te breken in kleine elementen (aparte tabellen) die de varchars vasthouden die steeds worden hergebruikt/naar wordt verwezen van de snel-lopende tabellen. Deze kleine maar veel geupdate tabellen bevatten alleen de prikeys van de andere tabellen, waardoor de insert snelheid minimaal is en het selecteren van de juiste keys vooral vanuit de cache kan worden gedaan op de server.

Dus, de clients lezen selecteren hun benodigde informatie uit de aanwezige records en gaan vervolgens alleen de keys en een datetime veld inserten in de snellopende tabellen. Zo bedien ik 15 tabellen met 3 snellopende en smalle tabellen.
Ik heb hiermee o.a. de updates zoveel mogelijk vermeden. Het is sneller om een insert te doen dan een update, omdat je dan eerst moet zoeken naar de where clause info en dan de update doorvoeren en je krijgt je concurrency problemen.
Bij een insert heb je dat minder, omdat je dan de data invoert en als je goed doet dan is die actie gegarandeerd en met zo min mogelijk concurrent informatie.
Ik denk in mijn hoofd altijd maar eenvoudig zo:
select: 1 read I/O (kan eenvoudig uit de cache, geen concurrent probleem, hoog uit een dirty read)
insert: 1 write I/O (mits alleen values worden geinsert en het geen select in zich heeft, want dan zie update, weinig concurrent problemen, als die er staat, staat die er, als je record er niet staat, staat die er nog niet (sterk afhankelijk van je data model!)
update: 1 read I/O plus 1 write I/O (van cache als je geluk heb, write naar cache met concurrent problemen).

Dat scheelt je database server een hoop geknutsel met locking en dat soort dingen. De transacties lopen dan makkelijker door.

I've visited the Mothership @ Cupertino

Acties:

MSalters

megamuch schreef op donderdag 15 juni 2006 @ 02:07:
[...]
Jep, nu 8 systemen, volgende week 11 en eind vd maand wellicht al 15 systemen.

Tijdsdruk is de #1 reden om geld uit te geven. Jouw een maand laten denken is waarscjinlijk duurder, zoals ik al eerder zei, maar in dit geval is er dus een nog groter nadeel: tegen die tijd moet je èn meer hardware èn een slimmere oplossing hebben. Begin dus nu met de snelle hardware, dan heb je alvast een mand tijd gekocht, en het enige verschil is een maand rente op een par duizend euro. Centenwerk dus.

Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein

donderdag 15 juni 2006 23:19

Acties:

BtM909

Watch out Guys...

Hoe kom jij eigenlijk op 1200 records p/s ?

En in mijn beleving (en ervaring

) heb je ook een serieus butt-systeem als die niet efficient met de gegevens om kan gaan en je dus database data nodig hebt om de rest van je onderdelen te laten functioneren.

Call informatie hoort gewoon netjes na het afronden weggeschreven te worden

Just mijn 2 offtopic cents

[ Voor 10% gewijzigd door BtM909 op 15-06-2006 23:20 ]

Ace of Base vs Charli XCX - All That She Boom Claps (RMT) | Clean Bandit vs Galantis - I'd Rather Be You (RMT)
You've moved up on my notch-list. You have 1 notch
I have a black belt in Kung Flu.

donderdag 15 juni 2006 23:39

Acties:

Verwijderd

Weet niet precies hoever je met MySql kan gaan, maar voor optimale performance kan je het beste

meest gebruikte tabellen op aparte schijven opslaan
indices op aparte schijven (ja meest gebruikte ook weer apart)
logs apart

zorgen dat je een systeem hebt dat idle time gebruikt om zaken weg te schrijven (background writers)

ideaal zou zijn iedere tabel, iedere index op aparte schijf (raid dan). Maar dit is meestal niet te doen, dus indelen volgens schatting of via statische gegevens uit gebruik van db.

Misschien is MySql gewoon niet de goede oplossing voor dit probleem.
Wil je niks door de "strot" duwen, maar lees hier eens b.v.:
http://www.progress.com/realtime/products/index.ssp

donderdag 15 juni 2006 23:58

Acties:

BCC

Gomez12 schreef op donderdag 15 juni 2006 @ 03:00:
[...]

Stap af van autoinc velden, maak 1 tabel extra aan genaamd counters. Per client 1 row

Inderdaad, of iets van receivingMachine, datetimestamp als key.

Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.

vrijdag 16 juni 2006 02:34

Acties:

vrijdag 16 juni 2006 07:23

Tring Tring!

Topicstarter

BtM909 schreef op donderdag 15 juni 2006 @ 23:19:
Hoe kom jij eigenlijk op 1200 records p/s ?

En in mijn beleving (en ervaring ) heb je ook een serieus butt-systeem als die niet efficient met de gegevens om kan gaan en je dus database data nodig hebt om de rest van je onderdelen te laten functioneren.

Call informatie hoort gewoon netjes na het afronden weggeschreven te worden

Just mijn 2 offtopic cents

1200 recs p sec is gemeten met mysql adminstrator op full load. Op dit moment als de systemen helemaal vol zitten, is dit de load. Bij 4 sytemen was de load dus ook 600 recs p sec en dat trok die machine dus prima. Echter met 8 systemen merk je dat er te traag info terug komt en er teveel gewacht moet worden op info uit de DB.

Wat betreft butt systeem: ik neem je niets kwalijk, maar ik denk niet dat je in dit geval er echt over kan oordelen. Ik heb niet alle info gegeven, mede omdat ik ook aan een bepaalde descreetheid gebonden ben.

Overigens is er vandaag gesproken over een upgrade voor de mysql machine.

De nieuwe setup wordt waarschijnlijk een dual amd/intel 3ghz, 2gb met scsi 320 schijf en een 32 mb scsi controller. Even kijken hoe of wat met warmte / kast ruimte etc. Waarschijnlijk zo'n HP machientje. We zijn nog aan het kijken naar oplossingen met raid 10, raid 5(0) of gewoon dual uitvoering op raid 0 (dus 2 van die HP dingen dan dus in een mysql cluster). Voor wat betreft de table partitioning en de keuze tussen innodb en myisam, zijn we nog niet helemaal zeker. Myisam is gewoon rete snel. InnoDB wellicht met de juiste config ook, maar levert tot nu toe een veel hogere load op. En dat blijft vreemd, zeker vanwege de 'simpelheid' van de queries. (Denk "select bla from bla where foo=bar", "update bla set woei=meeh" replace into bladiebla etc).

Betrouwbaar is MyIsam ook (of iig in deze situatie), en als ie eruit klapt, dan is dat met replication en clustering ook wel weer op te lossen.

Morgen even een test draaien op 4 machines met een mysql cluster en kijken hoe dat reageert op node failure, heavy load, network traffic etc. Wie weet levert dat nog bruikbare info op.

MSalters schreef op donderdag 15 juni 2006 @ 23:04:
[...]

Tijdsdruk is de #1 reden om geld uit te geven. Jouw een maand laten denken is waarscjinlijk duurder, zoals ik al eerder zei, maar in dit geval is er dus een nog groter nadeel: tegen die tijd moet je èn meer hardware èn een slimmere oplossing hebben. Begin dus nu met de snelle hardware, dan heb je alvast een mand tijd gekocht, en het enige verschil is een maand rente op een par duizend euro. Centenwerk dus.

Neuh ik ben gratis

Ik ben tijdelijk in .nl voor andere dingen en help wat oude collega's met perfomance problemen.

Om nog even terug te komen op de hoeveel datatraffic er naar die machine toegaat / vanafkomt. We komen niet boven de 1.5 mbit uit dus dat valt wel mee.

Verstand van Voip? Ik heb een leuke baan voor je!

Acties:

vrijdag 16 juni 2006 09:20

Software Architect

Werkt hier

megamuch schreef op vrijdag 16 juni 2006 @ 02:34:
Betrouwbaar is MyIsam ook (of iig in deze situatie), en als ie eruit klapt, dan is dat met replication en clustering ook wel weer op te lossen.

De missende betrouwbaarheid (niet voldoen aan ACID) los je daar niet mee op. Bovendien wordt de schrijfperformance niks beter met replication, in theorie zelfs slechter! Mysql's NDB-clustering is een rare, die doet namelijk alles in-memory... snel, maar erg beperkend.

Acties:

Verwijderd

Verwijderd schreef op donderdag 15 juni 2006 @ 23:39:
Weet niet precies hoever je met MySql kan gaan, maar voor optimale performance kan je het beste

meest gebruikte tabellen op aparte schijven opslaan
indices op aparte schijven (ja meest gebruikte ook weer apart)
logs apart

Deze stelling gaat hier natuurlijk niet helemaal op. Er is maar 1 meest gebruikte tabel

MSSQL en Oracle bijvoorbeeld kunnen zo'n tabel horizontaal partioneren over meerdere bestanden/schijven, maar weet niet of MySQL dat kan (denk het niet).

vrijdag 16 juni 2006 09:51

Acties:

vrijdag 16 juni 2006 12:19

Security!

Ik neem aan dat je ook wel bekent ben met het probleem van sommige select statements, dat die vereisen dat de hele tabel van begin tot eind worden gefetched en gelezen op het moment dat je iets vraagt wat niet geindexeerd is.

Al dit soort vertragende dingen moet je na gaan en proberen op te lossen. Ik denk dat stap #1 de snellere hardware is, want het is duidelijk dat je dat wilt hebben.
Stap #2 wordt in rust en met wat tijd nagaan waar je nog meer optimalisatie kan scoren in je data model.
Als je bereid bent om een MySQL cluster op te zetten ivm financiele voorspoed, dan zou ik zeggen, koop je oplossing, maar kijk uit voor schalingsproblematiek.

I've visited the Mothership @ Cupertino

Acties:

djc

Ik zou trouwens als je toch een dikke server gaat kopen eens kijken naar die nieuwe Sun-bakken. Voor bepaalde threaded applicaties schijnen die verdomd hard te kunnen werken. Zie dit leuke stukje.

Rustacean

vrijdag 16 juni 2006 13:09

Acties:

vrijdag 16 juni 2006 14:12

Software Architect

Werkt hier

Manuzhai schreef op vrijdag 16 juni 2006 @ 12:19:
Ik zou trouwens als je toch een dikke server gaat kopen eens kijken naar die nieuwe Sun-bakken. Voor bepaalde threaded applicaties schijnen die verdomd hard te kunnen werken. Zie dit leuke stukje.

Zijn toepassing is helemaal niet zo parallell (ivt een ftp of http-service)... Steeds in dezelfde tabel schrijven, in de zelfde indexen data bijwerken, etc...

Bovendien is MySQL in mijn persoonlijke ervaring ook niet zo geweldig schaalbaar naar meerdere cpu of cores. Ik kan vooralsnog hierover niets toelichten, maar voor MySQL zou ik met het huidige aanbod van systemen niet zo gauw iets anders dan een Opteron overwegen. De T2000 is een mooie machine, maar beperkt toepasbaar en dan vooral bij situaties die echt goed schalen naar meerdere cpu's. MySQL (zelfs de laatste beta's) hebben daar nog aardig wat moeite mee. Bovendien is zo'n T2000 behoorlijk prijzig.

Acties:

maandag 19 juni 2006 02:11

Tring Tring!

Topicstarter

ACM schreef op vrijdag 16 juni 2006 @ 07:23:
[...]

De missende betrouwbaarheid (niet voldoen aan ACID) los je daar niet mee op. Bovendien wordt de schrijfperformance niks beter met replication, in theorie zelfs slechter! Mysql's NDB-clustering is een rare, die doet namelijk alles in-memory... snel, maar erg beperkend.

Replication is natuurlijk langzamer, maar op 2x (of meer) een dual 3ghz machine met genoeg ram maakt die performance hit dan ook weer niet zo heel veel uit.

NDB is idd in memory, maar is op te lossen door dagtabellen aan te maken en die bij load < 5% weg te schrijven naar disk. (bijvoorbeeld).

ACID is vaak erg belangrijk. In deze situatie valt dat echter wel mee. Er is nooit sprake van rollback situaties of interdependent queries. En mocht er 1 of 2 dingen niet danwel verkeerd gaan, dan is dat op een totaal resultaat geen ramp. En ik heb nog wel het vertrouwen in MySQL dat bij het falen van een update insert ik ook een mooie error terug krijg. Snelheid en failover zijn in dit geval het belangrijkste.

Verstand van Voip? Ik heb een leuke baan voor je!

Acties:

Verwijderd

megamuch schreef op vrijdag 16 juni 2006 @ 02:34:
[...]

De nieuwe setup wordt waarschijnlijk een dual amd/intel 3ghz, 2gb met scsi 320 schijf en een 32 mb scsi controller. Even kijken hoe of wat met warmte / kast ruimte etc. Waarschijnlijk zo'n HP machientje. We zijn nog aan het kijken naar oplossingen met raid 10, raid 5(0) of gewoon dual uitvoering op raid 0 (dus 2 van die HP dingen dan dus in een mysql cluster).

Ik heb een 2-tal jaren het os-beheer voor een grote (+-100GB) database machine gedaan,
en voor de read/write throughput bleek meer disken vooral van belang te zijn.
en als ik het verhaal goed begrepen heb dan is dat je grootste bottleneck.

Mijn bevindingen van het tunen wat ik toen heb gedaan:
- Een raid 0 of 10 met veel disken levert meer throughput op dan cpu upgrades
- raid 5 is niet aan te raden vanwege de extra reads die nodig zijn voor de parity berekeningen (tenzij je een grote 128MB+ cache op je scsi controller hebt)
- software raid of hardware raid maakt niet zoveel uit als je genoeg cpu power hebt tenzij je raid 5 gebruikt (zie vorig punt)
- meer kleinere disken werkt beter dan minder grotere
- TCQ is een must
- database transactie logs altijd fysiek apart op de snelste schijf die je redelijkerwijs kan betalen

ik ben toen uitgekomen op een gemirrorde raid 5 voor de data en een raid1 van 2 schijven voor het transactie log, en dat liep als een speer
(SSA is

speelgoed

)

[ Voor 10% gewijzigd door Verwijderd op 19-06-2006 02:25 ]

maandag 19 juni 2006 23:04

Acties:

JaQ

ACM schreef op vrijdag 16 juni 2006 @ 13:09:
[...]
Bovendien is MySQL in mijn persoonlijke ervaring ook niet zo geweldig schaalbaar naar meerdere cpu of cores. Ik kan vooralsnog hierover niets toelichten, maar voor MySQL zou ik met het huidige aanbod van systemen niet zo gauw iets anders dan een Opteron overwegen. De T2000 is een mooie machine, maar beperkt toepasbaar en dan vooral bij situaties die echt goed schalen naar meerdere cpu's. MySQL (zelfs de laatste beta's) hebben daar nog aardig wat moeite mee. Bovendien is zo'n T2000 behoorlijk prijzig.

Er zijn bekende bugs met MySQL en multi threads, een T2000 gaat je hierdoor dus minder performance leveren dan een leuke AMD. De T2000 wordt niet voor niets geprezen als webserver (en dus niet als database server). Een verkoper bij Sun zal je dit overigens ook meteen vertellen (en vervolgens proberen een AMD te slijten

)

Als ik het hele verhaal zo doorlees kan ik enkel concluderen dat IO je bottleneck is. Dit moet te meten zijn vanaf het OS (iostat al geprobeerd?) Je meeste tijd zal verloren gaan in updates (daar is MySQL notoir slecht in). Probeer deze dus zoveel mogelijk te voorkomen. Verder is het wellicht interessant om naar "load data" te kijken (dus niet met insert statements werken). Ik ken daar zelf geen performance cijfers van, maar het lijkt me wel de manier [zie hier).

Egoist: A person of low taste, more interested in themselves than in me

maandag 19 juni 2006 23:10

Acties:

DJ Buzzz

Ik weet niet in hoeverre het mogelijk is, maar kijk iig naar het volgende:

Gebruik REPLACE INTO, zeker als je voor de query niet weet of je een UPDATE of INSERT moet doen. Maakt het wel MySQL only, maar goed, dat is in gevallen zoals deze niet echt een probleem lijkt me.

Cache op applicatie niveau b.v. een stuk of 100 queries en voer deze vervolgens uit in 1 INSERT INTO tbl_name (a,b,c) VALUES(1,2,3),(4,5,6),(7,8,9); achtige statement. Dit schaalt erg hard, maar vereist dus wel b.v. meer memory.

Ik heb zo niet meer de test resultaten die ik in een project behaald heb met deze tweaks, maar het is denk ik het zeker waard om even naar te kijken.

maandag 19 juni 2006 23:20

Acties:

CH4OS

It's a kind of magic

Is het niet gewoon mogelijk, om eerst je insert query te doen... En daarna (na een gesprek) 1 update query los te laten? Je kan immers bij je insert query bijvoorbeeld de starttijd alvast invullen, maar ook de gebruiker, het telefoonnummer, etcetera. Dan hoef je aan het eind van een telefoon gesprek nog maar 1 update te doen en dat is die van de eindtijd en de lengte (alhoewel je die kan berekenen, je hebt immers een begintijd en een eindtijd, met een timestamp kan je dan toch zo berekenen hoe lang iemand gebelt heeft?

Denk dat je daarmee je aantal queries (per seconde) ook heel erg goed weet te verminderen...

1200 queries per seconde klinkt mij namelijk in de oren alsof je een DB backup wilt terug zetten of iets dergelijks... Hoe wil je (imo) anders aan 1200 queries per seconde komen?

Kan me niet voorstellen dat je 1200 telefoontjes (als ik het topic zo lees) per seconde krijgt...
Ik wil niet zeggen dat het niet mogelijk is, het lijkt me alleen wat onwaarschijnlijk
Als dit het geval is, gaat de eerste alinea natuurlijk niet (meer) op

[ Voor 46% gewijzigd door CH4OS op 19-06-2006 23:26 ]

dinsdag 20 juni 2006 09:42

Acties: