02.06
In /dev/random ,Linux | Tags: apache, Linux, php
W PHPie zostały wykryte jakieś bugi więc pomyślałem że warto by zrobić upgrade na naszym Gentoowskim serwerem WWW. Jakiś czas temu zmieniłem mpm w apache z prefork na workera (pierwszy robi proces dla każdego żądania, drugi używa do tego wątków więc ogólnie żre mniej zasobów) więc PHP chciał być przekompilowany z opcją USE=threads (używam FastCGI ale mod_php trzymam na wszelki wypadek) . Wydawałoby się że nie powinno to być problemem, dodać flagę, przekompilować i tyle. Ta, byłoby za dobrze ;/
Odpaliłem emerge, przy okazji przekompilowało jakies zależności też z opcją “threads”. PHP się nie skompilował, tylko zależności bo php chciał żeby mu jeszcze przekompilować ręcznie libpg (jakby nie mogli tego wpakować w zależności), w międzyczasie libcurl dostał update psując starego PHP.
Nazwa pliku zmieniła się z libcurl.so.3 na libcurl.so.4 a stary perl chodził na tym pierwszym więc byebye.
ln -s libcurl.so.4 libcurl.so.3
I stary php zaczął działać normalnie. Pomęczyłem trochę nowy, skompilowałem, restart apache, nie działa. Uparcie próbuje ładowac liby do memcached które są tylko w katalogu “non-treaded”, wywala tylko warning ale to wystarczy żeby FastCGI już go nie lubiło. Pobawiłem się trochę, zaczęło działać, przestało działać.
Po otworzeniu paru stron fastcgi sypał errorami że php ma timeouty, cos mnie napadło żeby odpalić php-cgi. Odpalam, wklepuje coś, ctrl-d (czyli zakończ stdin), php wywala wyjście ale nie wychodzi. Zastanawiam się czy to normalne, loguje sie na devrandom (debian) taki sam test, php wychodzi po ctrl-d. WTF!?
Wyłączyłem moduł do apache w phpie, wyłączyłem threads, rekompilacja, wywalenie paru plików z configa apache (configi mod_php5, czepiał się mimo że ich nie ładował), apache stop, killall -9 apache2 ; apache start działa -_-
Więc jeżeli drogi Czytelniku zamierzasz kiedykolwiek używać Gentoo na twoim jedynym serwerze i nie masz opcji testowania upgradu na serwerze testowym z takim samym configiem (łącznie z takimi samymi wersjami pakietów itp.) , przemyśl to jeszcze raz ;]
8 ResponsesLeave a comment ?
A może tak… jak się człowiek na czymś do końca dobrze nie zna, to nie powinien się za to brać… :)
Niestety magiczne polecenie emerge to nie wszystko. System powinien być regularnie aktualizowany, a nie raz z doskoku (bo mi się akurat przypomniało) bo kończy się to tak jak opisałeś.
Ja jestem szczęśliwym użytkownikiem Gentoo od kilku lat i nie znam bardziej stabilnego i konfigurowalnego systemu.
PHP był aktualizowane z wersji 5.2.8-r1 do 5.2.8-r2 więc nie nazwałbym tego aktualizowaniem “raz z doskoku”;]. Akcje typu że robię update jakiegoś pakietu, przy okazji updatując 4-5 rzeczy zależnych i któraś z tych rzeczy jest niekompatybilna ze starszą wersją więc starsza wersja się rozsypuje a nowa jeszcze się nie skompilowała zdarzyły mi się już parę razy i wcale nie na ~x86 ;]
Nie napisałem że Gentoo jest zły, tylko że nie uzyłbym go na serwer jakbym nie mógł przedtem przetestować na innej maszynie “czy aby na pewno się nie sypnie”. Poza tym zysk wydajności jest na tyle minimalny (jeżeli chodzi o serwer) że Gentoo to strata czasu (no chyba że i tak nie masz co robić ;]) a jak bardzo potrzeba mi tych 5% to zawsze mogę w Debianie ściągnąć źródła paczki, skompilować i potem ładnie zapakować w deba ;]
I dlatego, tak naprawdę, systemy typu Gentoo, FreeBSD i inne, gdzie pakietologia żyje własnym, niezależnym od rytmu wydań samego systemu, to systemy dla dzieciaków, które mają za dużo czasu. Jak maszyn jest mnóstwo, to sprawdza się wyłącznie system taki, gdzie wersje oprogramowania nie zmieniają się w danym wydaniu. Wtedy wiadomo, że upgrade jakiejś biblioteki nie wysadzi połowy softu w powietrze.
Jak masz 20 maszyn robiących to samo możesz wyłączyć jedną i sprawdzić, a potem jak będzie ok zrobić upgrade reszty. Ale znowu, jeżeli i tak bedziesz korzystał ze “standardowych” opcji pakietu, kompilacja to strata czasu. A jak rzeczywiście potrzebujesz tej czy tamtej funkcji lub 3% więcej wydajności, możesz skompilować sobie paczki źródłowe i zrobić lokalne repo i nie przejmować się rekompilowaniem połowy systemu co pare miechów ;].
3% zysku na prędkości poszukiwania kolejnych bugów kompilatorze jest dobre dla dzieciaków, którym sie nudzi. Jak mam 20, 30 czy 50 maszyn (a mam więcej), które robią rózne rzeczy (tylko naprawdę Duuuuuże Sajty mają po 20 maszyn w farmie, które robią jedno i to samo), to nie mam czasu na dzierganie pakiecików, a przy naszych SLA tym bardziej nie podejmę ryzyka wysadzenia czegoś w powietrze dla marnych 3%, bo będę to musiał naprawiać w środku nocy. W dobie powszechnie dostępnych repozytoriów z kryptograficzną weryfikacją tożsamości pakietów struganie własnego repozytorium wszystkich pakietów (a nie tylko dzierganych na własne potrzeby) jest wyłącznie statą czasu. A już totalną stratą czasu jest budowanie całego drzewa (jakie szybkie by nie były te maszyny, to jednak trwa to trochę) dla jednego czy dwóch pakiecików, które ściągniesz z ogólnodostępnego repozytorium w pięć minut.
Zgadza się ;] Poza tym takie pakieciki w np. debianien stable są ruszane tylko w razie buga i generanie dobrze przetestowane zanim trafią do stable. Chyba że ktoś potrzebuje “bleeding edge” ale wtedy jest zawsze opcja zainstalowania pakietów w testing/unstable.
Poza tym, jeżeli chodzi o systemy 32 bitowe to optymalizacja jeszcze coś daje (bo pakiety są kompilowane na i386, w najlepszym wypadku i686), ale w 64 bitowych naprawdę nie ma co kręcić ;]
Od czasu buga w kompilatorze, objawiającego się w OpenBSD w sposób taki, że jądro z optymalizacją stawało w miejscu bez pierdnięcia ani słowa na temat co mu, a jądro GENERIC chodziło sobie bez zająknięcia, olałem wszelkie optymalizacje kodu pod procesor jako potencjalne źródła błędów. I w ten sposób, od paru lat, żyję w błogiej nieświadomości istnienia potencjalnych fruktów wynikajacych z optymalizacji kodu :P I jest to całkiem spokojne życie.
Teraz i tak zwykle jeżeli już app używa instrukcji typy SSE3 do przyśpieszenia działania to programista pisze na zasadzie “jeżeli są użyj tej części kodu, jeżeli nie fallback do default”, pierwszy z brzegu przykład – mplayer ;].