t4t4v4 3 Zgłoś post Napisano Wrzesień 8, 2014 Witajcie,Mam Debiana 6.0.9 i zastanawiam się, czy warto zaktualizować kernel do serii 3.14 ? Czy przyniesie to korzyści wydajnościowe i poprawi w pewien sposób bezpieczeństwo?Może lepiej skorzystać z serii 3.16 ? Udostępnij ten post Link to postu Udostępnij na innych stronach
Gość mariaczi Zgłoś post Napisano Wrzesień 8, 2014 Wpierw może warto byłoby zaktualizować system, a potem dopiero myśleć o krenelu. Udostępnij ten post Link to postu Udostępnij na innych stronach
spindritf 240 Zgłoś post Napisano Wrzesień 8, 2014 Tak. Nie aktualizuj samego tylko kernela. Wydajność poprawia się w zasadzie z każdą wersją, chociaż czasem zdarzy im się obsuwa. Natomiast patche na problemy z bezpieczeństwem powinny być backportowane, tutaj nie korzystasz. Podstawowy problem z aktualizacjami to oczywiście ryzyko, że jakaś aplikacja, na której polegasz, się rozjedzie. Poza tym, zazwyczaj im nowszy system, tym lepiej. Udostępnij ten post Link to postu Udostępnij na innych stronach
SanKen 63 Zgłoś post Napisano Wrzesień 9, 2014 A ja mam takie pytanie. Może to podstawy,ale trudno zapytam. Czy kompilowanie kernela np na VB i wrzucenie go na VPS/dedyk robi jaką różnicę ? Chciałem się pobawić i skompilowałem sobie kernel na virtualbox, działa. Ale czy mogę go wrzucić na serwer i będzie działał ? Pakiety .deb Udostępnij ten post Link to postu Udostępnij na innych stronach
Pan Kot 1535 Zgłoś post Napisano Wrzesień 9, 2014 (edytowany) Tak, pod kilkoma warunkami: 1. Kernel wspiera architekturę na którą jest kompilowany. 64-bitowy kernel nie pójdzie na x86. 2. Kernel wspiera dany procesor, opcja wspieranych procesorów jest domyślnie ukryta (wymagany tryb expert), więc pewno ok. 3. Kernel wspiera wszystkie specyficzne dla twojej maszyny moduły. Trzeci punkt jest najtrudniejszy, bo jest to taka mała ruletka w przypadku dedyków. OVH na ten przykład udostępnia configi do kerneli, które dostarczają, przez co możesz być pewny, że startowy config jest już odpowiednio zoptymalizowany pod ich sprzęt, czyli wywalili to co zbędne. Współczesne domyślne kernele systemów operacyjnych to jedna wielka bańka modularna. Kernel ma wsparcie dla prawie wszystkich podzespołów, urządzeń i konfiguracji, ale ładuje tylko te moduły, które są w danej chwili potrzebne. Oczywiście możesz wziąć takowy kernel i samemu skompilować, ale będzie on po prostu wolny, duży, i będzie się wolno kompilował. Jednym z lepszych pomysłów jest zanotowanie jakie moduły załadował kernel np. debiana, a następnie upewnienie się, że wszystkie są dostępne. Jeśli kompilujesz na tą samą maszynę to masz plus w postaci make localmodconfig, który zrobi to, co opisałem wyżej. Edytowano Wrzesień 9, 2014 przez Archi (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
SanKen 63 Zgłoś post Napisano Wrzesień 14, 2014 Czyli mam rozumieć że kompilowanie nowego kernela pod aktualny sprzęt jest dobrym rozwiązaniem. Ale jeśli system wymaga modułów a użyłem "localmodconfig" to wszystkie moduły warto w kompilować w jajko czy pozostawić jako moduły. Udostępnij ten post Link to postu Udostępnij na innych stronach
Pan Kot 1535 Zgłoś post Napisano Wrzesień 15, 2014 (edytowany) Musisz odróżnić kernel dystrybucji od własnego. Kernel dostarczany z dystrybucją jest jedną wielką bańką modularną. To oznacza, że ma wkompilowane jako moduły wszystkie sterowniki, drivery i czego dusza zapragnie co może być potrzebne/używane podczas korzystania z systemu. Kernel taki ma kilka zasadniczych wad. Po pierwsze, jest duży, zawiera tonę syfu, której nigdy w świecie nie użyjesz (chociażby moduł podczerwieni). I o ile te moduły de facto nie są ładowane, to fizycznie wciąż muszą być dostępne w razie, gdybyś podłączył nowe urządzenie wymagające określonego drivera. Kernel rekompiluje się z kilku powodów. a) Żeby być "na czasie", czyli wtedy, kiedy nowy kernel ma wsparcie dla określonej rzeczy, której wymagasz / chcesz b) Żeby zaaplikować kernelowe łatki, takie jak wsparcie grsecurity czy dodatkowe nieoficjalne moduły/funkcje/inne łatki. c) Żeby stworzyć jądro skompilowane konkretnie pod daną maszynę, w tym zastosowanie CPU-profilingu -mtune, który kompiluje kod konkretnie pod dany procesor/architekturę. d) Żeby odchudzić jajko ze wszystkich niepotrzebnych modułów, tak aby było mniejsze i działało szybciej. Ja kompilując kernela używam każdego z tych podpunktów. Ściągam najnowszego kernela z kernel.org, potem ściągam na niego najnowszą łatkę grsecurity z grsecurity.org, potem ściągam config OVH z ftp://ftp.ovh.net/made-in-ovh/bzImage, następnie aplikuję łatkę na kernela, odpalam config OVH, który jest już wstępnie zoptymalizowany i robię kilka zasadniczych modyfikacji: 1. Zmieniam target CPU z generic na Intel Atom, z racji że taki właśnie mam aktualnie na serwerze. 2. Wyłączam wsparcie dla procesorów innych niż Intel, oraz wszystkie funkcje AMD, których nie posiadam. 3. Włączam grsecurity 4. Optymalizuję jajko poprzez kilka zabiegów - w tym optymalizacja likely/unlikely, zmiana kompresji kernela, wywalenie całego debuga, frame pointerów i innych zbędnych rzeczy. 5. Wyłączam nieużywane przeze mnie funkcje, w tym tonę filesystemów (ext2, ext3, btrfs, xfs, jfs, nfs, cifs i więcej), tonę layoutów partycji i inne rzeczy. 6. Inne rzeczy, których już mi się nie chce pisać. Finalnie kompiluje nowego kernela, instaluję go, rebootuje maszynę i wszystko jest szybsze niż kiedykolwiek. Jeśli chcesz zrobić jednego kernela pod każdy z serwerów, których używasz należy upewnić się, że zawiera on wszystkie moduły, które są potrzebne każdemu z serwerów. Moduły zasadniczo są bardziej preferowane niż built-in rzeczy, aczkolwiek funkcje używane na każdym serwerze powinny być zaznaczone jako built-in, w szczególności takie rzeczy jak np. wsparcie dla dysków twardych, bez którego kernel po prostu nie zbootuje. Edytowano Wrzesień 15, 2014 przez Archi (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
spindritf 240 Zgłoś post Napisano Wrzesień 15, 2014 Finalnie kompiluje nowego kernela, instaluję go, rebootuje maszynę i wszystko jest szybsze niż kiedykolwiek. O ile szybsze? Puściłeś jakiś benchmark? Udostępnij ten post Link to postu Udostępnij na innych stronach
Pan Kot 1535 Zgłoś post Napisano Wrzesień 15, 2014 (edytowany) O ile szybsze? Puściłeś jakiś benchmark? Nie są to zaskakujące wartości, ale można podać parę przykładów: Przykład 1: OVH standardowo ma governor cpu "ondemand", który dostosowuje frequency do potrzeb. Ja zmieniam na performance - zawsze ustawiam max frequency. Przykład 2: Większość kerneli używa I/O governora CFQ, poprzez używanie Deadline jesteśmy w stanie nieco zwiększyć szybkość I/O. Przykład 3: Wyłączenie debuga pozbawia kernel overhead'u, z którym mamy styczność na wszystkich produkcyjnych i dystrybucyjnych kernelach. Jeśli ktoś nie zamierza debugować problemów z kernelem, można wyłączyć debug, aby kernel nie starał się zapisywać informacji o tym, co robi. Przykładów jest więcej, żadnego benchmarka nie robiłem bo ciężko coś takiego jak kernel w ogóle zbenchmarkować, jednak odczuwalna jest nieco większa responsywność w takich komendach jak apt i dpkg chociażby. Kernela kompiluję głównie dla grseca, prawdopodobnie gdybym nie używał tej łatki to bym się nie zagłębiał jakoś szczególnie w konfigurację, ale skoro już rekompiluję to od razu dostosowuje pod daną maszynę. I "zawsze" jakaś tam mikroskopijna różnica na plus jest odczuwalna po tym jak zrebootuje. Może to być również związane z samym faktem kompilatora, nowsze GCC zawsze lepiej sobie radzą z kodem i optymalizacjami niż starsze. Edytowano Wrzesień 15, 2014 przez Archi (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
