Jądro na serwerach OVH

[Przemek Jagielski]

Warto wiedzieć, zapiszę to sobie. 

[kkw]

Czy dla Kimsufi OVH też przygotowuje kernele?

[Przemek Jagielski]

Kernele OVHowskie są generalnie przystosowane do dedyków, więc nie powinno być jako takiego problemu. 

[Spoofy]

W dniu 12.04.2018 o 19:39, Pół człowiek pół admin napisał:

Co cię motywuje do tego? Przeprowadzasz regularnie testy na podatności własnego tworu?

Od jakichś kilku lat. Ostatnio coraz więcej ciekawych rzeczy jest w stockowym kernelu, aczkolwiek dalej to nie jest to czego potrzebuję ja i moi klienci.

 

Przykładem jest chociażby zastosowanie bfq w branchu 4.9 czy kwestie wydajnościowe od trywialnych tick parms czy kompilacji większości bezpośrednio w jajku a nie modułach, skończywszy na bardziej zaawansowanych kwestiach.

W dniu 18.08.2018 o 09:58, kkw napisał:

Czy dla Kimsufi OVH też przygotowuje kernele?

 

W dniu 18.08.2018 o 14:22, Przemek Jagielski napisał:

Kernele OVHowskie są generalnie przystosowane do dedyków, więc nie powinno być jako takiego problemu. 

 

nie, nie są "przystosowane do dedyków", tylko do konkretnych konfiguracji sprzętowych platform supermicro czy konkretnych kontolerów. Dodatkowo na kimsufi stosują łatki dla atomów.

[theqkash]

Pozwolę sobie podbić temat.

Miałem problem z wydajnością sieci na proxmoxach, które były instalowane via instalator w serii SyS.

Szukałem problemu w samej sieci, a okazało się, że problemem jest... kernel OVH.

Instalacja fabrycznego kernela rozwiązała problem.

[Przemek Jagielski]

A którą wersję jądra instalowałeś? Bezpośrednio z repo co idzie czy samemu wrzucasz nowsze wersje? Może któryś moduł jest trefny w obecnych wersjach

[Archi]

14 godzin temu, theqkash napisał:

Pozwolę sobie podbić temat.

Miałem problem z wydajnością sieci na proxmoxach, które były instalowane via instalator w serii SyS.

Szukałem problemu w samej sieci, a okazało się, że problemem jest... kernel OVH.

Instalacja fabrycznego kernela rozwiązała problem.

 

Ja już od dawna jadę na oficjalnym kernelu dystrybucyjnym, czasem jeszcze na własnym. Kernel od OVH ma zbyt dużo generycznych śmieci, które są ładowane w każdym wypadku. Zakładając, że twoja maszyna potrzebuje 30% kernela, w kernelu debiana załaduje się core 5% bez którego kernel w ogóle działać nie może, a pozostałe 25% dociągnie się z modułów, gdzie w kernelu ovh na siłę leci 40% czy Ci się to podoba czy nie, bo wszyscy w OVH boją się modularnego kernela jak ognia. W efekcie końcowym nie tylko jesteś podatny na o wiele więcej bugów niż zwykle (bo każda linijka kodu ma szanse na konflikt), ale sam kernel działa dużo wolniej i potrzebuje więcej pamięci bo ma na twardo załadowane co najmniej kilkadziesiąt modułów, które na twojej aktualnej maszynie do niczego nie są używane.

Edytowane 22 Marca 2019 przez Archi

[Przemek Jagielski]

Ja po swojej stronie korzystam z patchy i konfigu OVHowskiego, ale połowę rzeczy i tak jeszcze wyłączam. Ogólnie to przydałby się jakiś konkretniejszy spis tego, z czego oni rzeczywiście korzystają w ramach dedyków, żeby można było powyłączać wszystko to co nie jest potrzebne, chociażby po stronie sieci.

[Matix8981]

Możliwe, że problemy wydajności związane z kernelem OVH są spowodowane poprzez narzucony przez OVH tryb economy.

Powiedzmy procesor ma taktowanie 4,4 GHz według OVH na kernelu OVH miał problemy z przebiciem granicy 3,6 GHz. Na kernelu od elrepo na centos'ie bez problemu 4,36-4,4GHz

[Przemek Jagielski]

Nie ma co się też dziwić, że taki tryb jest narzucony w ich jądrze - DC tego prądu mało nie biorą, walczą też o jakiś poziom ekologii więc coś kosztem czegoś. Stąd można zawsze te jądro sobie zmienić.

[Archi]

3 godziny temu, Matix8981 napisał:

Możliwe, że problemy wydajności związane z kernelem OVH są spowodowane poprzez narzucony przez OVH tryb economy.

Powiedzmy procesor ma taktowanie 4,4 GHz według OVH na kernelu OVH miał problemy z przebiciem granicy 3,6 GHz. Na kernelu od elrepo na centos'ie bez problemu 4,36-4,4GHz

 

To też zauważyłem. Generalnie nie uważam tego za złe biorąc pod uwagę, że sztucznie nie ograniczają, a jedynie dowalają oszczędność mocy jak tylko mocno się da, ale faktem jest że każdy świadomy administrator pierwsze co powinien zrobić to albo wywalić to jądro całkowicie, albo zrekompilować pod siebie, bo części z tych opcji podczas runtime'a nie ruszysz.