CPU magok összekapcsolása

 ( addi | 2014. február 13., csütörtök - 16:56 )

Sziasztok!

Adott egy régebbi Windows-os program, ami csak 1 szálon képes futni és egy 8 magos szerver.

Van rá valamilyen megoldás, hogy a program az összes magot kihasználja? (Gondolok itt virtualizációs réteg beiktatására, ami a Windows számára egy CPU-t közvetít, és így a program meg tudja hajtani az összes magot.)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Nem, ilyen nincs. Ez az az eset amikor skálázni csak úgy tudsz,ha növeled az órajelet.

Régebben láttam kísérleti megoldásokat KVM-hez, de most nem találom. Éles környezetben amúgy sem lenne jó. Ez alapján pedig lehetne valamennyi teljesítményt kinyerni (igaz ez chip szinten elemezte): http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.8833&rep=rep1&type=pdf

++

Én mindenképp megpróbálnék valami profile jellegűt összehozni. Mert lehet akár diszk limited is, ha olyan a program.
Esetleg érdemes még megpróbálkozni más gyáró CPU-ival is, mert ki tudja, hogy a fejlesztő mire optimalizált.

### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch

Hehe, éppen ezzel a problémával küzdök egy Firebird adatbázissal. Nem megoldható a dolog.

Hasonló problémával küzdöttünk mi is. Firebird egyszerűen nem volt hajlandó gyorsulni akár mit varázsoltunk. Az eredmény az lett, h váltottunk mysql-re. Bizonyos területen nagy visszalépés volt, mert az üzleti logika jó része a db-ben volt (átírtuk program kódba), cserébe megdöbbentő teljesítmény növekedést és skálázhatóságot kaptunk. Szerintem a Firebird felett egy kicsit eljárt az idő.

Esetleg postgresql nem lett volna jó?

De valszeg jobb lett volna, de rajtam kívül senki nem támogatta.

Sokmindentől függ...

Több szempontból sem teljesen korrekt, amit írok és magam is tudok kivételeket mindegyikhez, de:

- a MySQL-t sokkal többen ismerik, mint a PostgreSQL-t
- kicsi, egyszerű, egygépes adatbázisokra a MySQL-t egyszerűbb használni, kevésbé tehetséges programozók és DBA-k körében munkát, időt, pénzt lehet vele spórolni a PostgreSQL-hez képest
- adattárház-jellegű egygépes adatbázis esetén (nagy, sok adat, sok adatot érintő lekérdezések) a PostgreSQL sokkal jobban skálázódik sok processzorra és memóriára, mint a MySQL
- forgalmas webfarm mögé read-only replikákat rakni ugyanolyan egyszerű mindkettővel, de a programozók inkább a MySQL-t fogják ismerni, ezért az az olcsóbb
- multi-master replikációt csinálni MySQL-lel egyszerű, PostgreSQL-lel meg bonyolult, alapból egyikhez sem fognak érteni a DBA-k és cserébe mindkettő eléggé béna mondjuk egy Oracle-höz képest

Szólva lehetett volna, de...

Igen, és úgy biza kb. ezek voltak az indokok ami miatt mysql -lett.

Nem igazán értem, hogy miben egyszerűbb egy mysql-t használni, mint egy postgresql-t. Ami szinten a legtöbben használják, ott szerintem pont ugyanolyan egyszerű. Ráadásul neki ott voltak az adatbázisba lefejlesztett kódjai, amiket "csak" át kellett volna rakni postgres alá...

Ebben az esetben ez nem túl egyszerű, egy kb. 20 éves (!), Interbase-ből kinőtt monstrum használja a Firebird-öt. Váltani róla teljesen esélytelen.

Egyébként a következők vezet(het)nek eredményre az infrastruktúra szempontjából:

