On Mon, Jul 13, 2020 at 05:13:40PM +0300, manuel "lonely wolf" wolfshant wrote:
On 7/13/20 3:21 PM, Dumitru Moldovan wrote:
On Mon, Jul 13, 2020 at 11:59:38AM +0300, manuel "lonely wolf"
wolfshant wrote:
On 7/13/20 11:35 AM, Dumitru Moldovan wrote:
Și revenind la discuția cu salvat câțiva MB de RAM… Kernelul implicit
din RHEL/CentOS cred că nu e optimizat pentru un asemenea scenariu.
LOL :)
este. din greu.
Deși îs curios de rezultat, nu am vreme de pierdut cu recompilatul unui
kernel CentOS doar pentru a vedea cât se poate economisi
dupa cum ti-am zis deja de 3 ori in priv: nu cistigi absolut nimic
fiindca modulele nefolosite oricum nu se incarca in memorie. _poate_
cistigi ceva daca scoti din partea care e built-in, doar ca nu prea ai
ce scoate de acolo.
Bun, acuma sper că am lămurit faptul că nu tot ce poate fi compilat
ca modul este compilat ca modul în CentOS 8. Și prin urmare kernelul
CentOS chiar nu este optimizat pentru un scenariu în care fiecare MB
contează. No offence, e ok, e optimizat pentru altceva, no biggie!
Dar să lămuresc și de ce am insistat, mai mult în privat inițial, dar
dacă repetai același lucru în esență, a trebuit să sap un pic pe cont
propriu și am vrut să împărtășesc și pe listă rezultatele.
Întâmplător am mai multe distribuții de Linux și alte câteva OS-uri în
administrare (evident, la un nivel destul de superficial de cunoaștere,
inclusiv pentru CentOS). Comparând însă cât spațiu pe disc necesită,
cât de mari îs containerele Docker comparabile, cât RAM le trebuie ca să
nu swap-uiască excesiv în testele noastre și cât de repede merg ele, am
remarcat că unele îs mai bloated decât altele, nu doar la un moment dat
în timp, ci și evoluând negativ de la o versiune la alta. RHEL/CentOS e
„campion” la capitolul ăsta¹ din păcate, din ce am văzut personal de la
versiunea 4 până în prezent la 8.
Acuma mno, ce să zic, CentOS e o distribuție specială, fiind un copycat
RHEL, deci cumva vina e mai mult a celor de la RHEL. Dar nu exclusiv!
Am și VM-uri cu Amazon 2.0 în administrare și (în mod neașteptat pentru
mine), sunt foarte rapide și sensibil mai puțin „bloated” decât CentOS
7 sau 8, cu care înțeleg că se înrudesc îndeaproape. Ca o idee foarte
superficială, în ce privește kernelul, Amazon Linux 2.0 e mult mai
aproape de Alpine 3.12 decât de CentOS 7 sau 8:
[root@bs1f-lnx-amzn2-x64-115 ~]# grep Slab /proc/meminfo
Slab: 33536 kB
Prin urmare, o (altă!) bănuială a mea ar fi că se poate mai bine și în
CentOS. Dar bineînțeles, întâi de toate să fie conștientizată problema,
nu negată cu încăpățânare și luat în derâdere cine zice altfel, că știm
noi mai bine, că doar cu asta ne ocupăm. Uneori e greu de văzut
pădurea din cauza copacilor…
De ce e importantă chestia asta? Time is money, RAM is money, storage
is money, etc. Amazon se pare că a înțeles asta mai rapid! În plus, e
păcat de resursele consumate aiurea în milioanele de instalări CentOS.
Serverele iau din ce în ce mai mult din consumul total pe planeta asta
și unele optimizări îs easy pickings. Deci pe lângă sortat gunoiul
responsabil, n-ar strica dacă responsabilii CentOS și-ar sorta mai cu
grijă modulele de kernel, opțiunile de compilare, dependențele
pachetelor mai importante șamd. Totul pentru un consum mai scăzut de
spațiu de stocare și timp de procesor. Optimizările Amazon Linux ar
trebui să fie publice, că doar vorbim de soft GPL.
1. Precizare: campion negativ între distribuțiile Linux mai uzitate
pe servere, că Windows și în special macOS (în ultima vreme) îs chiar
mai bloated. Și când zic Windows mă refer la versiunea aia fără
desktop, chiar și aia e mai bloated decât CentOS.
_______________________________________________
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
