BerkeleyDB Concurrency

stemmen
25
  • Wat is het optimale niveau van concurrency dat de C ++ implementatie van BerkeleyDB redelijkerwijs kan ondersteunen?
  • Hoeveel threads kan ik hameren op het DB voor doorvoer begint te lijden als gevolg van bronnenconflict?

Ik heb de handleiding te lezen en weten hoe het aantal sluizen, kluisjes, database paginagrootte, etc. ingesteld, maar ik zou graag wat advies van iemand die heeft real-world ervaring met BDB concurrency.

Mijn toepassing is vrij eenvoudig, ik zal doen krijgt en zet records die ongeveer 1 kB per stuk. Geen cursors, niet verwijderen.

De vraag is gesteld op 02/08/2008 om 00:28
bron van user
In andere talen...                            


5 antwoorden

stemmen
4

Betekent dit niet afhankelijk van de hardware als aantal draden en zo?

Ik zou een eenvoudige test te maken en voer het uit met toenemende hoeveelheden van draden hameren en te zien wat het beste lijkt.

antwoordde op 02/08/2008 om 19:21
bron van user

stemmen
10

Het hangt af van wat voor soort applicatie u bouwt. Maak een representatieve testscenario, en start hameren. Dan zult u het definitieve antwoord te weten.

Naast uw use case, het hangt ook af van de CPU, geheugen, front-side bus, het besturingssysteem, cache-instellingen, etcetera.

Serieus, gewoon test je eigen scenario.

Als je een aantal nummers nodig (dat kan eigenlijk niets in uw scenario bedoel):

antwoordde op 03/08/2008 om 13:34
bron van user

stemmen
1

Wat ik deed bij het werken met een database van onbekende prestatie was om doorlooptijd op mijn vragen te meten. Ik bleef upping de draad tellen tot turn-around tijd gedaald, en het schrappen van de draad tellen tot turn-around tijd verbeterd (nou ja, het was processen in mijn omgeving, maar wat dan ook).

Er waren voortschrijdende gemiddelden en allerlei metrics betrokken, maar de take-away les was: gewoon aanpassen aan hoe de dingen werken op dit moment. Je weet nooit wanneer de DBA prestaties zullen verbeteren of hardware zal worden opgewaardeerd, of misschien een ander proces zal langs komen om te down loaden het systeem, terwijl je draait. Zo passen.

Oh, en een ander ding: vermijd proces schakelt als je kunt - batch dingen.


Oh, ik moet dit duidelijk maken: dit alles gebeurde tijdens de uitvoering, niet tijdens de ontwikkeling.

antwoordde op 04/08/2008 om 08:45
bron van user

stemmen
2

De manier waarop ik dingen te begrijpen, Samba gemaakt tdb naar "meerdere gelijktijdige toestaan schrijvers " voor een bepaald databasebestand. Dus als uw werk heeft meerdere schrijvers uw prestaties kan slecht zijn (zoals in het Samba-project ervoor gekozen om een eigen systeem te schrijven, blijkbaar omdat hij niet tevreden was met de prestaties van Berkeley DB's in dit geval).

Aan de andere kant, als uw werk heeft veel lezers, dan is de vraag hoe goed uw besturingssysteem omgaat met meerdere lezers.

antwoordde op 16/09/2008 om 18:31
bron van user

stemmen
7

Helemaal mee eens punt Daan's: maak een testprogramma, en zorg ervoor dat de wijze waarop zij toegang tot gegevens bootst zo dicht mogelijk de patronen die u verwacht dat uw aanvraag te hebben. Dit is uiterst belangrijk bij BDB omdat verschillende toegangspatronen leveren zeer verschillend debiet.

Anders dan dat, deze zijn algemene factoren vond ik van grote invloed op de doorvoer te zijn:

  1. Toegang methode (die in uw geval is denk ik btree).

  2. Niveau van persistentie waarmee je DBD geconfigureerd (bijvoorbeeld, in mijn geval de 'DB_TXN_WRITE_NOSYNC' omgeving vlag verbeterde schrijfprestaties door een orde van grootte, maar het compromissen persistentie)

  3. Is de werking te stellen fit in de cache?

  4. Aantal Leest Vs. Schrijft.

  5. Hoe verspreid uw toegang is (vergeet niet dat btree heeft een pagina-niveau vergrendeling - dus de toegang verschillende pagina's met verschillende draden is een groot voordeel).

  6. Toegang patroon - meanig hoe groot de kans zijn discussies met elkaar te vergrendelen, of zelfs impasse, en wat is uw impasse resolutie beleid (dit kan een killer zijn).

  7. Hardware (schijf en geheugen cache).

Dit komt neer op het volgende punt: schalen van een oplossing op basis van DBD, zodat het biedt een grotere concurrency heeft twee belangrijke manieren te gaan over; ofwel het minimaliseren van het aantal sloten in uw ontwerp of voeg meer hardware.

antwoordde op 13/10/2008 om 22:59
bron van user

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more