plusnet – isp w anglii zmieniał system storage'y.
rano pracownik miał wyczyścić nowy system, ale pomylił konsole. 700 giga poczty klientów poszło na spacer.
firma wezwała specjaliste od odzyskiwania danych (co sugeruje brak backupów) – wyniki mają być znane w piątek.
klientów poinformowali o problemie, ale powiedzieli, że nie przewidują rekompensaty finansowej.
i tym optymistycznym newsem rozpoczynam dzień 🙂
od jakiegoś czasu strasznie modny stał się framework do robienia aplikacji webowych – ruby on rails.
sporo ludzi robi tutoriale, opisy, filmy pokazujące co i jak można.
econsultant.com przygotowali gotową do użytku listę 30 najlepszych (w/g nich) tutoriali nt. ror'a. warto spojrzeć – google na hasło “ruby on rails" tutorial, znajduje ponad 1.7 miliona stron. dzięki econsultantom można ich przejrzeć zdecydowanie mniej 🙂
mojeauto.pl – wortal poświęcony motoryzacji, obuplikował pełną wersję raportu dekry nt. awaryjności samochodów. obejrzeć, wyszukać i porównywać można bezpośrednio tu.
wiele serwisów internetowych broni sie przed np. masową rejestracją kont poprzez umieszczanie na formularzach tzw. captchy. czyli obrazków przedstawiających zniekształcone litery i cyfry. a użytkownik musi napisać jakie znaki tam sa by zostać uznanym za człowieka i by móc dalej rejestrawać konto czy wykonywać inną, chronioną, akcję.
ostatnio powstał serwis który oferuje captche które są jakby ciekawsze. trzeba wybrać które 3 zdjęcia (z 9) przedstawiają osoby “hot" – gorące, urodziwe. jest wersja dla facetów i dla kobiet.
kiedy yahoo zmieni swoje captche na takie?
na newsach na grupie pl.comp.bazy-danych co jakiś czas ktoś się pyta jak zaprojektować bazę do … (wypozyczalni książek, serwisu, whatevera).
zazwyczaj są to prośby/pytania wynikające z nieuczenia się i zbliżającej się (na przykład – już jutro) sesji egzaminacyjnej.
tym co się nie uczą to i tak niewiele pomoże, ale jeśli macie problem jak zacząć projekt bazy do jakiegoś zadania – spójrzcie na ten serwis. zawiera sporo (około 200 chyba) przykładowych struktur baz danych.
oczywiście tego co tam jest nie wolno traktować jako wyroczni. ale czasem po prostu jest potrzebny taki kopniak na początek – a dalej już można modyfikować przykładowy schemat do woli.
po raz kolejny (trzynasty) computerworld opublikował swoją coroczną listę firm w których się najlepiej pracuje informatykom.
ponieważ robi to amerykańskie centrum, to i firmy są amerykańskie (a dokładniej: muszą mieć minimum 500 pracowników w stanach).
warto przejrzeć by wiedzieć komu wysyłać cv 🙂
w przeprowadzonym ostatnio badaniu 35% osób zajmujących się rekrutacją przyznało, że odrzucali kandydatury pracowników na bazie informacji znalezionych w sieci.
rok temu było to 26% czyli trend ewidentnie zwyżkuje – co jest tak naprawdę dosyć oczywiste biorąc pod uwagę powszechność internetu.
co interesujące – 82% przepytanych osób spodziewa się, że osoba rekrutująca wyszuka informacji o nich w sieci, ale jedynie co trzeci sprawdzał sam informacje o sobie.
są też sytuacje odwrotne – gdy informacje znalezione na sieci pozwalają się lepiej zaprezentować lub też są startem do dyskusji w trakcie rozmowy kwalifikacyjnej, co pozwala nieco “rozluźnić atmosferę".
część ludzi omija ten problem pisząc na sieci pod pseudonimami lub anonimowo, ale trzeba zwrócić uwagę, że zamyka to też możliwość, skojarzenia przez przyszłego pracodawcę informacji pozytywnej o kandydacie.
wydaje się, że jedyną rozsądną opcją, jest po prostu zachowywanie się w sieci tak jak w normalnym życiu – pewne normy zachowania obowiązują. to da bezpieczeństwo, że nikt nie wygrzebie “brudów" z sieci.
w 1996 roku kilku naukowców zaczęło pracować nad systemem umożliwiającym odczytywanie bezpośrednio z mózgu prostych komend oraz ich przetwarzanie na postać cyfrową.
w 2001 założyli firmę, zdobyli 5milionów dolarów kapitału i wystąpili do fda o zgodę na badania kliniczne. w 2002 udało im sie spowodować, że małpy z wszczepionym chipem mogłu kontrolować kursor na ekranie komputera nie wykonując żadnego ruchu.
w 2004 rozpoczęły się testy kliniczne na ludziach.
chip jest inwazyjny – ma wielkość 4mm x 4mm i jest “zanurzony" na głębokość 1mm w mózg, w obszar odpowiedzialny za świadomy ruch.
wyłapuje sygnały, które (w fazie treningu) są przetwarzane na ruch w dwóch wymiarach.
testy są bardzo obiecujące – pierwszy pacient potrafi już przy pomocy myśli narysować kółko w programie graficznym, zagrać w ponga czy modyfikować głośność telewizji – nawet jeśli w czasie wykonywania tego rozmawia!
na razie testy wykonuje się na osobach chorych – pierwszy pacjent, mający 25 lat, ma jakieś (kiepsko rozumiem angielski medyczny) poważne uszkodzenia kręgosłupa/rdzenia nerwowego i jest sparaliżowany od 2001 roku.
na razie technologia jest jeszcze w powijakach. poza małym chipem do działania wymaga olbrzymiego sprzętu obok, długiego treningu (wzory aktywności neuronów mogą się zmieniać z dnia na dzień, ze względu na pogodę, humor czy cokolwiek innego). ale już teraz wygląda to mocno obiecująco. następny krok to spowodowanie by chip działał bezprzewodowo i rozbudowanie logiki odpowiedzialnej za rozpoznawanie wzorów aktywności. dzięki temu będzie możliwe np. zrobienie wózka inwalidzkiego sterowanego myślami chorego.
to jedna strona medalu. druga jest taka, że taka technologia ma całkiem inne, i też interesujące, zastosowania wojskowe. w dodatku – wojsko ma wyższy budżet. kiedy się dowiemy, że wojsko nad tym pracuje? a może pracuje od dawna, tylko jest to tajne?
po udanym postawieniu serwera, przychodzi kolej na to by go nadzorować. spora część ludzi używa w tym celu softu który automatycznie robi wykresy różnych parametrów. przykładem (którego używam np. ja) jest mrtg. są też inne pakiety, lepsze czy gorsze. używam i lubię mrtg.
mrtg potrafi rysować wykresy nie tylko ruchu na interfejsach, ale praktycznie dowolnych danych podawanych w postaci liczbowej.
dzięki temu używam go do rysowania wykresów:
to monitoruję na każdym serwerze – niezależnie czy to webserwer, serwer aplikacyjny z jbossem, webproxy, firewall czy serwer bazodanowy.
ale na serwerach bazodanowych przydają się też inne parametry.
zanim przejdę do ich omówienia krótki wtręt.
mrtg potrafi pobierać dane poprzez uruchamianie programów które mu dane zwracają, lub poprzez odpytywanie zdalnego serwera snmp. wybrałem to drugie rozwiązanie, bo daje mi trochę więcej możliwości – np. mogę wykresy rysować na zupelnie innej maszynie niż ta której wykresy dotyczą.
do każdej znanej mi implementacji snmp jest możliwość podpięcia zewnętrznych skryptów/programów pod tzw. mib'y. dzięki temu mogę dowolnie rozszerzać funkcjonalność snmp i dodawać monitorowanie parametrów o których twórcy snmpd nie mieli pojęcia 🙂
pierwszym niestandardowym parametrem który monitoruję na serwerach bazodanowych jest ilość operacji i/o w podsystemie dyskowym.
postgresql jest mocno czuły na obciążenie dysków i tzw. iowaity powodują, że maszyna zachowuje się jakby ktoś jej podciął skrzydła. procesor jest wolny, wszystko działa ok, ale postgres się wlecze.
w używanym przeze mnie net-snmpd, odpowiednie wartości są dostępne pod mib'ami: ssIORawSent.0 i ssIORawReceived.0.
odpowiedni kawałek configu mrtg:
Target[db_sys_iorawsent]: ssIORawSent.0&ssIORawSent.0:public@db Options[db_sys_iorawsent]: growright MaxBytes[db_sys_iorawsent]: 100000000 Title[db_sys_iorawsent]: IORawSent at db PageTop[db_sys_iorawsent]: IORawSent at db
(można umieścić oba wykresy na jednym obrazku, ale z przyczyn pozamerytorycznych wolę mieć każdy oddzielnie).
następnymi (i ostatnimi ogólno systemowymi) parametrami jakie monitoruję jest ilość context-switchy i przerwań w systemie.
dostępne jest to u mnie pod mibami: ssRawContexts.0 i ssRawInterrupts.0
i teraz przechodzimy do części najzabawniejszych.
co monitorować w samym postgresie.
przede wszystkim – jak? przygotowałem sobie prosty program który wykonuje jedno zadane polecenie w bazie danych i zwraca wynik na stdout. ten skrypt podłączam do snmp wykorzystując funkcję “exec" z snmpd.conf.
i lecimy z zapytaniami:
jeśli używacie replikacji, a do replikacji slony'ego, warto monitorować opóźnienie replikacyjne. opóźnienie to wyraża się w dwóch wartościach:
lag_events jest to ilość zdarzeń modyfikujących bazę które jeszcze nie zostały przesłane na bazy podrzędne. lag_time jest to opóźnienie replikacji wyrażone jako czas.
wyciągnąć obie wartości można tak:
SELECT st_lag_num_events, st_lag_time FROM _slony.sl_status
przy czym aby móc to rysować lepiej jest przeliczyć lag_time na sekundy:
SELECT st_lag_num_events, CAST(EXTRACT(epoch FROM st_lag_time) * 1000 AS int8) FROM _slony.sl_status
zwrócić należy uwagę, iż jeśli lag_events jest równy 0, to lag_time jest nieistotny.
na koniec coś na zewnątrz sql'a.
w postgresql.conf jest taka opcja: log_min_duration_statement.
pozwala ona na logowanie długich zapytań. tu uwaga – ta opcja jest zupełnie niezależna od log_statement czy log_duration!
wartość opcji log_min_duration_statement oznacza liczbę milisekund jaką zapytanie się wykonywało by zostało uznane za zbyt długie, i zalogowane. ja osobiście wpisuję tam wartość 1000 – co powoduje, że każde zapytanie trwające powyżej 1 sekundy zostanie zapisane w logach. np. tak:
[2006-07-14 00:00:04 CEST] [25989] LOG: duration: 1133.235 ms statement: SELECT id, file_extension FROM flickr_images WHERE id > ‘0' AND size_x_orig = 0 and status >= 0 ORDER BY id ASC
zwracam tylko uwagę na fakt iż to, że zapytanie się długo wykonuje niekoniecznie jest problemem zapytania. najczęstszą sytuacją jest to, że pojawia się zapytanie które wykonuje się dosyć długo, ale poza tym przyblokowuje ono zupełnie inne zapytania – które też nagle zaczynają się długo wykonywać.
tak więc nie należy patrzeć na listę “długich" zapytań jako listę rzeczy do poprawienia, tylko jako na wsad do analizy statystycznej jakie zapytania pojawiają się najczęściej. i dlaczego.
to zasadniczo kończy temat. monitorować można sporo więcej – choćby ilość procesów postgresa, czy ilości odczytów via seq-scan czy index-scan. natomiast wydaje mi się, że te parametry mogą być istotne “punktowo", a niekoniecznie muszą być od razu rysowane.
kilka firm zaskarżyło ostatnio google'a, że zaniża ich pozycję w wynikach wyszukiwarki, przez co maleją im obroty.
nie znam tła historii (nie wiem czemu google obniżył im pageranka, ale nie uważam tego za przesadnie istotne).
istotne dla mnie jest to, że firma x chciała wywrzeć na firmie y modyfikację działania na korzystaniejsze dla x – mimo, że ich rynki się nie pokrywają, nie ma nieuczciwej konkurencji.
osobiście wychodzę z założenia, że indeksy google'a są własnością google'a i to co w nich robią jest ich prywatną sprawą.
interesujące było to jak do sprawy podejdzie system prawny stanów zjednoczonych. i okazało się, że zdrowy rozsądek wygrał. sędzie rozpatrujący sprawę ją oddalił.
komentarze po procesowe informują, że jednyną drogą jaką “pokrzywdzone" firmy mogą się walczyć o poprawienie wyników jest stwierdzenie, że obniżenie ich pageranka to zniesławienie. ale to będzie bardzo ciężko udowodnić.