RPM helyett kézi fordítás (kernel, apache, nginx, php, stb...), sebességnövelés céljából és biztonsági szempontból?

Red Hat, Fedora, CentOS

Nekem a CentOS-ben az egyik fontos és hasznos szolgáltatás, hogy yum használattal könnyű kezelni a frissítéseket, még a kernel frissítést is. Szerencsére szinte mindent meg lehet oldani kézi forrásból fordítás nélkül.

A mai napig olvasom, hallom, hogy sokan a sebességnövelés céljából kézzel fordítják le kernelt, a web szervert (apache, nginx) és a PHP-t.
A másik ok, ami szerepelni szokott, hogy egy biztonsági javítást hamarabb tudnak felrakni így, mint ahogy kijön a csomag.
Az utóbbit megértem, csak kérdés, hogy megéri az időráfordítást?
A rendszeres csomagfordítás mennyire "szemeteli tele" a gépet jelenleg?

Valaki szánta már rá az idejét, hogy lemérje egy alap x86_64-es CentOS csomag és egy kézzel fordított alkalmazás között a sebesség különbséget? De még ha gyorsabb is lenne, megéri szerintetek 2014 szeptemberben is kézzel fordítani CentOS 7-re csomagokat, ha tökéletesen megfelelő a hivatalos update-ben rendelkezésre álló rpm is a feladatra?

Ezen KaTTogtam.

  • 7913 megtekintés

( locsemege v | 2014. 09. 17., sze – 02:13 )

Régebben, azaz mondjuk 12 éve még gyakran fordítottam kernelt, elsősorban valamilyen kernelmodul miatt. Manapság gyakorlatilag minden elérhető bináris csomagban, nem nyernél semmit a fordítással, csak veszítenél egy csomó időt. Gondolj arra, hogy a forrásból fordítás miatt buknád a csomagkezelő függőségkezelését. Ha minden áron fordítani vágysz, akkor használj forrás alapú disztribúciót, mint amilyen a Gentoo.

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

Igen, én is kb így gondolom, amiket írtál, pont ezért nem értem, hogy Ubuntu vagy Debian esetében sokan miért fordítanak kézzel kernelt, web szervert, php-t, ha az alapot használják.

Aki ezt mondta, hogy ilyet csinál, szerintük megbízhatóbb és gyorsabb, amit ők fordítanak, valamint hamarabb tudják a patch-eket felrakni, de engem nem győztek meg, hogy ennek lenne értelme, kivéve ha sok a szabadidőm és nincs mivel kitölteni.

Sakk-matt,
KaTT :)

+1 locsemegének.

annyit hozzá tennék, hogy debiannak mániája a félmegoldás vagy nem tudom minek nevezzem. Vannak olyan dolgok, amit nem tesznek bele a kernelbe, de a csomagtárába beletolják a patcheket ilyen pl a grsecurity. Ha debianon ezt szeretnéd használni, akkor pathcelni kell a kernelt és újrafordítani.

Én 3-4 éve próbálkoztam debianon az optimalizációval. Még automatizáltam is az apt-tot (milyen okos jószág az apt) rögtön a forrást szedte le és legyártotta a csomagot. Az eredmény? Nem igazán vettem észre a különbséget. Valószínű csak egy gyengébb konfiguráción van jelentősége, akkoriban egy core I3-as proci meg 6 GB DDR3-as pc-n teszteltem.

***********************************************************************

Aláírás szerzői jogok megsértése miatt TÖRÖLVE

DEBIAN forevör!

Itt bizony keveredes van. Egyreszt manapsag statikusan nagyon nem szokas linkelni libekhez, igy nem kell(ene) mindent ujraforditani. Masreszt az eredeti kerdesfeltevo is lyukra futhatott a kerdes kontextusaban: ki mit ert kezzel forditas alatt? './configure; make install' minden gepen? Na, ilyet biztos nem csinalnek dedikalt konteneren kivul, 2-3 gepnel tobb eseteben. RPM-alapu disztroknal SRPM eloszed, C/C++/linker opciok hozzaadasa a spec file-hoz, sajat patchek, stb. odapakolasa, aztan rpmbuild, es az elkeszult csomagokat ki lehet szorni a gepekre, akar kozponti yum repon keresztul, tobbe-kevesbe automatizalva. Persze ez feltetelezi, hogy ugyanazok a forditasi opciok optimalisak minden gepen, ami a mai CPU-kavalkadnal nem feltetlenul igaz, de viszonylag keves program van, ami ki tudja hasznalni az uj utasitasokat (amiket persze a forditoprogramnak es az eszkozeinek is tamogatnia kell).

Szerencsére már nem kell saját gépen fordítani, és általában meg is osztja a fordítás
eredményét aki erre vetemedik, pl. Ubuntunál PPA-k formájában (private apt repository)...

