Berkeley DB Samtidighet

stemmer
26
  • Hva er det optimale nivået av samtidighet at C ++ gjennomføring av Berkeley DB rimelighet kan støtte?
  • Hvor mange tråder kan jeg hamrer løs på DB før gjennomstrømming begynner å lide på grunn av ressurskonflikter?

Jeg har lest manualen og vet hvordan du angir antall låser, skap, database sidestørrelse, osv, men jeg bare liker noen råd fra noen som har praktisk erfaring med BDB samtidighet.

Søknaden min er ganske enkel, jeg skal gjøre får og setter av poster som er i ferd 1 kB hver. Ingen pekere, ingen sletting.

Publisert på 01/08/2008 klokken 23:28
kilden bruker
På andre språk...                            


5 svar

stemmer
12

Det avhenger av hva slags program du bygger. Lag en representant testscenario, og begynner å hamre løs. Da vil du kjenne den definitive svar.

Foruten bruken tilfelle, det avhenger også av CPU, minne, front-side bus, operativsystem, cache innstillinger, etcetera.

Seriøst, bare teste din egen scenario.

Hvis du trenger noen tall (som faktisk kan bety noe i ditt scenario):

Svarte 03/08/2008 kl. 12:34
kilden bruker

stemmer
7

Jeg er helt enig med Daan poeng: opprette et testprogram, og sørg for at den måten som det åpner dataligner så tett som mulig mønstrene du forventer søknaden din skal ha. Dette er ekstremt viktig med BDB fordi ulike aksessmønstre gi svært forskjellig gjennomstrømming.

Annet enn det disse er generelle faktorer jeg funnet å være av stor betydning for gjennomløp:

  1. Tilgangsmetode (som i ditt tilfelle jeg antar er BTREE).

  2. Nivå av utholdenhet som du konfigurert DBD (for eksempel i mitt tilfelle 'DB_TXN_WRITE_NOSYNC' miljø flagget forbedret skriveytelsen av en størrelsesorden, men det kompromisser utholdenhet)

  3. Har arbeids satt passer i cache?

  4. Antall Leser Vs. Skriver.

  5. Hvordan spre ut tilgang (husk at BTREE har en side nivå låsing - så tilgang til forskjellige sider med forskjellige tråder er en stor fordel).

  6. Tilgang mønster - meanig hvor sannsynlig er tråder for å låse hverandre, eller fastlåst, og hva er din vranglås oppløsning politikk (dette kan være en killer).

  7. Hardware (disk og minne for cache).

Dette beløper seg til følgende punkt: Skalering en løsning basert på DBD slik at det gir større samtidighet har to viktige måter å gå om det; enten redusere antall sluser i design eller legge til mer maskinvare.

Svarte 13/10/2008 kl. 21:59
kilden bruker

stemmer
5

Betyr ikke dette være avhengig av maskinvare, samt antall tråder og sånt?

Jeg ville gjøre en enkel test og kjøre den med økende mengder av tråder hamring og se hva som virker best.

Svarte 02/08/2008 kl. 18:21
kilden bruker

stemmer
2

Slik jeg forstår ting, Samba opprettet TDB å tillate "flere samtidige forfattere " for en bestemt databasefilen. Så hvis arbeidsmengden har flere forfattere ytelsen kan være dårlig (som i, valgte Samba-prosjektet til å skrive sitt eget system, angivelig fordi det ikke var fornøyd med Berkeley DB prestasjoner i dette tilfellet).

På den annen side, hvis arbeidsmengden har mange lesere, så spørsmålet er hvor godt operativsystemet håndterer flere lesere.

Svarte 16/09/2008 kl. 17:31
kilden bruker

stemmer
2

Det jeg gjorde når du arbeider mot en database av ukjent ytelsen var å måle behandlingstid på mine spørsmål. Jeg holdt upping tråden telle til turn-around tid falt, og slippe tråden telle til turn-around tid forbedret (vel, det var prosesser i mitt miljø, men uansett).

Det var glidende gjennomsnitt og alle slags beregninger som er involvert, men take-away leksjon var: bare tilpasse seg hvordan ting fungerer i øyeblikket. Du vet aldri når DBA vil forbedre ytelsen eller maskinvare vil bli oppgradert, eller kanskje en annen prosess vil komme sammen for å laste ned systemet mens du kjører. Så tilpasse seg.

Oh, og en annen ting: unngå prosessen bytter hvis du kan - batch ting opp.


Oh, jeg bør gjøre dette klart: dette skjedde under kjøring, ikke under utvikling.

Svarte 04/08/2008 kl. 07:45
kilden bruker

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