- CPU architektúra váltása újabbra
- CPU órajel növelése
- Firebird működése mód váltása SuperServer --> SuperClassic --> Classic irányban (a SuperServer csak 1 procimagot tud használni adatbázisonként)
- Firebird adatbázisok darabolása több adatbázissá, akár ugyanazon a gépen (ha az adatok jól partícionálhatóak)

Meg persze lehet az adatbázist (sweep, GC hangolása, indexek felülvizsgálata stb.) és a programot (query-k optimalizálása) hangolni.

Huuu az nem mai fejlesztés.
Majdhogynem csak az újraírás jöhet szóba mint megoldás.

A db darabolás kivételével mindent próbáltunk, és az áhított gyorsulást nem értük el. Ezért jött aztán a csere és a végkövetkeztetés, h amíg nem változik az FB addig kerülni, mert szinte bármi jobb (teljesítményben) nála.

A módváltás (Classic, SuperServer, SuperClassic) sem segített? Az SS egyik nagy baja, hogy adatbázisonként csak 1 procimagot képes használni, de a másik kettő ennél ügyesebb.

Mérhető volt némi változás a szerver mód váltás miatt (több verziót is próbáltunk), de nem számottevő. Azt már nem tudom megmondani, mennyivel változott, de szinte elhanyagolható volt. Látszott, h több szál fut meg h a ram használat is növekedett meg ilyesmi, de olyan kicsi volt a változás, h a kliensen szinte nem is volt mérhető. Optimalizáltunk indexeket, táblákat, növeltünk redundanciát hátha a több tábla összekapcsolása a probléma, (ja és csináltunk cache táblákat is) de semmi komoly eredmény. Külső hozzáértőket felkértünk, h nézzék már meg a db-t, h nem e mi rontottunk el valamit, de semmi eredménye nem lett. Már az is megfordult a fejemben, h egyszerűen az adatok kiszolgálási sebessége nem elég, de ezt már nem tudtam befolyásolni. Átírtuk a db léjert és bővítettük memcached -el, úgy h komplett lekérdezések eredményeit tároltuk benne, na ez sokat számított az össz teljesítményben. A következő lépés az volt, h mysql-ben csináltunk tesztet ugyan arra a táblákra lekérdezésekre ugyan annyi adattal és ugyan azon a vason. Az eredmény megdöbbentő volt: a mysql erőből ment úgy mint fb+memcached, ezután már nem volt kérdés a váltás. A végeredmény mysql+shm cache+file cache lett nagyon komoly sebesség növekedéssel.

Hát, ez igen szomorúan hangzik. Megkérdezhetem, hogy kik voltak a külső szakértők? Dimitrij és társai vagy valaki más?

En is szomoruan hallom. Tobb, mint 10 eve fejlesztunk firebirdre, nagy megelegedettsegunkre. Ha valami problemank volt, rendszerint kiderult, hogy mi nem ertunk hozza (ertsd: ha kicsit atszervezed a dolgot, akkor begyorsul). Altalaban a neten ott a segitseg, de a fejlesztok is segitokeszek. Konferencian is voltunk mar, nagyon hasznos volt a fejlesztokkel valo kommunikacio.
Van olyan ugyfelunk, ahol tobb gigas adatbazis van, tobb millios tablakkal, az azokat osszekapcsolo selectek is milliseces valaszidoket hoznak.
Mashol 200 adatbazis fut 8 magos szerveren 32 giga rammal, 400 konkurens felhasznaloval minden gond nelkul.
Tapasztalat az, hogy ha van memoria, es jol szervezett az adatbazis, akkor nincs lassulas, illetve az adatbazist hasznalo program hibas tranzakcio-kezelese is nagyon be tudja lassitani a lekerdezeseket. (GC select eseten is dolgozik, ha ugy allnak a csillagok. OIT, AIT, stb., gstat -h sokat segit. Read only read commited vs. read committed/snapshot tranzakciok hasznalata.)

