BerkeleyDB Concurrency

hlasů
25
  • Jaký je optimální úroveň souběžnosti, že C ++ implementace BerkeleyDB lze rozumně podpořit?
  • Kolik vláken může jsem zatloukat dál na DB před propustnost začne trpět kvůli sváru zdrojů?

Četl jsem návod a vědět, jak nastavit počet zámků, skříňky, databáze velikost stránky, atd, ale Jen bych radu od někoho, kdo má v reálném světě zkušenosti s BDB souběžnosti.

Moje aplikace je velmi jednoduchá, budu dělat dostane a klade záznamů, které jsou o 1 kB každého. Žádné kurzory, bez mazání.

Položena 02/08/2008 v 00:28
zdroj uživatelem
V jiných jazycích...                            


5 odpovědí

hlasů
10

Záleží na tom, jaký druh aplikací stavíte. Vytvořit reprezentativní testovací scénář, a začít klepání pryč. Pak budete znát definitivní odpověď.

Vedle vašeho use case, ale také záleží na CPU, paměť, front-side sběrnice, operační systém, nastavení vyrovnávací paměti a tak dále.

Vážně, prostě vyzkoušet svůj vlastní scénář.

Potřebujete-li některá čísla (které ve skutečnosti může znamenat nic váš scénář):

Odpovězeno 03/08/2008 v 13:34
zdroj uživatelem

hlasů
7

Já rozhodně souhlasím s Daan je místo: vytvořit testovací program a ujistěte se, že způsob, jakým přistupuje k datům napodobuje co nejvěrněji vzory, které očekáváte aplikace mít. To je nesmírně důležité s BDB, protože různé vzory přístupová získá úplně jiný výkon.

Jiné, než to, že se jedná o obecné faktory nalezené I, které mají zásadní vliv na propustnost:

  1. Metoda Access (což ve vašem případě myslím, že je b-stromě).

  2. Stupeň perzistence, se kterou nakonfigurován DBD (například v mém případě prostředí flag dále jen ‚DB_TXN_WRITE_NOSYNC‘ zlepšený výkon psát o řád, ale kompromituje perzistenci)

  3. Má pracovní set vejde do vyrovnávací paměti?

  4. Počet Čte Vs. Píše.

  5. Jak rozložit váš přístup je (nezapomeňte, že btree má uzamykání na úrovni stránky - tak přístup k různým stránky s různými závity je velkou výhodu).

  6. Přístup pattern - meanig s jakou pravděpodobností jsou vlákna, která zamyká se navzájem, nebo dokonce na mrtvém bodě, a jaká je vaše řešení zablokování policy (ten může být vrah).

  7. Hardware (disk a paměť pro vyrovnávací paměť).

To představuje následující bod: škálování řešení založené na DBD tak, že nabízí větší souběžnost má dva hlavní způsoby, jak jít o tom; buď minimalizovat počet zámků ve své konstrukci nebo přidat další hardware.

Odpovězeno 13/10/2008 v 22:59
zdroj uživatelem

hlasů
4

Není to závislé na hardware, stejně jako počet vláken a tak?

Chtěl bych udělat jednoduchý test a spusťte jej s rostoucím množstvím nití jako kladivo a uvidíme, co se zdá nejlepší.

Odpovězeno 02/08/2008 v 19:21
zdroj uživatelem

hlasů
2

Jak jsem pochopit věci, Samba vytvořené TDB , aby „více souběžných spisovatelé “ pro konkrétní databázový soubor. Takže pokud vaše pracovní vytížení má více spisovatelé váš výkon může být špatná (stejně jako v Projekt Samba rozhodl se napsat svůj vlastní systém, zřejmě proto, že nebyl spokojen s výkonem Berkeley DB je v tomto případě).

Na druhou stranu, pokud vaše pracovní vytížení má spoustu čtenářů, pak je otázkou, jak dobře je váš operační systém zpracovává více čtenářů.

Odpovězeno 16/09/2008 v 18:31
zdroj uživatelem

hlasů
1

Co jsem při práci s databází neznámého výkonu bylo změřit čas obrátky na mé dotazy. Pořád jsem upping počet závitů až turn-around time klesla a klesá počet vláken, dokud zlepšila obrat kolem času (no, bylo to děje v mém prostředí, ale co).

Tam byly klouzavé průměry a všechny druhy metrik zúčastněných, ale take-away lekce byla: stačí přizpůsobit, jak věci fungují v současné době. Nikdy nevíte, kdy se DBA zlepší výkon nebo hardware bude aktualizována, nebo možná jiný proces bude přijdou načíst dolů systému, když vedete. Tak přizpůsobit.

Jo, a ještě jedna věc: vyhnout se proces přepne, pokud je to možné - šarže věci.


Oh, měl bych, aby to jasné: to vše se stalo v době běhu, a to v průběhu vývoje.

Odpovězeno 04/08/2008 v 08:45
zdroj uživatelem

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