BerkeleyDB Concurrency

szavazat
25
  • Mi az optimális szintet konkurencia, hogy a C ++ végrehajtásának BerkeleyDB ésszerűen támogatják?
  • Hány szálak már kalapált el a DB előtt átmenő kezd szenvedni, mert az erőforrás állításával?

Olvastam a kézikönyvet, és tudja, hogyan kell beállítani a száma zárak, szekrények, adatbázis lapméret, stb, de én csak szeretném néhány tanácsot, aki már valós tapasztalat BDB konkurencia.

Az alkalmazás nagyon egyszerű, fogok csinálni jelentkeznek, és teszi a nyilvántartások, amelyek körülbelül 1 KB minden. Nem kurzorok, nincs törlés.

A kérdést 02/08/2008 00:28
a forrás felhasználó
Más nyelveken...                            


5 válasz

szavazat
4

Nem ez függ a hardvertől, valamint a szálak számát és a cucc?

Azt, hogy egy egyszerű tesztet, és futtassa növekvő mennyiségű szálat kalapált, és mi tűnik a legalkalmasabbnak.

Válaszolt 02/08/2008 19:21
a forrás felhasználó

szavazat
10

Ez attól függ, hogy milyen alkalmazást építesz. Hozzon létre egy reprezentatív vizsgálatot forgatókönyv, és indítsa kalapált el. Akkor megtudjátok a végleges választ.

Ezt a használati eset, ez attól is függ CPU, memória, FSB, operációs rendszer, cache beállításait, satöbbi.

Komolyan, csak teszt a saját forgatókönyv.

Ha szüksége van néhány szám (amely tulajdonképpen semmit sem jelent a forgatókönyv):

Válaszolt 03/08/2008 13:34
a forrás felhasználó

szavazat
1

Amit tettem, amikor dolgozik egy adatbázissal ismeretlen teljesítmény mérése volt az átfutási idő az én lekérdezés. Tartottam sűríti szálat, amíg fordulási idő csökkent, és vidd szálat, amíg fordulási idő javult (nos, ez volt folyamatok a környezetemben, de mindegy).

Voltak mozgó átlagok és mindenféle mutatók részt, de az elvitelre lecke volt: csak alkalmazkodni a dolgok hogyan működnek az adott pillanatban. Soha nem lehet tudni, ha a DBA javítja a teljesítményt vagy a hardver lesz frissíthető, vagy esetleg egy másik folyamat, jön betölteni a rendszert, miközben futsz. Tehát alkalmazkodni.

Ja, és még egy dolog: elkerülni folyamat kapcsol, ha tudsz - batch dolgokat.


Ó, ezt világossá kell tenni: ez az egész történt futás közben, nem a fejlesztés során.

Válaszolt 04/08/2008 08:45
a forrás felhasználó

szavazat
2

Ahogy én értelmezem a dolgokat, Samba létre TD , hogy „több egyidejű írók ” bármely adott adatbázis fájlt. Tehát, ha a terhelés több olyan írók a teljesítményt lehet rossz (mint a Samba projekt úgy döntött, hogy írjon a saját rendszere, nyilvánvalóan azért, mert nem volt elégedett a Berkeley DB teljesítménye ebben az esetben).

Másrészt, ha a terhelés rengeteg olvasó, akkor a kérdés az, hogy mennyire jól az operációs rendszer kezeli a több olvasók.

Válaszolt 16/09/2008 18:31
a forrás felhasználó

szavazat
7

Határozottan egyetértek Daan szempontjából: hozzon létre egy tesztprogram, és győződjön meg arról, hogy milyen módon hozzáfér adatok utánozza a lehető legszorosabban a minták vársz az alkalmazás, hogy van. Ez rendkívül fontos a BDB, mert a különböző hozzáférési mintákat, így nagyon különböző teljesítményt.

Más, mint, hogy ezek általános tényezők találtam, hogy jelentős hatást gyakorol áteresztőképességű:

  1. Hozzáférési mód (amely az Ön esetében azt hiszem van B-fán alapuló).

  2. Szintű perzisztencia, amellyel beállította DBD (például az én esetemben a „DB_TXN_WRITE_NOSYNC” környezet zászló javított írási teljesítmény egy nagyságrenddel, de ez veszélyezteti perzisztencia)

  3. Vajon az üzemi beállított illeszkedik cache?

  4. Olvasás számát Vs. Írja.

  5. Hogyan terjedt el a hozzáférés (ne feledjük, hogy B-fán alapuló egy oldal szintű zárolást - így betekintés a különböző oldalakon a különböző szálak egy nagy előny).

  6. Access minta - meanig milyen valószínűséggel szálak zár egymással, vagy akár holtpont, és mi a patthelyzet indítvány politika (ez lehet egy gyilkos).

  7. Hardver (lemez és memória cache).

Ez az összeg a következő ponttal: Méretezés alapuló megoldást DBD, hogy nagyobb teret konkurencia két fő módon is róla; vagy számának minimalizálása zár a tervezési vagy még több hardvert.

Válaszolt 13/10/2008 22:59
a forrás felhasználó

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