Az komoly, kár, h nem előbb futottunk össze akkor téged is megkértelek volna "szakértésre".
A szakértés kb. úgy festett, kiválogattunk egy marék lekérdezést amik mindig lassúak voltak és kiadtuk megnézésre. Persze db-vel és tesztelési lehetőséggel együtt.
Aztán meg olyan is volt, h mit szeretnénk tárolni abból mit szeretnénk kinyerni és ehhez a meglévő struktúra + lekérdezések jók e.

Egyébként, nem volt nagy adatbázisunk olyan hűde sok rekorddal.
A teljesítmény probléma nekünk akkor jelentkezett mikor olyan lekérdezések futottak amik rengeteg kis rekordot mozgattak meg. És a vicc az egészben, h se disk és ram se cpu hiány nem volt (ezt naplóztuk rendszeresen), hanem csak úgy csinált valamit.

A tranzakció kezelés is a minimumra volt szorítva, mert az is látványosan "ette az időt", de az is csak menet közben derült ki. Egyébként el tudom képzelni, h a mi hibán volt, de nem tudtuk megoldani akkor mikor kellet, és nem találtuk meg a megfelelő embert aki megmondta volna a tutit.

Nyilván, ha átírható volt kevesebb erőforrás ráfordítással, akkor azt kell(ett) választani. Nem szeretnélek rábeszélni a firebird-re, de azt sem szeretném, ha az terjedne, hogy nem jó. Pl. az orosz posta ezt az adatbázis kezelőt használja, nem kevés adattal, nem kevés tranzakcióval és nem kevés klienssel.
A legutóbbi konferencián, ahol a tranzakció kezeléséről volt szó, szélsőséges projektnek egy olyan weboldalt emlegettek, ahol havonta 1 milliárd tranzakció fut az adatbázisban.
Nálunk a másik fő fejlesztési irány az Oracle, van, hogy az FB jobb eredményeket produkálni. Mindig meg kell találni, az adott projektre mi a jó választás.
(Egyébként a Firebird tranzakció kezelése szerintem szenzációs, viszont az egyediségéből adódóan okozhat jelentős lassulást (még az Interbase-es időkből örökölte). Mi is belefutottunk sok év használat után, hogy speciális esetekben lassultak a selectek, és csak az segített, hogy a fejlesztőkkel konzultálva ténylegesen megértettük a működését és ez alapján változtattunk a program tranzakció kezelésén.)

Előtte nekünk sem volt bajunk vele, tette a dolgát ahogy azt megszoktuk.
Hónapok mentek el a felismeréssel mire rájöttünk, h ez van kevesek vagyunk hozzá v. egyszerűen ennyit bír v. nem ere való. 1-2 nap alatt előállítottuk a mysql-s teszt környezetet és az úgy ment mint a szél. A vezetés kapásból mondta, h tegnapra legyen kész (ami érthető volt részükről) és innentől megpecsételődött a sorsa. Személy szerint szeretem az fb-t, kb. onnantól használtam mikor kiváltak az interbase-ből. Ahol dolgoztam 2 dolgot javasoltam (ha kérdeztek): oracle v. firebird.

Esetleg ha van kedved és energiád rá, szívesen részletezem a problémát, mert a megoldás még mindig érdekel. Nem késő tanulni belőle ha hibáztunk is.

Természetesen érdekel engem is, mindig tanul az ember valami újat :)

