Skocz do zawartości

Rekomendowane odpowiedzi

Z jakiego jądra korzystacie na serwerach linuksowych w OVH?

  • Ich własne, czy
  • dystrybucyjne, czy
  • kompilujecie któreś pod własne potrzeby?

 

Pytam, bo chciałem użyć "targetcli-fb", które wymaga TCM w jądrze. Niby nic trudnego, ale poległem na kompilacji kernela na configu z OVH, bo wymagał różnych plików z microcodem Intela, których nigdzie nie mogłem znaleźć. Cześć była w pakietach Debiana (non-free), część z paczki na stronie Intela, a o niektórych to nawet Internet nie słyszał.

 

Ostatecznie zmieniłem na jądro dystrybucji i działa.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Jeżeli centos to ELRepo najnowsze kernele wchodzą. Zazwyczaj używam już gotowych kerneli, ale jeżeli jest potrzeba to kompiluje z paczki (kernel.org)

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

@Mruczek jeśli kernel z pakietu w dystrybucji działa, to zajrzyj do "source" pakiety, popraw co tam potrzebujesz i przebuduj do własnego pakietu.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Ja lecę tak - na podstawie ich configu opracowuje swój, potem wyłapuje ewentualne błędy. Ich configi są dobre bo są pod ich blachy, ale część rzeczy nie potrzebna tam jest. 

  • Lubię 1

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
2 godziny temu, Przemek Jagielski napisał:

Ja lecę tak - na podstawie ich configu opracowuje swój, potem wyłapuje ewentualne błędy. Ich configi są dobre bo są pod ich blachy, ale część rzeczy nie potrzebna tam jest. 

 

Rozwinąłbyś? 

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
11 godzin temu, Przemek Jagielski napisał:

Ja lecę tak - na podstawie ich configu opracowuje swój, potem wyłapuje ewentualne błędy. Ich configi są dobre bo są pod ich blachy, ale część rzeczy nie potrzebna tam jest. 

 

I to jest bardzo dobre podejście. Sam tak robię, choć teraz preferuję robić 3-way-merge configa distro i configa OVH, jeszcze samemu poprawiając co trzeba.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Z ciekawości. Jakie problemy / błędy mieliście z jądrem od OVH?

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
11 godzin temu, SomeGuy napisał:

 

Rozwinąłbyś? 

Spróbujmy. 

Osobiście robię to trochę na około, bo ręcznie (a pewnie da się to szybciej, @Archi liczę tu na jakąś wskazówkę). W jednej konsoli mam odpalony konfig na maszynie działającej a na maszynie, którą robię, klikam co mam klikać. Wymianę kernela robię głównie co rilis, chyba, że w changelogu coś wyhacze ważniejszego (chociaż ostatnio z czytaniem changelogów jestem w plecy). Ale jak robię wymianę rilisu to już mam gotowy config. 

3 godziny temu, Archi napisał:

 

I to jest bardzo dobre podejście. Sam tak robię, choć teraz preferuję robić 3-way-merge configa distro i configa OVH, jeszcze samemu poprawiając co trzeba.

A jak to robisz? Mógłbyś coś więcej powiedzieć? 

3 minuty temu, Poziomecki napisał:

Z ciekawości. Jakie problemy / błędy mieliście z jądrem od OVH?

Ostatnio się zaskoczyłem, kiedy trzeba było wgrać intel-microcode, gdzie tylko w OVH trafiłem na to. 

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
3 godziny temu, Archi napisał:

... jeszcze samemu poprawiając co trzeba.

 

Ponownie z ciekawości zapytam, co tam zwykle uważasz że trzeba poprawiać ?

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
4 godziny temu, gb1 napisał:

 

Ponownie z ciekawości zapytam, co tam zwykle uważasz że trzeba poprawiać ?

 

