[rlug] minimal vm :: postfix replacement?

Dumitru Moldovan dumol at gmx.com
Tue Jul 14 14:46:33 EEST 2020


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 at 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.




More information about the RLUG mailing list