Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Magvas gondolatok

628 views

Published on

Mire használjuk a magokat, ha már úgy is vannak? A több szálú adatfeldolgozás architekturális problémái.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Magvas gondolatok

  1. 1. Scheidler Balázs “Magvas gondolatok”
  2. 2. Tartalom•Párhuzamos programozás & SMP•Memória & Cache•Valós tapasztalatok•Tipikus problém & trade-off•Konkrét adatszerkezet gyorsítása
  3. 3. Párhuzamos programozás•Több szálú futás•Közös memória•Közös állapottér (nyitott fájlok, hálózati kapcsolatok, stb)•Szálak közötti ütemezés az OS feladata•Több CPU/core transzparens használata
  4. 4. SMP•SMP = Symmetric Multiprocessing•Több CPU, közös memória, I/O tér•Minden CPU/core azonos típusú, órajelűű•Desktop gépekben, szervereken tipikus•Lehetnek specializált CPU-k, más rendszert futtatva
  5. 5. Memória•Jelenlegi CPU-k órajele a GHz tartományban•Egy utasítás végrehajtásához szükséges időő nanoszekundum nagyságrend•DRAM memória hozzáféréshez szükséges időő mikroszekundum nagyságrend (1:1000)•Ez megegyezik a memória/vinyó közti aránnyal!
  6. 6. CacheDRAM lassú, az SRAM drágaMegoldás: • kisebb, gyors cache memória • nagy, lassú központi memória • 1:1000 arány (méret és sebesség) • L1, L2, L3 szintek
  7. 7. Cache II.•A cache a CPU és a memória közti gyorsítótár•CPU által automatikusan menedzselt, program számára transzparens•Asszociatív tárolás, 32 byte-os egységekben („cacheline”)
  8. 8. Cache HatásaiEgy algoritmus lehet utasítás számban minimális ÉSLassabb, mint a több utasításból álló, de a cache-t hatékonyabban kihasználó változat.
  9. 9. Cache & SMP•Egy SMP rendszerben minden CPU/core külön cache-sel rendelkezik•Memória mindegyik CPU/core számára közös•Ugyanazon memória cím eléréséhez a CPU-k között kommunikációra van szükség
  10. 10. CPU-k közti szinkronizációMESI protokoll M E • Modified • Exclusive • Shared S I • Invalid local read local write remote read remote write
  11. 11. Kommunikáció HatásaiEgy látszólag egyszerűű műűvelethez mögött komplex lépések történnekA komplexitás időőbe kerülEgy memória műűvelet: • lehet 3 nagyságrenddel lassabb • függhet a CPU-k számától!
  12. 12. Tipikus cache probléma•2 processzor végez ugyanazon a cacheline-on felváltva atomikus write műűveletet (pl. egy lock) sch•A write műűvelet miatt mindkét CPU memóriából húzza be a cacheline-t, miközben a másik cache tartalmat invalidálja.•Aka. cache ping-pong
  13. 13. Valós tapasztalatok: syslog-ng
  14. 14. syslog-ng•Naplózó szerver, üzeneteket fogad TCP és UDP csatornákon•Egy üzenet egy sor•Minden sor kb 3-500 byte•~ ezer kapcsolat,•~ néhány száz ezer msg/sec
  15. 15. Mérés, reprodukció„Premature optimization is the root of all evil.” - Donald KnuthMérés és a reprodukálható testcase fontos! • ne kezdjünk bele nélküle • ismerjük meg az eszközeinket • perf, cachegrind, gprof
  16. 16. syslog-ng műűködéseBejövőő üzenetek feldolgozása: • beolvasás, parse-olás, szűűrés/módosítás, kiküldés egy outputraKimenőő üzenetek feldolgozása: • üzenet megformázása, kiírás egy fájlba/ hálózati kapcsolatra
  17. 17. syslog-ng korábban • 1 szál, poll() ciklus • minden esemény kezelése aszinkron callbackekkel • kb 100k msg/sec
  18. 18. syslog-ng ma•főő szál + worker threadek •Nonblocking I/O•a főő szál figyeli az összes nyitott •Worker threadek száma kapcsolatot (epoll), I/O esemény megegyezik a CPU-k esetén annak teljes feldolgozását számával átadja a worker threadnek •Egy taszk 1-4 msec időő•I/O események: alatt végez (1-4000 üzenet feldolgozása) •input adat érkezett (fetch, process, enqueue loop) •output írhatóvá vált (dequeue, format, write loop)
  19. 19. Szűűk keresztmetszetek, problémák
  20. 20. Thread váltásDrága, mert: • kihűűl a cache, • scheduler, • context switch: regiszterek, TLBElkerülés módja: • kevés thread (=CPU-k száma), nonblocking I/O • egy feladat kb. egy időőszeletig fut, se hosszabban, se rövidebben
  21. 21. KésleltetésA latency önmagában nem okoz CPU használatot, de • egy feldolgozásba beépülve okozhatja annak jelentőős lassulását • 1 msec késleltetés önmagában nem sok, de 1000 tranzakció esetén már 1 mp-cel nyújtja az időőt!Latency források: • lockok és szinkronizációs primitívek • OS események (epoll)
  22. 22. Dinamikus memóriamalloc/free jelentős időrablás 500k/sec tranzakciónál • threadek közti szinkronizáció • láncolt listák • tipikus: egyik szál lefoglal, másik felszabadítElkerülés módja: • alloca() ill. fixen méretezett változók • per-thread allokációk, hosszú távon megőőrizve, igény esetén növelve • LogMessage adatszerkezet „tömörítése”, ideális esetben 1 malloc/msg
  23. 23. Lock contentionTipikus cache ping-pong: • N szál ugyanazt a mutexet lockolja, egymást váltva • a reader-writer locknál és az atomikus referencia számlálónál is előőfordul!Cél: • egy egység hasznos munkára esőő szinkronizációs időő csökkentéseElkerülés módja: • per-thread változók • adatszerkezet módosítása, nagyobb felbontású mutexek használata • több munkát végzünk egy lock védelme alatt, ld. skálázható queue-k
  24. 24. A nem triviális költségek miatt egy szekvenciálisprogram párhuzamos változata gyakran lassabb lesz elsőő alkalommal.
  25. 25. Tipikus trade-off-okKonzisztencia, sorrendiség vs. sebesség • az abszolút sorrend sok szinkronizációt követel meg, ezek közül nem mind fontosHasznált memória mennyiség vs. sebesség • pl. per-thread változók, párhuzamos objektum példányok
  26. 26. Skálázható queueAz input és az output közti összekötést biztosítja: • input taszkok (N): beteszik az eseményeket • output taszk (1): kiveszi az eseményeket, majd kiküldi
  27. 27. Triviális megoldás
  28. 28. Mutex ...Üzenetenként 4 szinkronizációt igénylőő műűvelet (input/output x lock-unlock)
  29. 29. Hogyan lehetne javítani?
  30. 30. per-thread input queue ... Mutex ... ... ... ...Konzisztencia/memória vs. performanceAtomikus műűveletek száma kb felezőődik.
  31. 31. per-threadinput queue . Lockolatlan . . Mutex output queue . . ... . . . . . . . Atomikus műűveletek másik fele is nagyságrendekkel csökken.
  32. 32. Lockless?
  33. 33. Lockless veszélyekCompiler reorderingCPU reordering (cache és memória miatt)Stale adatok jelenléte miatt: • nehezen debuggolható, ritkán előőforduló hibákMielőtt ilyenbe kezdesz: • memory ordering • memory barriers • compiler reordering barriers
  34. 34. Összefoglalás •Párhuzamos programozás okozhatƩ meglepetéseket •Egy algoritmus párhuzamosítása gyakran lassulást eredményez elsőőre! •Mérés & megértés
  35. 35. VÉGE lwn.net/Articles/250967/rdrop.com/users/paulmck/perfbook/perfbook.2011.08.28a.pdf

×