Igyekszem rövid és pontos lenni.
Vannak termékek, a termékeknek különböző változatai (1:n kapcsolat), több nyelven. A termékek és a változatok is bizonyos szempontok szerint csoportosíthatók, nevezzük tulajdonság-nak. Értelem szerűen amibe a termék be van sorolva abba a termék változat is, de fordítva nem. Egy termék/változat több tulajdonsággal is rendelkezhet. Vannak árak, több pénznemben is, a terméknek is és a változatoknak is, de a termék ára csak egy iránymutatás, a konkrét ár a változathoz van rendelve, és amitől csúf a dolog, h naponta más ár van. Az árakat előre töltik akár fél v. egy évre is. Töltik még azt is, h adott napon mennyi van belőle. Értelem szerűen egy termék változatot csak akkor lehet megvenni, ha (van ára) és (a mennyiség > mint amennyit szeretne a user) és (mindezt dátumtól dátumig) keresi. A keresésbe még bejönnek (esetek 90%-ban) a tulajdonságok is mint szűrési szempont.
Van még egy cifrázása a dolognak az a sorrend, ha a user nem ad meg sorrendet (pl. ár v. tulajdonság v. idő szerint) akkor vannak előre definiált sorrendek adott keresési / szűrési feltételekhez amit alkalmazni kell a találati listára.
Ebből a táblák kb. így:
[termékek]
[termék változatok]
[tulajdonságok]
[termék és termék változat X tulajdonságok] - ez egy kapcsolótábla (asszem ez a neve)
[napi árak és mennyiségek]
[sorrendek]
[sorrendek X tulajdonságok + egyéb feltételek] - szintén kapcsolótábla

A táblákban van némi redundancia is tervezve, h ne keljen mindenhez összeszorozni őket.

