BGAFC Vendégkönyv

Σ: 1 post

TCH (statz)

#1, Főfasz (10696)

4510 | #5b1d | ^ | Idézet | Tue, 27 Jan 2026 16:18:17 +01

188.143.*.*

*.pool.digikabel.hu

@miklos_akos:
Addig nincs ertelme folytatni a migraciot, amig a gepek nincsenek atpakolva.

Értem, de volt egy másik feladat is, azt lehet csinálni addig, amíg a migrációt nem tudod folytatni. Vagy félreértem? Csak mert azt mondtad, hogy a fontosabb (a migráció) szakította meg a másikat. Vagy a fontosabb az a VLAN setup volt és a migráció volt a kevésbé fontos?

@miklos_akos:
Most megneztem az egyik app szervert: top - 08:26:57 up 507 days, 2:26, 1 user, load average: 7.66, 7.13, 6.81, meg az egyik load balancert: top - 08:27:29 up 1604 days, 2:28, 1 user, load average: 6.62, 6.05, 6.10.

A load balancer az csak szétoszt, nem az a lényeg, hanem a másik, ami oké, hogy most alacsony loaddal bír, de hány másik gép is van, amik között ez szét van osztva? Megkapod, hogy mennyi lenne a valós load, ha felszorzod a most látott loadot a gépek számával. Na, azt lehetne lecsökkenteni, ha optimalizáltabb lenne a dolog és akkor máris kevesebb gép kéne, amik közt szét lehet osztani. (Így igazából nincsenek is kihasználva a gépek, ez így pazarlás, hogy van egy csomó gép, meg egy csomó CPU, de igazából 10% alatt van rajtuk a load; akkor minek ennyi gép?)

@miklos_akos:
DB szerverekhez nincs hozzaferesem es nem is szeretnem behackelni magam, ha nem muszaj. :D

Nem is kell. Ha ez a kérdés egyáltalán felmerül, akkor az is mutatja, hogy volna mit optimalizálni, mert alapvetően a DB-hez csak két esetben kéne hozzányúlni: egyfelől íráskor, másfelől meg akkor, ha a kiolvasandó adat nincs még benne a cache-ben. (Aztán íráskor lehet invalidálni az érintett cache entry-ket, hogy a legközelebbi lekéréskor force-oljuk a DB-fallback-et és a cache-rebuild-et.) A DB szerver tárolásra van és nem terhelésre.

@miklos_akos:
A cloud meg igyis-ugyis rank lett volna eroltetve. D:

Az mondjuk szar ügy. :/ (Meg sem kérdezem, hogy miért is muszáj...)

@miklos_akos:
Az EPYC procijaink 200W TDP-vel birnak.

Az a maximum. Normál esetben (alacsony load-dal) ez kevesebb.

@miklos_akos:
A webes feluletbol is lehet, de ez megint egy olyan retardalt limitacio, ami egy alapveto feature. D:

Csak egy lehetőség volt.

_  o  _
 \/|\/ 
   |

@miklos_akos:
A Mogile tracker nodeokban 2 db AMD Opteron 6234 van, fejenkent 115W TDP-vel, az appokban meg Xeon E5-2630 v4 (85W TDP) meg E5-2630 v3 (85W TDP) procik.

De az a maximum. A teljesítményfelvétel nem konstans. Alacsonyabb load esetén alacsonyabb lesz a teljesítményfelvétel is. És oké, hogy most alacsony is a load, de sok gépetek van, sok CPU-val.

Ezt méretezni szokás: kiszámolják, hogy hogy zabál a rendszer minél kevesebbet. Pl. úgy, ha van 100 gép 5%-os avg. load-dal, vagy úgy, ha van 20 gép 25%-ossal, vagy esetleg, ha van 5 gép 100%-ossal, mert a TDP sem lineáris; könnyen lehet, hogy az 5%-os avg. load és a 25%-os között nincs szignifikáns teljesítményfelvételbeli különbség (a CPU-knak ugye van egy alap zabafaktora is, amin elég sok múlik), viszont ötödannyi gép, tehát úgy máris 20-25%-ra redukáltuk az összfogyasztást, viszont a 100%-os loaddal lehet, hogy már annyira megnövekszik a fogyasztás, hogy hiába lesz negyedannyi gépünk, többet fogunk enni. Jó, az avg. 100% load mondjuk mindenképp rossz ötlet, de érted, mit szeretnék mondani. Mérni kell, meg méretezni. (Meg optimalizálni. :P )

Ha pl. azok az EPYC CPU-k így 10-%-os loaddal is 150+W-ot zabálnak, akkor irdatlan pazarlás, hogy 10-%-os avg. loaddal mennek. Gondolj bele: ha 7.5% -> 150W és 100% -> 200W, akkor 10 gép esetén ez 1500W, viszont a terhelés alapján elég lenne 1 is, amin lehet, hogy már 75% load lenne, de a teljesítményfelvétel máris csak - hasraütök: - 180W. Máris közel tizedakkora fogyasztás. (Ez az egész persze elméleti feltevés volt, mert nem tudom, hogy mennyit eszik az EPYC 7.5%-os kiterheltség mellett. Ezért kell mérni.)