Zależy od przeznaczenia serwera. Politykę ASPM na performance, cpu governor na performance, I/O scheduler w zależności czy mam system na hdd czy ssd cfq lub noop, kernel patchuję patchem od graysky2 żeby mu wrzucić -march=native,  przerwania CPU ustawiam na ogół na 250 MHz, do tego wyłączam wszystkie zbędne funkcje, żeby się w ogóle nie budowały, cały debug, czy nawet takie rzeczy jak support procesorów AMD (no bo po co jak mam intela).

 

Ogółem dużo rzeczy można pozmieniać. To wyżej to tylko to co mi do głowy przyszło.

 

5 godzin temu, Przemek Jagielski napisał:

Osobiście robię to trochę na około, bo ręcznie (a pewnie da się to szybciej, @Archi liczę tu na jakąś wskazówkę).

 

Diffmerge, zwykły diff, make localmodconfig czy diff oryg configa z configiem OVH i zaaplikowanie na nowy, po czym make oldconfig. Też dużo możliwości.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Na wielu serwerach działa jądro kompilowane przez OVH i nie ma żadnych problemów.

Wiadomo tak jak pisał @Archi nie jest ono jakoś specjalnie optymalizowane ale działa poprawnie przy większości zastosowań.

Tak naprawdę nie ma większych różnic między dystrybucyjnym jądrem, a tym od OVH.

Wydajnościowo będzie podobnie, jedynie jądra OVH mają dodane patche pod ich sprzęt i z reguły są nowsze niż te dystrybucyjne ( no chyba, że używamy Archa :) ).

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Ja właśnie chciałem zachować to dopasowanie pod ich sprzęt (zwłaszcza, że to serwerek na DN2800MT), ale dokompliować wsparcie dla TCM (Target iSCSI). Ale poległem na dodatkowych mirocode'ach, które w configu są dodane jako "linki" do binarek Intela. Pakiet Debiana miał ich część, część była w paczce od Intela, ale ponad 4 nie mogłem za Chiny namierzyć. Niby mogłem ograniczyć się do firmware'u dla mojego procka, ale wybrałem linię najmniejszego oporu (oryginalne jądro Debiana, z TCM już w module).

 

Nota bene, fajnie chodzi iSCSI między dwoma serwerami w OVH. Kimsufi jako dysk dla VPSa z Windowsem :-) Oczywiście bardziej jako PoC lub do użytku prywatnego. Firmy, czy klientów tak bym nie postawił.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
W dniu 15/02/2018 o 18:30, Archi napisał:

Ogółem dużo rzeczy można pozmieniać. To wyżej to tylko to co mi do głowy przyszło.

 

Większość opcji jest konfigurowalnych zwykle. Większość z wymienionych opcji może być konfigurowalna nie na etapie kompilacji, zatem ponownie z ciekawości zapytam czy widzisz jakieś rozsądne uzasadnienie aby robić to na etapie kompilacji jądra ?

 

Korzystacie z jakiegoś ciekawego rozwiązania automatyzacji i cyklicznego automatycznego przebudowywania jądra wedle własnej specyfikacji ? Deployment na produkcję przez własne repo pakietów czy inny ciekawy sposób ?

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
2 godziny temu, gb1 napisał:

 

Większość opcji jest konfigurowalnych zwykle. Większość z wymienionych opcji może być konfigurowalna nie na etapie kompilacji, zatem ponownie z ciekawości zapytam czy widzisz jakieś rozsądne uzasadnienie aby robić to na etapie kompilacji jądra ?

 

Korzystacie z jakiegoś ciekawego rozwiązania automatyzacji i cyklicznego automatycznego przebudowywania jądra wedle własnej specyfikacji ? Deployment na produkcję przez własne repo pakietów czy inny ciekawy sposób ?

 

Większość tego co wymieniłem tak, większość tego co wywalam z kompilacji, żeby się w ogóle nie budowało wraz z ich zależnościami już nie, a przecież nie będę Ci wymieniał każdego pojedynczego drivera.

 

2 godziny temu, gb1 napisał:

Korzystacie z jakiegoś ciekawego rozwiązania automatyzacji i cyklicznego automatycznego przebudowywania jądra wedle własnej specyfikacji ? Deployment na produkcję przez własne repo pakietów czy inny ciekawy sposób ?

 