Kezd nagyon offtopic lenni, ha magánban folytatjuk szívesen veszek akár egy üres, vagy anonimizált adatokkal töltött adatbázist + a select-et, amiről tudjátok, hogy lassú.
Nekem ez nem tűnik olyan bonyolultnak, hogy lassulást feltételezzek.
Amik eszembe jutottak hívószavak szintjén:
- to_char rossz használat (index a date mezőre van, selectben to_char(date, 'YYYYMMDD') = '20140215), ez indexet veszít
- cte használattal lehet egyszerűbb lekérdezés írható (firebird 2.1től)
- lehet, ha nagyon megtréfálna, akkor tároltból selectálnám az eredményhalmazt, nem "sima" select-et írnék rá

ok

Nem lehetne inkább másik, e célra nyitott topic-ban?
Végre egy érdekes társalgás, erre elviszitek privátba :(

Csatlakoznék, érdekelnének a további tapasztalatok.

+1
---
#include "alairas.h"

Készítettem egy blog bejegyzést, nem tudom ez-e az ok LMoon-éknál, de összeszedtem a gondolataim és leírtam egy lehetséges lassulási okot.
http://hup.hu/node/130595

Hát ja én is szomorú és csalódott voltam. Nem hivatalos szakértők voltak, hanem olyan külsős kollégákat kértünk meg, akikről tudtuk, h éveket fejlesztettek fb-ben (és más db-re is), de a rendszert nem ismerték, így "tiszta" fejjel tudták tárgyilagosan vizsgálni a db-t. "Dimitrij és társai" -t nem ismerem.

Ket kerdesem lehet?
1. van olyan megoldas a programban, hogy egy vagy több rekordot szamtalanszor update-el (mindegy, hogy tranzakción belül, vagy több tranzakció)? (Láttam ilyen megoldást folyamatos (lyukmentes) sorszám képzésre pl.)
2. vannak-e hosszan nyitva tartott tranzakciók (akár órákig, napokig)?

1. igen. Az egyik program tipikusan ezt csinálta, egy tr-ben egyszerre akár több 100 rekordot is updatel-t, ebből egy napon akár több is lehetett, de aztán napokig semmi csak select hegyek és 1-1 update.
2. normál esetben nem. Mikor belassult a szerver akkor bármi megeshetett.

A firebird egy adatlapot 70%osan tölt fel adatokkal, a maradék 30%ot fenntartja a változásoknak. Ezek a változások mindaddig megmaradnak, és nem érvényesülnek véglegesen, amíg van olyan tranzakció (akár önmaga is), amely érintett lehet a korábbi állapotok kiolvasásában (aktív read commited, snapshot-os tranzakcók vannak az adatbázisban). Ha a 30% megtelik, akkor a változások új adatlapra kerülnek, ami miatt az olvasás (is) jelentősen lassul.
Saját mérések alapján 4k-s page esetén egy integer mező 1500-1700 update-je után elkezdenek belassulni azok a selectek, amelyek olvassák ezt az adatot. Ez a lassulás exponenciális, míg egy select <1 ms alatt lefut az update nélküli rekordra, addig egy sajét/konkurens tranzakción történő 1500-1700 update esetén már egy újabb selectre/update-re 1 mp felett is lehet a válaszidő.
Az üzleti logika függvényében ki kell váltani az ilyen update-eket. Vagy gyakori committal (ha nem fontos a tranzakció), vagy más megoldással (pl. segédtáblába insert-ek és a tranzakció végén az utolsó helyes érték egyszeri update-je).

Lehet arról szó, hogy a sebességteszt eredményeket publikáld?

Hát meg próbálom megkeresni, de nem sok reményt fűzök hozzá. A tesztelés körülményeit tudom részletezni is akár emlékből, de a számokat nem.

Csak a turbo boost segíthet rajtad egy kicsit.

http://en.wikipedia.org/wiki/Intel_Turbo_Boost

+1 a többieknek, illetve ritka hülye megoldás, ha az adott process-t rögzíted mondjuk a 7-es számú maghoz, az összes többi folyamatnak pedig megmondod hogy ezt az egy magot pont nem használhatjátok, illetve megemeled a folyamat prioritását.

Így _talán_ hoz valamekkora eredményt.

Bizonyos esetekben azt is tapasztaltam, hogy az is lassít, ha olyan core-on fut valami, amivel a végletekig gyorsítani kívánt egyszálú processz fut. Tehát ha a 7-es és a 8-as mag osztozik a külső cache-en, akkor tiltsuk ki az összes processzt mindkettőről, kivéve persze a gyorsítani kívántat, amit meg épp ezekre teszünk.

Ez number crunchig programoknál jelenthet egy pár százalék pluszt, az itteni adatbázis-problémánál nem tudom mit okoz.

A klasszikus megoldás hogy ilyenkor nyolc példányban indítod el - már persze ha a program és a feladat is olyan, hogy felosztható több darabra. Ha nem, akkor ez van, ezt dobta a gép.

Igen, lecseréled a szoftvert. Vagy a fejlesztőjét. Vagy mindkettőt.

És akkor még kérdezik az emberek, hogy minek ennyi architektúrák a tantervbe...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A kód egyik részét futtatná az egyik mag, a másik részét a másik mag, de az egyik mag által futtatott részeredményeket kell felhasználnia a másik mag által futtatott kódnak, akkor természetesen nem futtathatod időben egyszerre.

Az sem baj, ha az igényen túl arra is gondolsz, mit is jelent az, hogy több magos egy CPU.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

ha a feladat olyan, hogy lehet darabolni, vagy a skálázás alapvetően read only lekérdezéseket érint, akkor esetleg lehet azzal próbálkozni, hogy a 8 magos gépen létrehozni 8 darab virtuális gépet 1 maggal, azokra telepíteni 1-1 példányt a fixen egyszálú programból, és megoldani hogy a VM-ek között legyen load balance

ez nyilván nem fog működni, ha nem darabolható a feladat, egymáson dependálnak a dolgok amiket az egyes cpuknak kéne csinálniuk, de ez minden párhuzamosításnak gátját szabja

valószínűleg jobb újraírni az egészet, mert ez csak tüneti kezelésre jó...

esetleg ha java alapú lenne a cucc, akkor meg lehet próbálni Hadoop alapú MapReduce jobokká átkonvertálni azt amit csinál, és a több cpu használatát az egy gépen futó n darab task teremti meg, itt is persze megvan a követelmény hogy egyáltalán lehessen a dolgot párhuzamosítani

Vegyel egy ilyet:
AMD FX-9590

Ha csak 4 magot hasznalsz a 8-bol, akkor ha jol tudom turbon tudja jaratni oket 5 GHz-en. Igy ha most van egy 3-4 GHz-es szerver procid, akkor nyerhetsz 25-70 % gyorsulast
(es egy tobb mint 200 W-os futotestet)

Ha letezne ilyen -jol mukodo, tenyleg altalanos- megoldas, akkor az mar be lenne epitve hardwarebe mindenhol es most is a sok magot egykent hasznalnank, hiszen egy nagy teljesitmenyu magon mindig konyebb skalazodni mint tobb kisebben.

bookmark

Ha már virtualizáció szóba került. Az nem működne, ha virtualboxban csinálsz egy másik szervert 1 maggal, majd azon nyomod a cuccot? A virtualbox meg fel fogja osztani a fizikai magok közt a terhelést, vagy nem? Még nem csináltam ilyet, csak elméleti kérdés...

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

Nem, nem fogja.

És hogyan? Az

INC AX
PUSH AX

szekvenciából az egyik utasítás az egyik magon, a másik a másikon fut? Kár, hogy az egyik magon lévő regiszter a benne lévő adattal együtt mit sem tud a másikon lévőről. A sorrendiség fontosságáról nem is beszélve.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ahham, értem akkor. Azért kérdeztem mert nem tudom, hogy működik-e a vbox ilyen téren.

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

Ez nem annyira a vboxtól függ. Inkább arról van szó, hogy több magon különálló regiszterkészlet felhasználásával egyidőben futnak programok. Párhuzamosítani úgy tudsz, ha fel tudod bontani a feladatodat egyidejűleg futtatható részfeladatokra, s ennek az is feltétele, hogy az egyik futás eredményére a másik folyamat ne tartson igényt.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Azt értettem előtte is, hogy párhuzamosítás kell. Csak arra gondoltam a vbox megteszi-e vagy sem. a válasz a nem, szóval megtudtam a lényeget. ;)

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

Arra utaltam, hogy nem tudom elképzelni, ezt hogyan tudná megtenni, persze lehet, hogy csak a fantáziám sekélyes. A programot funkcionálisan elemezni, azt újraírni nem tudja. Favágó módon meg nem lehet, mert a műveletek sorrendisége számít, az egyik részeredményen végzünk újabb műveletet, hogy a következő részeredményt kapjuk.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem lehetetlen azert, csak nagyon valoszinutlen.

Elmeletben egy leforditott programot is szet lehetne szedni reszekre, egyfajta hosszabb out of order vegrehajtas szeruen (ahogy most a processzorokban is van).
Sot meg parhuzamosan is ki lehetne szamolni egy elagazas mindket agat es akkor nincs performance penalty teves branch prediction miatt. Gondoljunk bele 8 mag eseten ez 2^3-on. Vagyis 3 elagazast is tudunk parhuzamosan csinalni elore. Ha meg jobban el akarunk rugaszkodni, akar dataflow szeruen elemezzuk es vegrehajtjuk egy dataflow processzor arrayen.

Persze, csak ha egy fostalicska kőkorszaki szar a program, amit a 15 évvel ezelőtti gépekre írtak, azon semmi nem fog segíteni.

És az a rettenetesen szörnyű, hogy itt a "magyar informatikusok krémje"* közül egyesek még komolyan gondolkodnak is rajta, hogy ez majd egy varázslattal hirtelen menni fog.

*Lololol...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nincs ezzel semmi probléma!
Hozzáértés szempontjából a helyére került: virtuális.

Virtualizálással nem tudsz párhuzamosítani soros végrehajtást.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A kérdés lett virtuális.

Jó, csak nem volt világos, hogy ezt írod.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A tudás = virtuális. :)