Szóval aki csinál valamit azt mindjárt többen is tudják használni, ott már megéri a fáradságot...

( uzsolt v | 2014. 09. 18., cs – 11:49 )

Mit szeretnél a kézzel fordítással elérni?
Sebességnövekedés? A mai, (10 évvel ezelőtti szemmel nézve) gyors gépek korában az a 0.1 másodperc nem sokat ér. Ha mégis valaki erre veri az epéniszét, gondolj arra, hogy a hivatalos csomagokról csúszik le, állandóan nézni kell az adott program honlapját, jött-e újabb verzió. Valamint a patch-eket is folyamatosan ellenőriznie kell.

Az alapértelmezettől eltérő funkciók? Ha kevesebb funkciót (és ezáltal kevesebb függőséget) akarsz, akkor el kell gondolkodni arról, hogy az a 2-300 megával kevesebb foglalt hely megéri-e a fentebb vázolt macerát.
Több funkció: akkor inkább a spec-fájlt írd át, de akkor is a fentebb vázolt macera fennáll.

Hamarabb jönnek a biztonsági patch-ek? Szintén a fentebbi macera egyrészt, másrészt az az egy-két napon nagyon sok múlik? Ha pl. olyan szerver, ami csak belső hálózatról érhető el... stb.

Tehát lehet választani: forrásból ordítgatni, fentebbi macera, epénisz, vagy pedig egyszerű, normál 'yum update', pár perc, és szevasz.

Én is kb erre jutottam, kb így látom.

Azért én még várok olyan hozzászólásra, aki Debian/Ubuntu/CentOS alatt fordíthatja a csomagokat kézzel, rendszeresen, ami bár rpm/drb-ben is elérhető, de valami miatt mégis manuálisan csinálja, mert valamiért a kézzel fordított alkalmazást jobban szereti, mint a csomagban kapottat. Kíváncsi vagyok a mozgató rugókra, pusztán ezért.

Sakk-matt,
KaTT :)

> A mai, (10 évvel ezelőtti szemmel nézve) gyors gépek korában az a 0.1 másodperc nem sokat ér.
SOHO-ban legalábbis, de enterprise-ban elég kimutatható költsége lehet. Nekem van egy szívemhez közeli WS a cégnél, amit 24/7 hajtanak, elég bonyolult számításokat végez, bizonyos függvényei adatbázist is írnak, de kb. 100 request/second alatt üres marad a queue.

Na most ha (a sarkított példában) ez a futtatás 0,1 seccel rövidebb lehetne, akkor effektíve végtelen mennyiségű :) százszor annyi requestet lehetne kiszolgálni.

A sebességnövekedés hasznos ott ahol az kell. Én pl numerikus fizikával foglalkozom. Egy optimalizált kód és nem optimalizált kód között jópár % a különbség. Na nekem egy szimulációs idő egy core7-es gépen 8-magon kb 1-2 nap. Nem mindegy, hogy még este befejezi, amikor regger érkezem ott az eredmény vagy csak a "műszak közepére". Egy asztali gépnél szerintem nem éri meg a vacaolás, egy szervernél talán, egy numerikus matematikai projektnél pedig szerintem kötelező (persze ott ahol nem percek a mérvadóak).

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

(gelei-nek is)
Igen, ez a nüansznyi sebességnövekedés sokszor igenis számít, de azok (ahogy gelei is írta eggyel feljebb) már nem a SOHO-kategória. Tudom, gondolatolvasók nem vagytok (kiolvastam a gondolataitokból :) ), de alapvetően ilyen "klasszikus" esetekre gondoltam, mikor a fentebbi soraimat írtam (tehát általános desktop-használat, vagy egy egyszerű, általános, nem "túlterhelt" bármilyen-szerver).

( KissT | 2014. 09. 24., sze – 08:28 )

Szerintem azt sem szabad kihagyni a kepletbol, hogy mennyire ertesz a konkret csomaghoz amit ujra akarsz forditani, ha nem tudod kivulrol belulrol, es ismered szinte az osszes kapcsolot, az optimalis conf megtalalasa is gondot okozhat, en kobo egy-masfel eve forditottam kernel-t, driver miatt, de be kell valjam hogy heteket elcsesztem vele mire veginyalaztam az osszes beallitast, mert ha nem tudtam hogy epp mi-micsoda akkor google es rtfm, szoval ez sem elhanyagolhato tenyezo.

( sigellef | 2014. 09. 24., sze – 14:22 )

Bizonyos programoknál bizonyos gépeken bizonyos CFLAG-ek rengeteget tudnak gyorsítani. pl. egy bash lefordítva -O3 ... -minline-all-stringops optimizálással bizonyos esetekben 2-4-szeres(!) sebességet is képes produkálni, mintha simán -O2-vel fordítod.

