Re: [rlug] minimal vm :: postfix replacement?
On Fri, Jul 17, 2020 at 07:12:20PM +0300, Dumitru Ciobarcianu wrote: "Salvatul" de memorie în VM-uri de fapt nu salvează nimic. Experiența ta cu chestii personale e OK, dar nu te grăbi să generalizezi și pentru cei ce folosesc virtualizarea în scopuri ceva mai profi. Pentru fiecare VM cu CentOS tre' sa aloc juma de GB de RAM în plus în comparație cu alte distribuții de Linux pentru fix aceeași treabă. Probabil că nu-s singurul care are problema asta, deși mulți (inclusiv CentOS maintainers) nu o conștientizează. Am folosit exemplul cu chestii personale pentru că nu îmi permit să public date de pe sistemele de la birou. Ce voiam să spun este că nu contează pentru utilizarea memoriei fizice faptul că tu trebuie să aloci 0.5 Gb în plus în config-urile sistemului de virtualizare pentru un anumit sistem de operare (în afară de faptul că este probabil enervant pentru tine). Pentru că la final acel jumătate de gigabit de fapt va fi shared între toate cele N mașini virtuale de pe acel host. Ok, poate fi deranjant dacă ești obligat să nu folosești overprovisioning însă din experiența mea sunt destul de puține situațiile în care este într-adevăr necesar acest lucru. Iar pentru situațiile "profesionale", "at scale", unde sunt hosturi cu mult mai mult RAM (și VMs per host), economia adusă de acest sistem are cifre mult mai spectaculoase. Singurul showstopper pentru asta ar fi un sistem "multi-tenant" datorită posibilelor considerente de securitate, dar acolo este cu totul altă cutie de viermi. Oh, sunt de acord că CentOS este un pic "bloated", din motive mai mult sau mai puțin bune (sau rele). Poate fi o provocare pe mașinile cu deficit de RAM. Însă într-un sistem virtualizat, unde cei 0.5GB sunt efectiv la o apăsare de buton, este cea mai mică problemă. Dumitru "52 VMs of Windows XP with 1 GB of memory, on 16 GB of RAM [1]" C. [1] https://en.wikipedia.org/wiki/Kernel_same-page_merging Din nou, o experiență interesantă și îs de acord cu ideile tale. Dar nu te grăbi cu generalizarea… Io nu am două VM-uri la fel pe același sistem. Am cel mult 3 VM-uri cu aceeași versiune de sistem de operare, obligatoriu pe sisteme diferite. Deci nu beneficiez ca tine de kernel same page merging. Și probabil că mai îs și alte scenarii asemenea, nu doar cele în care e pus un accent crescut pe securitate. E adevărat că 0.5GB mie mi-e ușor să-i aloc. Mai nasol e când se termină RAM-ul pe servere și încep să swap-uiască. Am avut experiențe neplăcute, se poate întâmpla să stai și ore întregi ca să repornești un asemenea server intrat adânc în swap. „De ce?” s-a dovedit a fi o problemă fascinantă, până la urmă pentru setup-ul de care vorbesc am ajuns să dezactivăm (aproape) complet swapping-ul pe host și să lăsăm VM-urile să intre în swap. Iar când exagerează în privința asta, mai le dăm câte un 0.5GB de RAM în plus. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
"Salvatul" de memorie în VM-uri de fapt nu salvează nimic. Experiența ta cu chestii personale e OK, dar nu te grăbi să generalizezi și pentru cei ce folosesc virtualizarea în scopuri ceva mai profi. Pentru fiecare VM cu CentOS tre' sa aloc juma de GB de RAM în plus în comparație cu alte distribuții de Linux pentru fix aceeași treabă. Probabil că nu-s singurul care are problema asta, deși mulți (inclusiv CentOS maintainers) nu o conștientizează. Am folosit exemplul cu chestii personale pentru că nu îmi permit să public date de pe sistemele de la birou. Ce voiam să spun este că nu contează pentru utilizarea memoriei fizice faptul că tu trebuie să aloci 0.5 Gb în plus în config-urile sistemului de virtualizare pentru un anumit sistem de operare (în afară de faptul că este probabil enervant pentru tine). Pentru că la final acel jumătate de gigabit de fapt va fi shared între toate cele N mașini virtuale de pe acel host. Ok, poate fi deranjant dacă ești obligat să nu folosești overprovisioning însă din experiența mea sunt destul de puține situațiile în care este într-adevăr necesar acest lucru. Iar pentru situațiile "profesionale", "at scale", unde sunt hosturi cu mult mai mult RAM (și VMs per host), economia adusă de acest sistem are cifre mult mai spectaculoase. Singurul showstopper pentru asta ar fi un sistem "multi-tenant" datorită posibilelor considerente de securitate, dar acolo este cu totul altă cutie de viermi. Oh, sunt de acord că CentOS este un pic "bloated", din motive mai mult sau mai puțin bune (sau rele). Poate fi o provocare pe mașinile cu deficit de RAM. Însă într-un sistem virtualizat, unde cei 0.5GB sunt efectiv la o apăsare de buton, este cea mai mică problemă. Dumitru "52 VMs of Windows XP with 1 GB of memory, on 16 GB of RAM [1]" C. [1] https://en.wikipedia.org/wiki/Kernel_same-page_merging -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On Wed, Jul 15, 2020 at 11:42:19PM +0300, Dumitru Ciobarcianu wrote: Pentru o secundă am crezut că m-am întors în '95 și urmăresc un thread cu "optimilizations" în Gentoo. Apropo de easy pickings, de ce folosești mamutul de virtualbox și nu folosești facilitățile native din Linux? Care printre altele oferă și: Se pare că e o neînțelegere la mijloc… Inițiatorul acestui fir de discuție intenționa să folosească VirtualBox, io îs de fapt cel care l-a bătut la cap să renunțe la idee. Printre altele și pentru că știu din proprie experiență diferențele, am migrat un client de la VirtualBox la KVM cu paravirtualizare pentru un setup unde chiar era nevoie de virtualizare, ceea ce în cazul de față s-ar putea să nici nu fie cazul. În acest moment, pe o mașină pe care îmi țin chestii personale, cu doar 32Gb ram (din care folosiți 22) și vreo 11 VM-uri , KSM sharing îmi salvează 2.87 GiB. A se lua în calcul că sunt vreo 3 tipuri de OS-uri, dacă le standardizam pe toate probabil salvam mai mult. "Salvatul" de memorie în VM-uri de fapt nu salvează nimic. Experiența ta cu chestii personale e OK, dar nu te grăbi să generalizezi și pentru cei ce folosesc virtualizarea în scopuri ceva mai profi. Pentru fiecare VM cu CentOS tre' sa aloc juma de GB de RAM în plus în comparație cu alte distribuții de Linux pentru fix aceeași treabă. Probabil că nu-s singurul care are problema asta, deși mulți (inclusiv CentOS maintainers) nu o conștientizează. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On 7/15/20 11:42 PM, Dumitru Ciobarcianu wrote: Pentru o secundă am crezut că m-am întors în '95 și urmăresc un thread cu "optimilizations" în Gentoo. Apropo de easy pickings, de ce folosești mamutul de virtualbox și nu folosești facilitățile native din Linux? Care printre altele oferă și: Eu îl folosesc la mine pe desktop din cauză că are un frontend prietenos și managementul rețelelor la fel. Pe servere... nu prea am frontend, windows server excepted :) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
Pentru o secundă am crezut că m-am întors în '95 și urmăresc un thread cu "optimilizations" în Gentoo. Apropo de easy pickings, de ce folosești mamutul de virtualbox și nu folosești facilitățile native din Linux? Care printre altele oferă și: -- cut here -- Introduction Optimized and effective memory management is a key factor in virtualization environments. KSM and Auto-Ballooning enables sophisticated and economic configurations for physical RAM utilization. KSM KSM (Kernel Samepage Merging) is running in the Linux kernel and scans the memory of all the virtual machines running on a single host, looking for duplication and consolidating. With KSM we're able to improve virtual machine density by as much as 300% without impacting performance. One of the great benefits of using Linux as the hypervisor means KSM is not limited to KVM and virtual machines, but can also reduce memory pressure with normal Linux applications. -- cut here -- În acest moment, pe o mașină pe care îmi țin chestii personale, cu doar 32Gb ram (din care folosiți 22) și vreo 11 VM-uri , KSM sharing îmi salvează 2.87 GiB. A se lua în calcul că sunt vreo 3 tipuri de OS-uri, dacă le standardizam pe toate probabil salvam mai mult. "Salvatul" de memorie în VM-uri de fapt nu salvează nimic. My 2c. Dumitru "shamelessly top-posting" C. On 14/07/2020 14:46, Dumitru Moldovan wrote: 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. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
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
Re: [rlug] minimal vm :: postfix replacement?
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: O măsurătoare grosieră: [root@bs1f-lnx-centos8-x64-123 ~]# grep Slab /proc/meminfo Slab: 73884 kB bs1l-lnx-alpine312-x64-135:~# grep Slab /proc/meminfo Slab: 16612 kB informatia asta nu ne ajuta la mare lucru fara sa stim ce si cum e folosit de fapt acolo... Orientativ poți compara cele două kerneluri implicite din CentOS 8 și Alpine Linux 3.12 pe "hardware" similar (virtualizat în cazul de față), cu sofware similar (instalat și configurat automat). Acuma că mă gândesc mai bine, e totuși o mică diferență, pentru slave-urile cu CentOS acordăm 512MB de RAM în plus pentru că, de, are nevoie! :-p mi-am permis sa reformatez sub forma de tabel comparativ ce ai dat tu mai sus. faza cu xfs care e in plus se rezolva pur si simplu formatind toate partitiile cu ext4 iar referitor la ipv6... cred ca ai confundat masina virtuala la care l-ai socotit; oricum exista modalitati simple de dezactivare pentru cei carora inca nu le e necesar centos alpine xfs 1474560 kvm 761856 765952 ext4749568 761856 drm 524288 536576 ipv6 528384 sunrpc 425984 421888 fscache 385024 393216 nfs 315392 327680 kvm_intel 290816 315392 libata 270336 278528 drm_kms_helper 217088 usbcore 266240 total 5414912 4595712 total fara xfs si ipv6 3940352 4067328 Mulțam, dar inutil, nu asta era ideea. Ce se vedea comparativ acolo e: 1) Modulul XFS mâncă RAM în plus și poți scăpa de el ușor. 2) În CentOS 8 nu există un modul "ipv6", e compilat în kernel. bs1l-lnx-alpine312-x64-135:~# modinfo ipv6 | head -1 filename: /lib/modules/5.4.43-1-lts/kernel/net/ipv6/ipv6.ko [root@bs1f-lnx-centos8-x64-123 ~]# modinfo ipv6 modinfo: ERROR: Module ipv6 not found. Poate ar fi trebuit să menționez, ca să fie mai clar, ambele sisteme au conectivitate IPv6. Chiar și numai având grijă să nu folosești XFS (cum e mai nou opțiunea implicită pentru /), FSVO "nou" pt ca xfs e implicit in rhel/centos de cel putin 5 ani Să zicem că avem o perspectivă diferită atunci? Posibil… Încă mai am treabă cu RHEL 6, SLES 11, Solaris 10, AIX 5.3 și altele asemenea. Și da, toate îs configurate cu IPv6, au teste specifice IPv6 de rulat. Dar kernelul CentOS pare să aibă mult mai multe chestii incluse implicit (printre care și ipv6, responsabil pentru un juma de MB). amendamentul fiind ca in exemplele date de tine, ipv6 era trecut doar la alpine Pentru că în CentOS 8 nu există modulul "ipv6", e built-in. :-] (Vorba unui clasic în viața, dacă nu am zis, am să mă repet!) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
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.
, dar am să dau
niște cifre comparative CentOS 8 vs. Alpine Linux 3.12 din VM-uri
configurate identic și automat în acel setup Buildbot de care am pomenit.
Așa, pentru o impresie generală… :-]
Prima dată le-am repornit, just in case. Apoi am golit cache-urile pe
ambele VM-uri cu:
echo 3 > /proc/sys/vm/drop_caches
O măsurătoare grosieră:
[root@bs1f-lnx-centos8-x64-123 ~]# grep Slab /proc/meminfo
Slab: 73884 kB
bs1l-lnx-alpine312-x64-135:~# grep Slab /proc/meminfo
Slab: 16612 kB
informatia asta nu ne ajuta la mare lucru fara sa stim ce si cum e
folosit de fapt acolo...
Uitându-ne doar la module, ia să vedem ce mâncă mai mult:
[root@bs1f-lnx-centos8-x64-123 ~]# awk '{print $2 " " $1 }'
/proc/modules | sort -nr | head -10
1474560 xfs
761856 kvm
749568 ext4
524288 drm
425984 sunrpc
385024 fscache
315392 nfs
290816 kvm_intel
270336 libata
217088 drm_kms_helper
bs1l-lnx-alpine312-x64-135:~# awk '{print $2 " " $1 }' /proc/modules
| sort -nr | head -10
765952 kvm
761856 ext4
536576 drm
528384 ipv6
421888 sunrpc
393216 fscache
327680 nfs
315392 kvm_intel
278528 libata
266240 usbcore
În concluzie, e o pâine de mâncat la capitolul ăsta de vânezi mai mult
de 1MB de RAM economisit în CentOS.
mi-am permis sa reformatez sub forma de tabel comparativ ce ai dat tu
mai sus. faza cu xfs care e in plus se rezolva pur si simplu formatind
toate partitiile cu ext4 iar referitor la ipv6... cred ca ai confundat
masina virtuala la care l-ai socotit; oricum exista modalitati simple de
dezactivare pentru cei carora inca nu le e necesar
centos alpine
xfs 1474560
kvm 761856 765952
ext4749568 761856
drm 524288 536576
ipv6
528384
sunrpc 425984 421888
fscache 385024 393216
nfs 315392 327680
kvm_intel 290816 315392
libata 270336 278528
drm_kms_helper 217088
usbcore
266240
total 5414912 4595712
total fara xfs si ipv6 3940352 4067328
Chiar și numai având grijă să nu
folosești XFS (cum e mai nou opțiunea implicită pentru /),
FSVO "nou" pt ca xfs e implicit in rhel/centos de cel putin 5 ani
ci EXT4 pentru toate partițiile. Pentru asta nici măcar nu tre' să
recompilezi ceva… :-p
aici sint de acord cu tine .
Dar kernelul CentOS pare să aibă mult mai multe chestii incluse implicit
(printre care și ipv6, responsabil pentru un juma de MB).
amendamentul fiind ca in exemplele date de tine, ipv6 era trecut doar la
alpine
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
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, dar am să dau
niște cifre comparative CentOS 8 vs. Alpine Linux 3.12 din VM-uri
configurate identic și automat în acel setup Buildbot de care am pomenit.
Așa, pentru o impresie generală… :-]
Prima dată le-am repornit, just in case. Apoi am golit cache-urile pe
ambele VM-uri cu:
echo 3 > /proc/sys/vm/drop_caches
O măsurătoare grosieră:
[root@bs1f-lnx-centos8-x64-123 ~]# grep Slab /proc/meminfo
Slab: 73884 kB
bs1l-lnx-alpine312-x64-135:~# grep Slab /proc/meminfo
Slab: 16612 kB
Uitându-ne doar la module, ia să vedem ce mâncă mai mult:
[root@bs1f-lnx-centos8-x64-123 ~]# awk '{print $2 " " $1 }'
/proc/modules | sort -nr | head -10
1474560 xfs
761856 kvm
749568 ext4
524288 drm
425984 sunrpc
385024 fscache
315392 nfs
290816 kvm_intel
270336 libata
217088 drm_kms_helper
bs1l-lnx-alpine312-x64-135:~# awk '{print $2 " " $1 }' /proc/modules
| sort -nr | head -10
765952 kvm
761856 ext4
536576 drm
528384 ipv6
421888 sunrpc
393216 fscache
327680 nfs
315392 kvm_intel
278528 libata
266240 usbcore
În concluzie, e o pâine de mâncat la capitolul ăsta de vânezi mai mult
de 1MB de RAM economisit în CentOS. Chiar și numai având grijă să nu
folosești XFS (cum e mai nou opțiunea implicită pentru /), ci EXT4
pentru toate partițiile. Pentru asta nici măcar nu tre' să recompilezi
ceva… :-p
Dar kernelul CentOS pare să aibă mult mai multe chestii incluse implicit
(printre care și ipv6, responsabil pentru un juma de MB).
QED! :-]
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On Mon, Jul 13, 2020 at 01:35:53PM +0300, Adrian Sevcenco wrote: On 7/13/20 1:30 PM, Dumitru Moldovan wrote: On Mon, Jul 13, 2020 at 12:17:33PM +0300, Adrian Sevcenco wrote: ai o referinta la benchmark-ul amintit? ma gandesc ca la o asemenea diferenta de performanta ar fi iesit ditamai bruhaha-ul ... Nu e chiar un benchmark. Am migrat niște clienți Buildbot de la VirtualBox (unii cu paravirtualizare, alții fără) la KVM cu paravirtualizare. Pentru OS-uri identice, cu paravirtualizare atât în VirtualBox cât și în KVM, ăsta era sporul de viteză obținut în final pe același hardware Testele rulate în Buildbot îs suita de teste a respectivei soluții Python. Câteva zeci de mii de teste, destul de diverse, dar freacă în principal procesoarele și discurile. Softul e proprietar, nu pot publica rezultate care să poate fi reproduse independent. Dar la o căutare superficială, diferența mare de performanță pare a fi „public knowledge”: https://www.phoronix.com/scan.php?page=article=virtualbox-60-kvm=1 Super merci!! intr-adevar, convigator... Phoronix nu e o sursă foarte bună, dar ceva, ceva grăunte de adevăr e în rezultatele alea… O altă parte nasoală cu VirtualBox e că îi cam buggy, deci în timp ai mai multă bătaie de cap. Nici io n-am scăpat de tot de el, încă mai am 2 servere cu VM-uri VBox, dar nu mai adaug alte VM-uri noi pe ele și sper să scap complet de VirtualBox cândva! ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On 7/13/20 1:30 PM, Dumitru Moldovan wrote: On Mon, Jul 13, 2020 at 12:17:33PM +0300, Adrian Sevcenco wrote: On 7/13/20 11:35 AM, Dumitru Moldovan wrote: On Sat, Jul 11, 2020 at 04:31:05PM +0300, Adrian Sevcenco wrote: On 7/11/20 3:24 PM, Dumitru Moldovan wrote: 5. VBoxService nu cred că e util într-un asemenea VM. eh.. ba e :) ca ma folosesc de virtualbox pentru virtualizare, si daca vreau se se monteze fara nici un fel de serviciu implicat un share, sau sa gasesc ip-ul luat prin dhcp sau alte chestii interne masinii, am nevoie de driverul de guest de virtualbox Evident, habar n-am cum e acel setup, dar sigur vrei să folosești VirtualBox? Din câte am încercat, e o soluție slabă de virtualizare în Linux, cam cu 15% mai lentă decât KVM cu paravirtualizare într-un virtualbox-ul foloseste acelasi kvm si aceleasi mecanisme de virtualizare ca si virtsh-ul sau libvirt-ul ai o referinta la benchmark-ul amintit? ma gandesc ca la o asemenea diferenta de performanta ar fi iesit ditamai bruhaha-ul ... Nu e chiar un benchmark. Am migrat niște clienți Buildbot de la VirtualBox (unii cu paravirtualizare, alții fără) la KVM cu paravirtualizare. Pentru OS-uri identice, cu paravirtualizare atât în VirtualBox cât și în KVM, ăsta era sporul de viteză obținut în final pe același hardware Testele rulate în Buildbot îs suita de teste a respectivei soluții Python. Câteva zeci de mii de teste, destul de diverse, dar freacă în principal procesoarele și discurile. Softul e proprietar, nu pot publica rezultate care să poate fi reproduse independent. Dar la o căutare superficială, diferența mare de performanță pare a fi „public knowledge”: https://www.phoronix.com/scan.php?page=article=virtualbox-60-kvm=1 Super merci!! intr-adevar, convigator... Adrian ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On 7/13/20 1:24 PM, manuel "lonely wolf" wolfshant wrote: On 7/13/20 12:17 PM, Adrian Sevcenco wrote: On 7/13/20 11:35 AM, Dumitru Moldovan wrote: On Sat, Jul 11, 2020 at 04:31:05PM +0300, Adrian Sevcenco wrote: On 7/11/20 3:24 PM, Dumitru Moldovan wrote: 5. VBoxService nu cred că e util într-un asemenea VM. eh.. ba e :) ca ma folosesc de virtualbox pentru virtualizare, si daca vreau se se monteze fara nici un fel de serviciu implicat un share, sau sa gasesc ip-ul luat prin dhcp sau alte chestii interne masinii, am nevoie de driverul de guest de virtualbox Evident, habar n-am cum e acel setup, dar sigur vrei să folosești VirtualBox? Din câte am încercat, e o soluție slabă de virtualizare în Linux, cam cu 15% mai lentă decât KVM cu paravirtualizare într-un virtualbox-ul foloseste acelasi kvm si aceleasi mecanisme de virtualizare ca si virtsh-ul sau libvirt-ul ai o referinta la benchmark-ul amintit? ma gandesc ca la o asemenea diferenta de performanta ar fi iesit ditamai bruhaha-ul ... setup cu diverse OS-uri ce testează un server de transfer de fișiere scris în Python. În plus, licența nu e atât de permisivă precum cred unii, s-ar putea să fii în afara legii cu anumite chestii și cei de la Oracle îs scârboși la capitolul ăsta. (Nu e doar o chestie teoretică, s-a întâmplat deja în practică să dea pe unii în judecată pe tema asta). m-am oritentat dupa https://www.virtualbox.org/wiki/Licensing_FAQ si e ok pentru mine As renunta/O sa renunt la virtualbox cand solutiile native o sa imi ofere montare de fisier ca block device fara glusterfs sau alte servicii suplimentare, cad o sa pot deschide o interfata grafica la vm fara sa am nevoie de vnc/spice instalat in guest, si cel mai important, cad o sa poata sa imi foloseasca reteaua hostului in mod direct fara sa am envoie de modificari cu bridge si alte kkt-uri... Nu inteleg de ce aceste lucruri simple nu exista deja, dar realitatea e ca nu exista .. am voie sa te rog sa te uiti sa vezi cum arata reteaua de pe host cind sint pornite serviciile lui virtualbox? o sa ai o surpriza :) hint: isi face si el bridge exact la fel cum fac toate celelalte solutii de virtualizare poate isi face el undeva intern , dar nu trebuie sa modific eu setarile hostului .. singurele dev-uri le am asa (si un vm ruleaza) ALIBUILD##[Monday 13.07.20 13:32] adrian@sev : ~ $ ip -br link lo UNKNOWN00:00:00:00:00:00 enp3s0 UP b4:2e:99:3f:30:23 wg0 UNKNOWN wg1 UNKNOWN Adrian ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On Mon, Jul 13, 2020 at 12:17:33PM +0300, Adrian Sevcenco wrote: On 7/13/20 11:35 AM, Dumitru Moldovan wrote: On Sat, Jul 11, 2020 at 04:31:05PM +0300, Adrian Sevcenco wrote: On 7/11/20 3:24 PM, Dumitru Moldovan wrote: 5. VBoxService nu cred că e util într-un asemenea VM. eh.. ba e :) ca ma folosesc de virtualbox pentru virtualizare, si daca vreau se se monteze fara nici un fel de serviciu implicat un share, sau sa gasesc ip-ul luat prin dhcp sau alte chestii interne masinii, am nevoie de driverul de guest de virtualbox Evident, habar n-am cum e acel setup, dar sigur vrei să folosești VirtualBox? Din câte am încercat, e o soluție slabă de virtualizare în Linux, cam cu 15% mai lentă decât KVM cu paravirtualizare într-un virtualbox-ul foloseste acelasi kvm si aceleasi mecanisme de virtualizare ca si virtsh-ul sau libvirt-ul ai o referinta la benchmark-ul amintit? ma gandesc ca la o asemenea diferenta de performanta ar fi iesit ditamai bruhaha-ul ... Nu e chiar un benchmark. Am migrat niște clienți Buildbot de la VirtualBox (unii cu paravirtualizare, alții fără) la KVM cu paravirtualizare. Pentru OS-uri identice, cu paravirtualizare atât în VirtualBox cât și în KVM, ăsta era sporul de viteză obținut în final pe același hardware Testele rulate în Buildbot îs suita de teste a respectivei soluții Python. Câteva zeci de mii de teste, destul de diverse, dar freacă în principal procesoarele și discurile. Softul e proprietar, nu pot publica rezultate care să poate fi reproduse independent. Dar la o căutare superficială, diferența mare de performanță pare a fi „public knowledge”: https://www.phoronix.com/scan.php?page=article=virtualbox-60-kvm=1 ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On 7/13/20 12:17 PM, Adrian Sevcenco wrote: On 7/13/20 11:35 AM, Dumitru Moldovan wrote: On Sat, Jul 11, 2020 at 04:31:05PM +0300, Adrian Sevcenco wrote: On 7/11/20 3:24 PM, Dumitru Moldovan wrote: 5. VBoxService nu cred că e util într-un asemenea VM. eh.. ba e :) ca ma folosesc de virtualbox pentru virtualizare, si daca vreau se se monteze fara nici un fel de serviciu implicat un share, sau sa gasesc ip-ul luat prin dhcp sau alte chestii interne masinii, am nevoie de driverul de guest de virtualbox Evident, habar n-am cum e acel setup, dar sigur vrei să folosești VirtualBox? Din câte am încercat, e o soluție slabă de virtualizare în Linux, cam cu 15% mai lentă decât KVM cu paravirtualizare într-un virtualbox-ul foloseste acelasi kvm si aceleasi mecanisme de virtualizare ca si virtsh-ul sau libvirt-ul ai o referinta la benchmark-ul amintit? ma gandesc ca la o asemenea diferenta de performanta ar fi iesit ditamai bruhaha-ul ... setup cu diverse OS-uri ce testează un server de transfer de fișiere scris în Python. În plus, licența nu e atât de permisivă precum cred unii, s-ar putea să fii în afara legii cu anumite chestii și cei de la Oracle îs scârboși la capitolul ăsta. (Nu e doar o chestie teoretică, s-a întâmplat deja în practică să dea pe unii în judecată pe tema asta). m-am oritentat dupa https://www.virtualbox.org/wiki/Licensing_FAQ si e ok pentru mine As renunta/O sa renunt la virtualbox cand solutiile native o sa imi ofere montare de fisier ca block device fara glusterfs sau alte servicii suplimentare, cad o sa pot deschide o interfata grafica la vm fara sa am nevoie de vnc/spice instalat in guest, si cel mai important, cad o sa poata sa imi foloseasca reteaua hostului in mod direct fara sa am envoie de modificari cu bridge si alte kkt-uri... Nu inteleg de ce aceste lucruri simple nu exista deja, dar realitatea e ca nu exista .. am voie sa te rog sa te uiti sa vezi cum arata reteaua de pe host cind sint pornite serviciile lui virtualbox? o sa ai o surpriza :) hint: isi face si el bridge exact la fel cum fac toate celelalte solutii de virtualizare Ș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. Cu un mic efort se mai poate economisi și acolo ceva de compilezi doar ce ai nevoie. eh, nu stiu ce as putea economisii .. marea majoritate oricum sunt compilate ca si module .. iar module inutile nu prea imi ruleaza ca si ordine de marime, dupa un drop caches am un slab de 24MiB... my point exactly ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On 7/13/20 12:03 PM, Petru Rațiu wrote: Threadul asta e din ce in ce mai offtopic si eu astept sa vad care e X-ul lui Adrian, ca IMHO in 2020 asta cu numaratul megabitilor de memorie se aplica fie la device-uri minuscule gen rpi (dar a zis ca e vorba de VM, si nici rpi nu mai e chiar atat de #sarak), fie cand inmultesti cu un N suficient de mare, caz in care incepi sa te uiti la alte solutii mai eficiente. Sau poate e doar nostalgia de a lua la smirghel distro-ul ca in 2003... ca sa fiu ff sincer e un % destul de mare din partea cu nostalgia .. iar din punctul de vedere al mb de ram e mai degraba nostalgia de ~'96 (nu zic 93 ca pe atunci de abia vedeam la prieteni un 286 ) in plus, IMHO, mai bine offtopice decat linistea asurzitoate ;) :D Adrian ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On 7/13/20 11:35 AM, Dumitru Moldovan wrote: On Sat, Jul 11, 2020 at 04:31:05PM +0300, Adrian Sevcenco wrote: On 7/11/20 3:24 PM, Dumitru Moldovan wrote: 5. VBoxService nu cred că e util într-un asemenea VM. eh.. ba e :) ca ma folosesc de virtualbox pentru virtualizare, si daca vreau se se monteze fara nici un fel de serviciu implicat un share, sau sa gasesc ip-ul luat prin dhcp sau alte chestii interne masinii, am nevoie de driverul de guest de virtualbox Evident, habar n-am cum e acel setup, dar sigur vrei să folosești VirtualBox? Din câte am încercat, e o soluție slabă de virtualizare în Linux, cam cu 15% mai lentă decât KVM cu paravirtualizare într-un virtualbox-ul foloseste acelasi kvm si aceleasi mecanisme de virtualizare ca si virtsh-ul sau libvirt-ul ai o referinta la benchmark-ul amintit? ma gandesc ca la o asemenea diferenta de performanta ar fi iesit ditamai bruhaha-ul ... setup cu diverse OS-uri ce testează un server de transfer de fișiere scris în Python. În plus, licența nu e atât de permisivă precum cred unii, s-ar putea să fii în afara legii cu anumite chestii și cei de la Oracle îs scârboși la capitolul ăsta. (Nu e doar o chestie teoretică, s-a întâmplat deja în practică să dea pe unii în judecată pe tema asta). m-am oritentat dupa https://www.virtualbox.org/wiki/Licensing_FAQ si e ok pentru mine As renunta/O sa renunt la virtualbox cand solutiile native o sa imi ofere montare de fisier ca block device fara glusterfs sau alte servicii suplimentare, cad o sa pot deschide o interfata grafica la vm fara sa am nevoie de vnc/spice instalat in guest, si cel mai important, cad o sa poata sa imi foloseasca reteaua hostului in mod direct fara sa am envoie de modificari cu bridge si alte kkt-uri... Nu inteleg de ce aceste lucruri simple nu exista deja, dar realitatea e ca nu exista .. Mai mult, sigur ai nevoie de virtualizare? Că e un nivel de indirectare destul de gros. Poate te scoți cu ceva containerizare, nu neapărat Docker. Sau poate nici de aia nu e nevoie. da, pentru diverse servicii acum ma uit la podman, dar sunt multe cazuri in care serviciile ce le am ar avea nevoie de modificari pentru a rula in container (si nu stau sa fac asta sau nu are sens notiunea) sau nu are sens/nu ma descurc eu pentru vm-uri de build ce oricum sunt pornite doar on-demand... Ș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. Cu un mic efort se mai poate economisi și acolo ceva de compilezi doar ce ai nevoie. eh, nu stiu ce as putea economisii .. marea majoritate oricum sunt compilate ca si module .. iar module inutile nu prea imi ruleaza ca si ordine de marime, dupa un drop caches am un slab de 24MiB... Merci! Adrian ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On Lu, 13 iul 20, 11:23:57, Dumitru Moldovan wrote: > On Sun, Jul 12, 2020 at 10:46:29AM +0300, Andrei POPESCU wrote: > > > > Posibil să fie nevoie să instalezi ceva pachet în aceiași mișcare și/sau > > să forțezi dezinstalarea unui pachet Important (sau Essential ?). > > Un link se poate? Aș încerca într-un VM cu Debian 10 amd64 prima dată > oricum, dar pe cont propriu nu m-am prins ce ar fi trebuit să fac ca să > nu bușesc sistemul. Mulțam! Îmi pare rău, nu găsesc acum. Din amintiri, posibil să ai nevoie de elogind și e posibil să nu-ți iasă dacă ai ceva desktop instalat (Gnome, KDE) pentru că depind de libpam-systemd. Sugestia mea ar fi să încerci cu un sistem fără X, după care să adaugi mediul grafic. Comanda 'aptitude why systemd' poate fi extrem de utilă pentru a determina ce pachet depinde (indirect) de systemd. Spor, Andrei signature.asc Description: PGP signature ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
Threadul asta e din ce in ce mai offtopic si eu astept sa vad care e X-ul lui Adrian, ca IMHO in 2020 asta cu numaratul megabitilor de memorie se aplica fie la device-uri minuscule gen rpi (dar a zis ca e vorba de VM, si nici rpi nu mai e chiar atat de #sarak), fie cand inmultesti cu un N suficient de mare, caz in care incepi sa te uiti la alte solutii mai eficiente. Sau poate e doar nostalgia de a lua la smirghel distro-ul ca in 2003... -- P. On Mon, Jul 13, 2020 at 11:45 AM Dumitru Moldovan wrote: > On Sun, Jul 12, 2020 at 10:40:17AM +0300, Andrei POPESCU wrote: > >On Sb, 11 iul 20, 20:23:48, wo...@prolinux.ro wrote: > >> On July 11, 2020 7:56:34 PM GMT+03:00, Dumitru Moldovan > wrote: > >> > > >> >Slack merge bine de tot cu wee-slack în WeeChat. > >> Si iar recurgem la workarounduri in locul clientului nativ... > > Nu e un workaround, prefer să folosesc o interfață text pentru mail și > chat, unde lucrez în principal cu text. În plus, am alerte într-un > singur loc (indiferent că-s locale sau pe un server la distanță): în > bara de status tmux. > > > >https://xkcd.com/1782/ > > Relevant, dar nu chiar… Am avut o fază în care am preferat clienți > grafici, dar am revenit la TUI în ultimii ani, doar Firefox mai am > deschis tot timpul în paralel cu terminalul. > > BTW, Slack sucks! În echipa în care tre' să-l folosesc, aveam IRC > înainte și făcea cam aceleași lucruri pentru noi. Singura chestie > diferită e că avem acuma două canale în plus, un #general la comun cu > marketingul și un #random pentru watercooler chat. Cum e însă nevoie > în continuare de salvatul local al logurilor din chat-ul comun al > echipei tehnice, o facem tot prin IRC, cu canalul respectiv în bridge > cu cel din Slack prin Matrix… Dar mno, OMG, we are using Slack! > > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
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. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On Sun, Jul 12, 2020 at 10:40:17AM +0300, Andrei POPESCU wrote: On Sb, 11 iul 20, 20:23:48, wo...@prolinux.ro wrote: On July 11, 2020 7:56:34 PM GMT+03:00, Dumitru Moldovan wrote: > >Slack merge bine de tot cu wee-slack în WeeChat. Si iar recurgem la workarounduri in locul clientului nativ... Nu e un workaround, prefer să folosesc o interfață text pentru mail și chat, unde lucrez în principal cu text. În plus, am alerte într-un singur loc (indiferent că-s locale sau pe un server la distanță): în bara de status tmux. https://xkcd.com/1782/ Relevant, dar nu chiar… Am avut o fază în care am preferat clienți grafici, dar am revenit la TUI în ultimii ani, doar Firefox mai am deschis tot timpul în paralel cu terminalul. BTW, Slack sucks! În echipa în care tre' să-l folosesc, aveam IRC înainte și făcea cam aceleași lucruri pentru noi. Singura chestie diferită e că avem acuma două canale în plus, un #general la comun cu marketingul și un #random pentru watercooler chat. Cum e însă nevoie în continuare de salvatul local al logurilor din chat-ul comun al echipei tehnice, o facem tot prin IRC, cu canalul respectiv în bridge cu cel din Slack prin Matrix… Dar mno, OMG, we are using Slack! ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On Sat, Jul 11, 2020 at 04:31:05PM +0300, Adrian Sevcenco wrote: On 7/11/20 3:24 PM, Dumitru Moldovan wrote: 5. VBoxService nu cred că e util într-un asemenea VM. eh.. ba e :) ca ma folosesc de virtualbox pentru virtualizare, si daca vreau se se monteze fara nici un fel de serviciu implicat un share, sau sa gasesc ip-ul luat prin dhcp sau alte chestii interne masinii, am nevoie de driverul de guest de virtualbox Evident, habar n-am cum e acel setup, dar sigur vrei să folosești VirtualBox? Din câte am încercat, e o soluție slabă de virtualizare în Linux, cam cu 15% mai lentă decât KVM cu paravirtualizare într-un setup cu diverse OS-uri ce testează un server de transfer de fișiere scris în Python. În plus, licența nu e atât de permisivă precum cred unii, s-ar putea să fii în afara legii cu anumite chestii și cei de la Oracle îs scârboși la capitolul ăsta. (Nu e doar o chestie teoretică, s-a întâmplat deja în practică să dea pe unii în judecată pe tema asta). Mai mult, sigur ai nevoie de virtualizare? Că e un nivel de indirectare destul de gros. Poate te scoți cu ceva containerizare, nu neapărat Docker. Sau poate nici de aia nu e nevoie. Ș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. Cu un mic efort se mai poate economisi și acolo ceva de compilezi doar ce ai nevoie. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On Sun, Jul 12, 2020 at 10:46:29AM +0300, Andrei POPESCU wrote: On Sb, 11 iul 20, 17:03:51, Dumitru Moldovan wrote: Placa cu care mă joc e un Pine64 fără wireless, e conectată la rețea prin cablu Ethernet. Un dram de bun-simț mai e totuși în comunitatea Debian, totul a funcționat normal când am ras NetworkManager și am repornit rețeaua, dacă am configurat manual /etc/network/interfaces. Vezi https://wiki.debian.org/InstallingDebianOn/PINE64/PINEA64 dacă vrei să reinstalezi. Interesant, n-am știut de asta. Eram obișnuit cu Armbian de acum doi ani și tot acolo m-am uitat prima dată. Mulțam! Aș fi ras și systemd, `apt purge systemd` dă impresia că ar funcționa, dar instinctul mi-a zis altceva și am încercat de probă într-un VM cu un Debian 10 amd64, fără succes. Din ce citesc pe debian-user ar trebui să meargă. Posibil să fie nevoie să instalezi ceva pachet în aceiași mișcare și/sau să forțezi dezinstalarea unui pachet Important (sau Essential ?). Un link se poate? Aș încerca într-un VM cu Debian 10 amd64 prima dată oricum, dar pe cont propriu nu m-am prins ce ar fi trebuit să fac ca să nu bușesc sistemul. Mulțam! ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On Sb, 11 iul 20, 17:03:51, Dumitru Moldovan wrote: > > Placa cu care mă joc e un Pine64 fără wireless, e conectată la rețea > prin cablu Ethernet. Un dram de bun-simț mai e totuși în comunitatea > Debian, totul a funcționat normal când am ras NetworkManager și am > repornit rețeaua, dacă am configurat manual /etc/network/interfaces. Vezi https://wiki.debian.org/InstallingDebianOn/PINE64/PINEA64 dacă vrei să reinstalezi. > Aș fi ras și systemd, `apt purge systemd` dă impresia că ar funcționa, > dar instinctul mi-a zis altceva și am încercat de probă într-un VM cu > un Debian 10 amd64, fără succes. Din ce citesc pe debian-user ar trebui să meargă. Posibil să fie nevoie să instalezi ceva pachet în aceiași mișcare și/sau să forțezi dezinstalarea unui pachet Important (sau Essential ?). Spor, Andrei signature.asc Description: PGP signature ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On Sb, 11 iul 20, 20:23:48, wo...@prolinux.ro wrote: > On July 11, 2020 7:56:34 PM GMT+03:00, Dumitru Moldovan wrote: > > > >Slack merge bine de tot cu wee-slack în WeeChat. > Si iar recurgem la workarounduri in locul clientului nativ... https://xkcd.com/1782/ Salut, Andrei signature.asc Description: PGP signature ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On July 11, 2020 7:56:34 PM GMT+03:00, Dumitru Moldovan wrote: >On Sat, Jul 11, 2020 at 05:54:41PM +0300, manuel "lonely wolf" >wolfshant wrote: >>On 7/11/20 5:26 PM, Mihai Badici wrote: >>> >>> Placa cu care mă joc e un Pine64 fără wireless, e conectată la rețea prin cablu Ethernet. Un dram de bun-simț mai e totuși în >comunitatea Debian, totul a funcționat normal când am ras NetworkManager și am repornit rețeaua, dacă am configurat manual /etc/network/interfaces. Aș fi ras și systemd, `apt purge systemd` dă impresia că ar >funcționa, dar instinctul mi-a zis altceva și am încercat de probă într-un VM >cu un Debian 10 amd64, fără succes. Contrar așteptărilor din ultimii (15?) ani, sunetul în Linux nu >necesită pulseaudio. În Chromium era necesar, dar Firefox nu-i duce lipsa. >Acu' îmi dau seama că pot rade libpulse* cu totul, nu mai știu de ce l-am cruțat prima dată. Apropo, un Python minimal a trebuit să pun >înapoi pentru că aveam io nevoie de el pentru a folosi Slack în WeeChat cu wee-slack. >>>Experiența mea e că ai nevoie de pulseaudio pentru skype de pildă ( >>>slackware nu avea pulseaudio, a trebuit să "mă descurc"). De ce ai >>>nevoie de skype, ar fi o întrebare, dar în general ai... >> >> >>skype, slack. zoom. teamviewer >> > >Slack merge bine de tot cu wee-slack în WeeChat. Si iar recurgem la workarounduri in locul clientului nativ... > Pentru Skype chat >există chiar plugin de Pidgin. Stiu. Eu am intretinut o vreme rpm-ul pt CentOS. > Pentru Skype audio/video de e nevoie >se poate compensa cu telefonul. Mersi. Asa am avut alaltaieri sedinta pe chime. Video pe calculator, sunet pe mobil fiindca microfonul a refuzat sa mearga in ff. > >De Zoom și TeamViewer m-a ferit soarta până acuma. Am avut de-a face >cu >GoMeeting în schimb o vreme, bine că am scăpat. toate-s bune si frumoase cit timp alegi tu. Dar cind iti trimite clientul invite la sedinta pe Zoom/MS Teams/ whatever platform cu plugin proprietar si nu ai de ales, inca tb sa dai arm deoparte. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On Sat, Jul 11, 2020 at 05:54:41PM +0300, manuel "lonely wolf" wolfshant wrote: >On 7/11/20 5:26 PM, Mihai Badici wrote: >> >> >>>Placa cu care mă joc e un Pine64 fără wireless, e conectată la rețea >>>prin cablu Ethernet. Un dram de bun-simț mai e totuși în comunitatea >>>Debian, totul a funcționat normal când am ras NetworkManager și am >>>repornit rețeaua, dacă am configurat manual /etc/network/interfaces. >>> >>>Aș fi ras și systemd, `apt purge systemd` dă impresia că ar funcționa, >>>dar instinctul mi-a zis altceva și am încercat de probă într-un VM cu >>>un Debian 10 amd64, fără succes. >>> >>>Contrar așteptărilor din ultimii (15?) ani, sunetul în Linux nu necesită >>>pulseaudio. În Chromium era necesar, dar Firefox nu-i duce lipsa. Acu' >>>îmi dau seama că pot rade libpulse* cu totul, nu mai știu de ce l-am >>>cruțat prima dată. Apropo, un Python minimal a trebuit să pun înapoi >>>pentru că aveam io nevoie de el pentru a folosi Slack în WeeChat cu >>>wee-slack. >>Experiența mea e că ai nevoie de pulseaudio pentru skype de pildă ( >>slackware nu avea pulseaudio, a trebuit să "mă descurc"). De ce ai >>nevoie de skype, ar fi o întrebare, dar în general ai... > > >skype, slack. zoom. teamviewer > Slack merge bine de tot cu wee-slack în WeeChat. Pentru Skype chat există chiar plugin de Pidgin. Pentru Skype audio/video de e nevoie se poate compensa cu telefonul. De Zoom și TeamViewer m-a ferit soarta până acuma. Am avut de-a face cu GoMeeting în schimb o vreme, bine că am scăpat. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On 7/11/20 5:26 PM, Mihai Badici wrote: Placa cu care mă joc e un Pine64 fără wireless, e conectată la rețea prin cablu Ethernet. Un dram de bun-simț mai e totuși în comunitatea Debian, totul a funcționat normal când am ras NetworkManager și am repornit rețeaua, dacă am configurat manual /etc/network/interfaces. Aș fi ras și systemd, `apt purge systemd` dă impresia că ar funcționa, dar instinctul mi-a zis altceva și am încercat de probă într-un VM cu un Debian 10 amd64, fără succes. Contrar așteptărilor din ultimii (15?) ani, sunetul în Linux nu necesită pulseaudio. În Chromium era necesar, dar Firefox nu-i duce lipsa. Acu' îmi dau seama că pot rade libpulse* cu totul, nu mai știu de ce l-am cruțat prima dată. Apropo, un Python minimal a trebuit să pun înapoi pentru că aveam io nevoie de el pentru a folosi Slack în WeeChat cu wee-slack. Experiența mea e că ai nevoie de pulseaudio pentru skype de pildă ( slackware nu avea pulseaudio, a trebuit să "mă descurc"). De ce ai nevoie de skype, ar fi o întrebare, dar în general ai... skype, slack. zoom. teamviewer ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
Placa cu care mă joc e un Pine64 fără wireless, e conectată la rețea prin cablu Ethernet. Un dram de bun-simț mai e totuși în comunitatea Debian, totul a funcționat normal când am ras NetworkManager și am repornit rețeaua, dacă am configurat manual /etc/network/interfaces. Aș fi ras și systemd, `apt purge systemd` dă impresia că ar funcționa, dar instinctul mi-a zis altceva și am încercat de probă într-un VM cu un Debian 10 amd64, fără succes. Contrar așteptărilor din ultimii (15?) ani, sunetul în Linux nu necesită pulseaudio. În Chromium era necesar, dar Firefox nu-i duce lipsa. Acu' îmi dau seama că pot rade libpulse* cu totul, nu mai știu de ce l-am cruțat prima dată. Apropo, un Python minimal a trebuit să pun înapoi pentru că aveam io nevoie de el pentru a folosi Slack în WeeChat cu wee-slack. Experiența mea e că ai nevoie de pulseaudio pentru skype de pildă ( slackware nu avea pulseaudio, a trebuit să "mă descurc"). De ce ai nevoie de skype, ar fi o întrebare, dar în general ai... ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On Sat, Jul 11, 2020 at 04:31:05PM +0300, Adrian Sevcenco wrote: On 7/11/20 3:24 PM, Dumitru Moldovan wrote: La modul general, de ceva timp cam toate distribuțiile s-au umflat peste măsură… Chiar zilele astea experimentez cu o placă ARM64 ca desktop și uite ce a trebuit să rad dintr-o imagine Armbian de Debian 10 ca să o curăț nițel: apt purge -V libreoffice* xfce* transmission gvfs* gstreamer* \ libgtk2* gtk2-engines* libwebkit* pulseaudio* python* libcanberra* \ libgcr-base* libboost* ghostscript network-manager hostapd \ wpasupplicant iw rfkill bluez* cups* upower asta se intimpla pt ca arm-urile din cate stiu, nu pot sa booteze usb si sa aiba parte de o procedura de install normala .. altfel ai putea avea un kickstart custom cu exact ce vrei tu si nu ar mai aparea notiunea de bloatware... IMHO, arm-ul nu o sa ajunga niciodata desktop daca nu o sa suporte operatiunile normale ale unui comp. (bine ca au inceput sa apara sbc-uri ieftine x86) Never say never! E cam garantat că ARM-ul va avea o felie din piața desktop acuma că Apple va trece (complet cred) pe ARM64. Desktopul ARM Linux e funcțional de ceva ani deja… Placa asta am mai folosit-o cu succes ca desktop de backup, tot cu Armbian, dar o versiune bazată pe Ubuntu 16.04. Diferența e că acuma multe drivere îs upstream în kernel și nu mai e nevoie de kernelul ăla antic de la Allwinner. dar, daca il folosesti ca desktop, de ce scoti partea de radio (wireless/bt? nu exista?) de asemeni nici sunet nu folosesti? in plus python-ul te-as sfatui sa il lasi, sunt o gramada de tool-uri/apps bazate pe python ... Placa cu care mă joc e un Pine64 fără wireless, e conectată la rețea prin cablu Ethernet. Un dram de bun-simț mai e totuși în comunitatea Debian, totul a funcționat normal când am ras NetworkManager și am repornit rețeaua, dacă am configurat manual /etc/network/interfaces. Aș fi ras și systemd, `apt purge systemd` dă impresia că ar funcționa, dar instinctul mi-a zis altceva și am încercat de probă într-un VM cu un Debian 10 amd64, fără succes. Contrar așteptărilor din ultimii (15?) ani, sunetul în Linux nu necesită pulseaudio. În Chromium era necesar, dar Firefox nu-i duce lipsa. Acu' îmi dau seama că pot rade libpulse* cu totul, nu mai știu de ce l-am cruțat prima dată. Apropo, un Python minimal a trebuit să pun înapoi pentru că aveam io nevoie de el pentru a folosi Slack în WeeChat cu wee-slack. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On Sb, 11 iul 20, 16:31:05, Adrian Sevcenco wrote: > > asta se intimpla pt ca arm-urile din cate stiu, nu pot sa booteze usb si sa > aiba parte de o procedura de install normala .. altfel ai putea avea un > kickstart custom cu exact ce vrei tu si nu ar mai aparea notiunea de > bloatware... Lumea s-a obișnuit așa de tare cu imaginile preconfigurate că nici nu se mai uită la opțiunile de instalare (Debian are). > IMHO, arm-ul nu o sa ajunga niciodata desktop daca nu o sa > suporte operatiunile normale ale unui comp. (bine ca au inceput sa apara > sbc-uri ieftine x86) Există sisteme ARM64 cu UEFI și ACPI. În principiu se pare că ai de ales între firmware proprietar cu bug-uri care probabil nu se vor rezolva niciodată sau suport în U-BOOT / Linux inclus când hardware-ul respectiv deja nu prea mai face față la cerințele actuale. Salut, Andrei signature.asc Description: PGP signature ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On 7/11/20 3:24 PM, Dumitru Moldovan wrote: On Fri, Jul 10, 2020 at 09:48:44PM +0300, Adrian Sevcenco wrote: Salutare! Doresc sa vad cat de mult pot reduce consumul de memorie de sistem (adica ignorand serviciile pentru care e facut vm-ul) si cam ce mi-a mai ramas[1] e postfixul Prezenta acestuia e doar pentru trimiterea mailurilor de notificari de la diverse servicii din sistem, fie local fie la alt server Se poate face ceva? sau am ajuns la minim? Se mai poate face optimiza ceva la [1]? (nu doresc flame legate de systemd asa ca pe acela ignorati-l) si nici dbus-ul nu se poate scoate ca e legat de systemd Multumesc! Adrian [1] [root@el7build ~]# ps_mem Private + Shared = RAM used Program 176.0 KiB + 116.0 KiB = 292.0 KiB agetty 232.0 KiB + 167.5 KiB = 399.5 KiB atd 624.0 KiB + 183.0 KiB = 807.0 KiB auditd 780.0 KiB + 141.5 KiB = 921.5 KiB irqbalance 696.0 KiB + 281.5 KiB = 977.5 KiB crond 856.0 KiB + 150.0 KiB = 1.0 MiB systemd-logind 920.0 KiB + 144.0 KiB = 1.0 MiB systemd-networkd 1.4 MiB + 136.0 KiB = 1.5 MiB chronyd 1.0 MiB + 543.0 KiB = 1.6 MiB dbus-daemon 1.5 MiB + 205.0 KiB = 1.7 MiB systemd-journald 1.2 MiB + 526.0 KiB = 1.7 MiB master 1.5 MiB + 196.0 KiB = 1.7 MiB bash 1.3 MiB + 506.0 KiB = 1.8 MiB VBoxService 1.3 MiB + 984.0 KiB = 2.2 MiB pickup 1.3 MiB + 987.0 KiB = 2.3 MiB qmgr 2.7 MiB + 1.1 MiB = 3.8 MiB systemd-udevd 3.3 MiB + 2.9 MiB = 6.2 MiB sshd (2) 5.1 MiB + 1.1 MiB = 6.2 MiB systemd - 36.1 MiB Woo-hoo, my time to shine… :-] Salut si merci de info suplimentar :) În plus față de ce s-a mai zis despre postfix/chronyd/crond: nu am apucat sa spun mai sus dar nu pot scoate chrony ca cei de la rhel nu au compilat/bagat si timesyncd-ul iar de cron nu pot scapa ca imi e peste mana pentru fiecare script de rulat sa fac si un .timer si un .service 1. De nu folosești at(1), poți opri și dezactiva atd. corect! 2. De nu folosești ausearch(8)/aureport(8), la fel pentru auditd. eh.. le mai folosesc ... unele vm-uri sunt publice si ma mai uit la ce se intimpla .. ma mai gandesc la asta .. 3. irqbalance e util doar de ai mai mult de un procesor. da asa e .. dar am si vm-uri de build ce ajung la 4-6 coreuri... 4. OpenSSH poate fi înlocuit cu ceva mai ușurel precum Dropbear. corect.. inca nu am evaluat daca ma folosesc ceva in ssh ce mi-ar lipsi in dropbear... merci! il trec pe lista :) 5. VBoxService nu cred că e util într-un asemenea VM. eh.. ba e :) ca ma folosesc de virtualbox pentru virtualizare, si daca vreau se se monteze fara nici un fel de serviciu implicat un share, sau sa gasesc ip-ul luat prin dhcp sau alte chestii interne masinii, am nevoie de driverul de guest de virtualbox Nu știu de e relevant pentru situația ta, dar bash e un shell ce consumă cam multe resurse, poți încerca și altele mai ușurele. În ultima vreme din pacate asta nu se poate ca toate scripturile mele sunt bash (4+) îmi plac ksh-ul din OpenBSD, dar poți înlocui mai multe chestii o dată de folosești BusyBox, care are un shell integrat ce pare OK. La modul general, de ceva timp cam toate distribuțiile s-au umflat peste măsură… Chiar zilele astea experimentez cu o placă ARM64 ca desktop și uite ce a trebuit să rad dintr-o imagine Armbian de Debian 10 ca să o curăț nițel: apt purge -V libreoffice* xfce* transmission gvfs* gstreamer* \ libgtk2* gtk2-engines* libwebkit* pulseaudio* python* libcanberra* \ libgcr-base* libboost* ghostscript network-manager hostapd \ wpasupplicant iw rfkill bluez* cups* upower asta se intimpla pt ca arm-urile din cate stiu, nu pot sa booteze usb si sa aiba parte de o procedura de install normala .. altfel ai putea avea un kickstart custom cu exact ce vrei tu si nu ar mai aparea notiunea de bloatware... IMHO, arm-ul nu o sa ajunga niciodata desktop daca nu o sa suporte operatiunile normale ale unui comp. (bine ca au inceput sa apara sbc-uri ieftine x86) dar, daca il folosesti ca desktop, de ce scoti partea de radio (wireless/bt? nu exista?) de asemeni nici sunet nu folosesti? in plus python-ul te-as sfatui sa il lasi, sunt o gramada de tool-uri/apps bazate pe python ... + încă alte câteva mărunțișuri… Totul merge în continuare decent, am mai mult RAM pentru navigator și lucrurile au devenit ceva mai predictibile și ușor de depanat. În sfârșit pot pune monitorul în așteptare cu xset când mă ridic de la birou! Revenind la ideea cu distribuțiile obeze, Alpine Linux e o soluție interesantă într-un scenariu în care resursele hw contează mult. Diferența față de un RHEL este mare. posibil dar eu am niste restrictii date de comunitate (comunitatea stiintifica)... standardul e EL7 si se chinuiesc din greu sa adapteze software-urile pentru 8 Multumesc pentru idei! Adrian
Re: [rlug] minimal vm :: postfix replacement?
On Fri, Jul 10, 2020 at 09:48:44PM +0300, Adrian Sevcenco wrote: Salutare! Doresc sa vad cat de mult pot reduce consumul de memorie de sistem (adica ignorand serviciile pentru care e facut vm-ul) si cam ce mi-a mai ramas[1] e postfixul Prezenta acestuia e doar pentru trimiterea mailurilor de notificari de la diverse servicii din sistem, fie local fie la alt server Se poate face ceva? sau am ajuns la minim? Se mai poate face optimiza ceva la [1]? (nu doresc flame legate de systemd asa ca pe acela ignorati-l) si nici dbus-ul nu se poate scoate ca e legat de systemd Multumesc! Adrian [1] [root@el7build ~]# ps_mem Private + Shared = RAM used Program 176.0 KiB + 116.0 KiB = 292.0 KiB agetty 232.0 KiB + 167.5 KiB = 399.5 KiB atd 624.0 KiB + 183.0 KiB = 807.0 KiB auditd 780.0 KiB + 141.5 KiB = 921.5 KiB irqbalance 696.0 KiB + 281.5 KiB = 977.5 KiB crond 856.0 KiB + 150.0 KiB = 1.0 MiB systemd-logind 920.0 KiB + 144.0 KiB = 1.0 MiB systemd-networkd 1.4 MiB + 136.0 KiB = 1.5 MiB chronyd 1.0 MiB + 543.0 KiB = 1.6 MiB dbus-daemon 1.5 MiB + 205.0 KiB = 1.7 MiB systemd-journald 1.2 MiB + 526.0 KiB = 1.7 MiB master 1.5 MiB + 196.0 KiB = 1.7 MiB bash 1.3 MiB + 506.0 KiB = 1.8 MiB VBoxService 1.3 MiB + 984.0 KiB = 2.2 MiB pickup 1.3 MiB + 987.0 KiB = 2.3 MiB qmgr 2.7 MiB + 1.1 MiB = 3.8 MiB systemd-udevd 3.3 MiB + 2.9 MiB = 6.2 MiB sshd (2) 5.1 MiB + 1.1 MiB = 6.2 MiB systemd - 36.1 MiB Woo-hoo, my time to shine… :-] În plus față de ce s-a mai zis despre postfix/chronyd/crond: 1. De nu folosești at(1), poți opri și dezactiva atd. 2. De nu folosești ausearch(8)/aureport(8), la fel pentru auditd. 3. irqbalance e util doar de ai mai mult de un procesor. 4. OpenSSH poate fi înlocuit cu ceva mai ușurel precum Dropbear. 5. VBoxService nu cred că e util într-un asemenea VM. Nu știu de e relevant pentru situația ta, dar bash e un shell ce consumă cam multe resurse, poți încerca și altele mai ușurele. În ultima vreme îmi plac ksh-ul din OpenBSD, dar poți înlocui mai multe chestii o dată de folosești BusyBox, care are un shell integrat ce pare OK. La modul general, de ceva timp cam toate distribuțiile s-au umflat peste măsură… Chiar zilele astea experimentez cu o placă ARM64 ca desktop și uite ce a trebuit să rad dintr-o imagine Armbian de Debian 10 ca să o curăț nițel: apt purge -V libreoffice* xfce* transmission gvfs* gstreamer* \ libgtk2* gtk2-engines* libwebkit* pulseaudio* python* libcanberra* \ libgcr-base* libboost* ghostscript network-manager hostapd \ wpasupplicant iw rfkill bluez* cups* upower + încă alte câteva mărunțișuri… Totul merge în continuare decent, am mai mult RAM pentru navigator și lucrurile au devenit ceva mai predictibile și ușor de depanat. În sfârșit pot pune monitorul în așteptare cu xset când mă ridic de la birou! Revenind la ideea cu distribuțiile obeze, Alpine Linux e o soluție interesantă într-un scenariu în care resursele hw contează mult. Diferența față de un RHEL este mare. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On 7/11/20 12:54 PM, Andrei POPESCU wrote: On Vi, 10 iul 20, 21:48:44, Adrian Sevcenco wrote: Salutare! Doresc sa vad cat de mult pot reduce consumul de memorie de sistem (adica ignorand serviciile pentru care e facut vm-ul) si cam ce mi-a mai ramas[1] e postfixul Prezenta acestuia e doar pentru trimiterea mailurilor de notificari de la diverse servicii din sistem, fie local fie la alt server Se poate face ceva? sau am ajuns la minim? Se mai poate face optimiza ceva la [1]? (nu doresc flame legate de systemd asa ca pe acela ignorati-l) Poate reușești să scapi de cron (timere systemd) și chrony (systemd-timesyncd, dacă nu ai nevoie de partea de server). corect!!! timerele nu prea sunt functionale ca nu pot rula decat un serviciu deja existent dar de chrony sigur pot scapa Merci! Adrian ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On Vi, 10 iul 20, 21:48:44, Adrian Sevcenco wrote: > Salutare! Doresc sa vad cat de mult pot reduce consumul de memorie de sistem > (adica ignorand serviciile pentru care e facut vm-ul) > si cam ce mi-a mai ramas[1] e postfixul > Prezenta acestuia e doar pentru trimiterea mailurilor de notificari de la > diverse servicii din sistem, fie local fie la alt server > Se poate face ceva? sau am ajuns la minim? > Se mai poate face optimiza ceva la [1]? (nu doresc flame legate de systemd > asa ca pe acela ignorati-l) Poate reușești să scapi de cron (timere systemd) și chrony (systemd-timesyncd, dacă nu ai nevoie de partea de server). > 176.0 KiB + 116.0 KiB = 292.0 KiB agetty > 232.0 KiB + 167.5 KiB = 399.5 KiB atd > 624.0 KiB + 183.0 KiB = 807.0 KiB auditd > 780.0 KiB + 141.5 KiB = 921.5 KiB irqbalance > 696.0 KiB + 281.5 KiB = 977.5 KiB crond > 856.0 KiB + 150.0 KiB = 1.0 MiB systemd-logind > 920.0 KiB + 144.0 KiB = 1.0 MiB systemd-networkd > 1.4 MiB + 136.0 KiB = 1.5 MiB chronyd > 1.0 MiB + 543.0 KiB = 1.6 MiB dbus-daemon > 1.5 MiB + 205.0 KiB = 1.7 MiB systemd-journald > 1.2 MiB + 526.0 KiB = 1.7 MiB master > 1.5 MiB + 196.0 KiB = 1.7 MiB bash > 1.3 MiB + 506.0 KiB = 1.8 MiB VBoxService > 1.3 MiB + 984.0 KiB = 2.2 MiB pickup > 1.3 MiB + 987.0 KiB = 2.3 MiB qmgr > 2.7 MiB + 1.1 MiB = 3.8 MiB systemd-udevd > 3.3 MiB + 2.9 MiB = 6.2 MiB sshd (2) > 5.1 MiB + 1.1 MiB = 6.2 MiB systemd > - > 36.1 MiB Spor, Andrei signature.asc Description: PGP signature ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On 7/11/20 3:19 AM, manuel "lonely wolf" wolfshant wrote: On 7/10/20 10:20 PM, Mihai Badici wrote: dar nu am studiat exact cum funcționează dbus, dacă interceptează doar modificările hardware sau mai mult de atât. dbus e mult mai mult de atit Da, după asta am mai citit și eu, dar mi-am dat cu părerea înainte, ca românul :) Așa, dacă vrea și vrea, doar de amorul artei, poate muta și cron-ul în exterior ( dacă e container, îl rulează cu docker run când are nevoie :)) . Routerele astea de 100 de RON cu linux embeded, openwrt sau variante, nu prea au cron-ul pornit by default. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On 7/10/20 10:20 PM, Mihai Badici wrote: dar nu am studiat exact cum funcționează dbus, dacă interceptează doar modificările hardware sau mai mult de atât. dbus e mult mai mult de atit ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
Ar mai fi si dma[1] care inteleg ca are si coada, dar arunca inainte un ochi prin Issues sa vezi daca nu te afecteaza ceva de acolo. [1] https://github.com/corecode/dma On Fri, Jul 10, 2020 at 10:21 PM Mihai Badici wrote: > > On 7/10/20 10:09 PM, manuel "lonely wolf" wolfshant wrote: > > On 7/10/20 9:48 PM, Adrian Sevcenco wrote: > >> Salutare! Doresc sa vad cat de mult pot reduce consumul de memorie de > >> sistem (adica ignorand serviciile pentru care e facut vm-ul) > >> si cam ce mi-a mai ramas[1] e postfixul > >> Prezenta acestuia e doar pentru trimiterea mailurilor de notificari > >> de la diverse servicii din sistem, fie local fie la alt server > >> Se poate face ceva? sau am ajuns la minim? > >> Se mai poate face optimiza ceva la [1]? (nu doresc flame legate de > >> systemd asa ca pe acela ignorati-l) > >> si nici dbus-ul nu se poate scoate ca e legat de systemd > > Și eu subscriu la ssmtp, mai ales dacă e virtuală nu prea o să pierzi > conexiunea cu host-ul, unde se presupune că rulezi un MTA adevărat, ca > să îți pară rău de coadă. Depinde cât de tare îți dorești să scapi de > ele :) În principiu dacă e vm nu ai avea nevoie să rulezi un proces > care să vadă ce plăci ai mai înfipt în sistem, dar nu am studiat exact > cum funcționează dbus, dacă interceptează doar modificările hardware sau > mai mult de atât. Oricum însuși faptul că rulezi virtuale înseamnă > consum în plus de memorie pe host :) > > > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On 7/10/20 10:09 PM, manuel "lonely wolf" wolfshant wrote: On 7/10/20 9:48 PM, Adrian Sevcenco wrote: Salutare! Doresc sa vad cat de mult pot reduce consumul de memorie de sistem (adica ignorand serviciile pentru care e facut vm-ul) si cam ce mi-a mai ramas[1] e postfixul Prezenta acestuia e doar pentru trimiterea mailurilor de notificari de la diverse servicii din sistem, fie local fie la alt server Se poate face ceva? sau am ajuns la minim? Se mai poate face optimiza ceva la [1]? (nu doresc flame legate de systemd asa ca pe acela ignorati-l) si nici dbus-ul nu se poate scoate ca e legat de systemd Și eu subscriu la ssmtp, mai ales dacă e virtuală nu prea o să pierzi conexiunea cu host-ul, unde se presupune că rulezi un MTA adevărat, ca să îți pară rău de coadă. Depinde cât de tare îți dorești să scapi de ele :) În principiu dacă e vm nu ai avea nevoie să rulezi un proces care să vadă ce plăci ai mai înfipt în sistem, dar nu am studiat exact cum funcționează dbus, dacă interceptează doar modificările hardware sau mai mult de atât. Oricum însuși faptul că rulezi virtuale înseamnă consum în plus de memorie pe host :) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] minimal vm :: postfix replacement?
On 7/10/20 9:48 PM, Adrian Sevcenco wrote: Salutare! Doresc sa vad cat de mult pot reduce consumul de memorie de sistem (adica ignorand serviciile pentru care e facut vm-ul) si cam ce mi-a mai ramas[1] e postfixul Prezenta acestuia e doar pentru trimiterea mailurilor de notificari de la diverse servicii din sistem, fie local fie la alt server Se poate face ceva? sau am ajuns la minim? Se mai poate face optimiza ceva la [1]? (nu doresc flame legate de systemd asa ca pe acela ignorati-l) si nici dbus-ul nu se poate scoate ca e legat de systemd uite-te la ssmtp ( atentie, nu e daemon; face relay dar nu stie sa stocheze mesaje local si sa faca delivey ulterior ), esmtp , msmtp si OpenSMTPD ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