Pedig én csak kérdeztem, lehetséges-e a dolog...

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

Félreérted!
Valamit nem tudni, nem szégyen. Ha marhaságot kérdezel, az sem szégyen. Nem tudtad, így nem is tudtál jól kérdezni. A probléma inkább úgy fogalmazható meg, hogy volt olyan, aki erre magabiztosan marhaságot válaszolt. Szóval a színvonalra vonatkozó utalások ez utóbbira vonatkoztak.

Mit kevertél össze? A virtualizációnál, - ha a CPU pl. 1/10 egységenként osztható ki - akkor oszthatsz pl. 15/10 CPU-t egy gépnek. Ebben az esetben 150% erőforrás áll rendelkezésedre. De! Abban a pillanatban, amikor leírtad, hogy a program 1 szálat használ, eldöntötted a kérdést.

A virtualizáció kicsit egyszerűsítve időosztásos rendszer. Ebben 1 CPU-ból, a példa szerint kaphatsz valahány 1/10 részt, de legfeljebb 10/10 értéket. Mivel a több CPU párhuzamosan működik, egy szál ebből legfeljeb 10/10 részt láthat, azaz max. 1 egészet. Ha 1 CPU több szálat tud kezelni (hyperthreading), akkor is a 100% időn belül teszi. Tehát 2 szál=2x50% erőforrás, ami megint legfeljebb 100%. Mit kezdjünk a fenti 150% CPU-val? Nagyon egyszerű: ezt olyan programok tudják csak kihasználni, amelyek több szálon dolgoznak.