Ja mam raczej autorskie rozwiązanie oparte hybrydowo na pakietach budowanych ze źródeł i paczkach deb z repo. Mam określoną konfigurację każdego pakietu - serwer testowy każdego dnia dokonuje self-update'a (w pełni automatycznie), wraz z rebootem. Po reboocie lecą unit testy na wszystko co kiedykolwiek mnie zawiodło czy nie ma żadnych regresji (począwszy od tego czy serwis X wstaje, poprzez to czy wspiera funkcjonalność X, a na benchmarku raw wydajności i testach obciążeniowych kończąc). Jeśli wszystkie testy przejdą bez problemu to leci automatyczny deploy na wszystkie maszyny w tej samej konfiguracji. Pakiety ze źródeł są budowane tam gdzie dorzucam łatki -march=native, czyli praktycznie wszędzie gdzie coś grzebię (aktualnie kernel, .net core runtime, nginx, php-fpm i mariadb).

 

Wszystkie maszyny jadą na debianie testingu na produkcji :)

  • Lubię 1

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
1 godzinę temu, Przemek Jagielski napisał:

@Archi a dokompilowywałeś Live Patch czy nie jesteś zwolennikiem tego rozwiązania? 

 

Nie, reboota potrzebuje również z innych względów (np. żeby sprawdzić czy usługi dobrze wstają, systemd działa poprawnie itp.) więc nie jest mi to do niczego potrzebne.

  • Lubię 2

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Dystrybucyjny kernel, jeśli tylko się da. Coś innego tylko jeśli absolutnie muszę, ale ostatnio rzadko muszę.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
W dniu 17/02/2018 o 17:18, Archi napisał:

większość tego co wywalam z kompilacji, żeby się w ogóle nie budowało wraz z ich zależnościami już nie

 

Jaki masz cel że to wywalasz ? Jakieś konkretne kwestie wydajnościowe ? bezpieczeństwa ? jakieś inne ?

 

W dniu 17/02/2018 o 17:18, Archi napisał:

Po reboocie lecą unit testy...


Testy w bashu ? Z czegoś ciekawego korzystasz do testów ? Stale poszukujemy dobrego rozwiązania do testów w bashu jednak pomimo korzystania z wielu żaden nie przypadł nam do gustu, choć najczęściej korzystamy z BATS choć nie rozwijany i siermiężny.

 

W dniu 15/02/2018 o 18:30, Archi napisał:

kernel patchuję patchem od graysky2 żeby mu wrzucić -march=native

 

Dokonywałeś jakiś testów wydajnościowych w tym zakresie ? Jeśli tak to w jakim obszarze lub obciążeniach uzyskujesz największy przyrost wydajności w stosunku do standardowych kerneli z dystrybucji ? 

W zeszłym roku dokonaliśmy takich testów i przyznam, że przy większości obciążeń brak było popraw wydajności powyżej kilku niskich procent. Wcześniej także dokonywaliśmy podobnych testów korzystając z kompilatora Intela, tam także nie było znacznie lepiej. 

 

(powyższe dotyczy kompliowania kernela w opisany sposób)

 

Podobnie w przypadku kompilacji aplikacji/usług, czy testowałeś zyski na wydajności ? Tutaj znaczący uzysk widzieliśmy przy szyfrowaniu (np. w przypadku https), ale to zrozumiałe. 

 

W dniu 18/02/2018 o 12:31, Przemek Jagielski napisał:

a dokompilowywałeś Live Patch czy nie jesteś zwolennikiem tego rozwiązania?

 

IMHO dużo zależy od kontekstu, czyli jaki miałby być cel wykorzystania Live Patcha ? 
 

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się


  • Przeglądający   0 użytkowników

    Brak zarejestrowanych użytkowników, przeglądających tę stronę.

×

Powiadomienie o plikach cookie

Korzystając z forum, wyrażasz zgodę na: Warunki użytkowania, Regulamin, Polityka prywatności.