Kérdés, megéri-e egy adott gépre tervezni linuxot. Nemrégiben végigcsináltam forrásból egy egész Linuxot. Több, mint másfél évig tartott. Ha kedvtelésből csinálod, megéri, sokat lehet vele tanulni.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

Pl. a glib2... ha azt -O3-mal fordítom, akkor minden ami arra épül, segfaultol.

A bash akkor mutatja ezt a gyorsulást, ha egy olyan shell scriptet futtatunk alatta, ahol egymásba ágyazott ciklusokban függvényeket hívogatunk, és a futási idejük percekben mérhetőek.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

A bash akkor mutatja ezt a gyorsulást, ha egy olyan shell scriptet futtatunk alatta, ahol egymásba ágyazott ciklusokban függvényeket hívogatunk, és a futási idejük percekben mérhetőek.

Ez tipikus eset? Mértél is már ilyet vagy csak hasraütésszerűen mondod? A disztrók csomagolói ezt nem tudják, azért nem így fordítják?
De még ha így is lenne, azért ez nem tipikus felhasználás - egy egyszerű felhasználó ebből az állítólagos gyorsulásból semmit nem fog érzékelni - cserébe szenved a fordítással és karbantartással.

(Persze azért az a kérdés is felmerül, hogy perces futási idejű bash-szkriptet nem lehetne kiváltani valami hatékonyabb megoldással, más nem, egy C programmal?)

A csomagot azért nem optimizálják túlzottan, hogy rendesen fusson minden x86 processzoron, minden körülmények között (már amelyik disztribeket ilyen gépekre adnak).
Ilyen esetben vagy -O2 vagy -Os. A -O2 minden olyan optimalizációt tartalmaz, ami gyorsít, és "biztonságos". Az -Os pedig minden olyat, ami csökkenti a gépi kód méretét, és "biztonságos". A disztribeknél ezért nem mennek ennél sokkal tovább.

Fordítgatni akkor érdemes, ha egy adott alkalmazást adott egy adott gépre akarunk optimizálni. Pl. a cégnél sok videókonvertálást végzünk, (helyi tv), és itt megcsináltam egy gépen, hogy az ffmpeg, mencoder, avidemux programokat, és minden függőségüket (gyakorlatilag az összes multimédiás library) optimizáltam. A javulás mérhető, és lényeges, formátumtól függően az alapesethez képest 10-20%, dvavi-nál kisebb, mpeg/divx-nél nagyobb a gyorsulás. A hátulütő az lett, hogy az addig többé-kevésbé jól működő cinelerra hibái megszaporodtak a használhatatlanságig. Hiába fordítottam újra, többféle optimizációval, nem lehetett használhatóvá tenni. Szerencsére ezen a gépen ezt a progit nem kell használni, így hát maradhat a gyors konvertáló.
A mencoder/mplayer-nél bizonyos részek alapból -O3 -mal vannak optimizálva.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

A csomagot azért nem optimizálják túlzottan, hogy rendesen fusson minden x86 processzoron, minden körülmények között (már amelyik disztribeket ilyen gépekre adnak).

Én a 2-4-szeres sebességű bash-t kérdeztem.

A javulás mérhető, és lényeges, formátumtól függően az alapesethez képest 10-20%, dvavi-nál kisebb, mpeg/divx-nél nagyobb a gyorsulás.

A 10-20%-os sebességnövekedés még mindig semmi a 2-4-szeres bash gyorsuláshoz képest! Ezt a 2-4-szeres bash-gyorsulást vitatom - de ha megmondod, egyszer és másszor milyen opciókkal fordítsam, adsz egy bash-szkriptet, szívesen lemérem.
A 10-20% pedig belefér, régebben, mikor több időm volt, próbálgattam is ilyeneket.

A hátulütő az lett, hogy az addig többé-kevésbé jól működő cinelerra hibái megszaporodtak a használhatatlanságig. Hiába fordítottam újra, többféle optimizációval, nem lehetett használhatóvá tenni.

Erről beszéltem.

( Dwokfur v | 2014. 09. 24., sze – 14:46 )

A fő kérdés, hogy mennyi időt szánnál a projektre?
Ha van sok időd, akkor használj forrás alapú disztrót.
Szerintem egy LAMP oldal sebesség növekedése nem azon fog múlni, hogy milyen flag-ekkel fordítottad a PHP-t. Persze nem akarlak lebecsülni - lehet, hogy olyan szerverfarmod van, ahol számít az -funroll-loops. Lehet, hogy egy bash -O3-mal 2x gyorsabb egyes feladatok megoldására, de más programok meg elhasalnak vele.
Szóval mennyi időd van?...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."