Egy szál esetén a következő lehetőségek adódnak gyorsításra:
A) A többi core lekapcsolása -> kevesebbet veszekszenek a buszon. Ezt előszeretettel alkalmazzák egyes benchmarkok esetén.
B) Az A módszer + órajel emelés. (turbo üzemmód)
C) A feladat több diszjunkt részre bontása. Ha magas az IO terhelés akkor célszerűen a feladatok száma < magok száma, így a feladat nélküli magok segítenek az IO-t kezelni. - Ne feledjük, hogy a feladatok 1 szálat futtatnak! (Ilyen esetekre néha jó az ilyen parancs: bindprocessor.)

A C esetben tovább lehet gondolni, hogy mi az az egy szál: szál vagy adatfolyam vagy adatbázis. A feladat ilyen irányú megközelítése az adatszervezés.

Nem értettelek félre, nem konkrétan az hozzászólásodra válaszoltam, te voltál a szál végén és hogy sikerült jól összeveszni... ;)

Egyébként igen, a nem tudás nem szégyen. senki sem tudhat mindent születése pillanatában.

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

"senki sem tudhat mindent születése pillanatában"
LOL!
Tehát vannak egyesek, akik már akkor sok mindent tudnak?

Pl. Einstein, aki az Idegenektől szerezte zsenialitását. :)

Rosszul olvastad. Egyesek mindent tudnak születésük pillanatában! :D Ne becsüld alá őket azzal, hogy azt írod, sok mindent tudhatnak. ;)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Egyesek sem tudhatnak mindent, hisz senki nem tudhat mindent. Persze ha figyelembe vesszük a magyar jogrendet, akkor vannak egyesek, akikre nem vonatkozik a senki sem.

Miva??? Ülj le, egyes! Olvasás egy dolog, de érted is mi van ott? Nem hinném, mert épp aszondom, hogy SENKI SEM, nem hogy egyesek igen...

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

Akkor most próbálj te is olvasni:
"senki sem tudhat MINDENT", ezt írtad.
Tehát az elméleted szerint vannak, akik mindent ugyan nem tudnak, de sok mindent igen.
He?

Most azon mit kell kavarni, hogy "senki sem tudhat mindent születésekor" ?
Össz. arra céloztam, hogy azért kérdeztem mert kurvára nem tudtam, és azért van ez az oldal, hogy itt megtudjam, amit születésemkor nem kaptam meg.

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

:(