Jest to model 4810-340 o konfiguracji sprzętowej zaczerpniętej ze strony producenta http://www-03.ibm.com/products/retail/products/pos/300/specs.html

Problem ze startem systemu polegał na tym, iż na dysku niebył zainstalowany jakikolwiek system operacyjny W ruch poszła, prawie standardowa, instalacja OpenSuSE 11.1 – prawie standardowa, gdyż nie instalowałem menagerów Xów. Bootowanie po PXE następnie proces instalacji – zajęły niecałe 25 minut. Po uruchomieniu serwera Xów, przy ruchu palcem po Touch Screenie, początkowo nieskonfigurowanym, powodowało oddalanie kursowa o kilka milimetrów coraz dalej od palca. Przekonfigurowałem Xorga, tak by Touch Screen działał na driverach EloDev’a, co poskutkowało prawidłowym działaniem wyświetlacza. Do testów dla znajomego dokonałem modyfikacji .bashrc, .xinitrc oraz inittab, tak by użytkownik obsługujący aplikację logowany był automatycznie na wyznaczonym przeze mnie terminalu, po czym od razu startowałyby Xy z uruchomioną aplikacją firmową. Tak przygotowane środowisko oddałem koledze do testów.

W instrukcji urządzenia wymieniony został system, z którym konwerter sprawuje się dobrze – chodzi oczywiście o rodzinę Okienek – zapominając o systemie Linux. Błąd ten poprawiono na płytce ze sterownikami (!), na której niestety znaleźć można drivery tylko do starszych dystrybucji RH.

Testy przeprowadzone zostały na starszej dystrybucji SLEDa o jądrze 2.6.16.46.

Po podłączeniu konwertera do portu USB system wykrył nowy sprzęt, co zobaczyć można poniżej (wynik polecenia dmesg | tail):

usb 1-2: new full speed USB device using uhci_hcd and address 2
usb 1-2: new device found, idVendor=067b, idProduct=2303
usb 1-2: new device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-2: Product: USB-Serial Controller
usb 1-2: Manufacturer: Prolific Technology Inc.
usb 1-2: configuration #1 chosen from 1 choice
usbcore: registered new driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
usbcore: registered new driver usbserial_generic
drivers/usb/serial/usb-serial.c: USB Serial Driver core
drivers/usb/serial/usb-serial.c: USB Serial support registered for pl2303
pl2303 1-2:1.0: pl2303 converter detected
usb 1-2: pl2303 converter now attached to ttyUSB0
usbcore: registered new driver pl2303
drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver

lub chociażby w wyniku polecenia lsusb:

Bus 001 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port

Z informacji jakie uzyskałem poleceniem dmesg wynika, że nowe urządzenie widoczne jest w systemie jako ttyUSBo.

Nadszedł czas na podmianę urządzeń (ttyS0 na ttyUSB0) – co w rezultacie oznacza szybkie odlinkowanie portu ttyS0 i stworzenie symlinka ttyS0 kierującego na ttyUSB0. woila!

Testy na dostępnym przeze mnie sprzęcie (drukarka fiskalna ELZAB) zakończone zostały sukcesem – przejściówka działa bez zarzutu

Przeważnie każdy zastanawiał się nad tym czy droga, którą podąża jest właściwa. Zadając sobie to pytanie postanowiłem szukać odpowiedzi w zen. Ponieważ uwielbiam Japonię czasów feudalnych, wielokrotnie wracam do Hagakure, a z powodu braku czasu – moimi papierowymi nabytkami sprzed kilku miesięcy Heiho Kadensho i Gorin-no sho nie nacieszyłem się do końca – późnymi wieczorami poświęcam czas na studiowanie przekazów

Japonia w sieni domowego zacisza…  zakładam, że każdy ma swoją Nibylandię.

Miejsce, gdzie rozpalam kadzidła:

Jeden z lepszych prezentów jaki kiedykolwiek dostałem – Hanko (pieczęć z fonetycznie brzmiącym moim imieniem i nazwiskiem):

Wspaniały otoczony papirusami obraz namalowany techniką sumi-e:

Gekkeikan Sake i ręcznie wykonane czarki do tegoż trunku:

Chwila na refleksję przy muzyce

Zamieniłem OpenBSD 4.1 i BackTrack’a 4, które miałem na hdd właśnie na Solarisa. Mam nadzieję, że nie będę żałował.

Sprzęt na jakim zainstalowałem system Solaris 10 to:

- procesor: Pentium M 1.5 GHz,

- RAM: 512 MB,

- karta graficzna: ATI RADEON 7500,

- wyświetlacz 14″,

- dysk twardy 40 GB.

Do rzeczy.

Ponieważ Solaris jest specyficznym systemem musiałem sprawdzić kompatybilność sprzętową. Udałem się na, co prawda dawno nie aktualizowaną stronę http://www.bolthole.com/solaris/x86-laptops.html i ku mojemu zadowoleniu na liście laptopów znalazłem T40. Faktycznie był mój model, ale testowany na Solaris 9. Istniała szansa, że w stosunku do wersji kolejnej systemu dużo z obsługi sprzętowej nie zostało zmienione.

Pierwsze koty za płoty.

Pierwszym problemem na jaki natknąłem się podczas procesu instalacji to błędy „wyrzucane” przez aplety JAVA. Widziałem kiedyś podobne informacje, gdy uruchamianie zainicjowanej aplikacji, jeszcze przed wczytaniem wszystkich apletów, zostało przerwane przez użytkownika. Na myśl przyszło mi jedno: Okey, jeśli graficzny instalator nie poszedł to spróbuję z konsoli. Tutaj nie było zaskoczenia, wszystko odbyło się wręcz idealnie, mianowicie zgodnie z tym co jest napisane na http://www.sun.com/software/solaris/howtoguides/installationhowto.jsp

Pierwsze uruchomienie i… poszło Moim oczom ukazał się ekran logowania z logiem „Słonecznej firmy”. System używam od prawie miesiąca, narazie nie zauważyłem żadnych mankamentów.

Oto jak wygląda moja nowa-stara zabawka – HOSTNAME Dundee:

]]> http://jastrzebski.wordpress.com/2009/06/18/mania/feed/ 1 jastrzebski cwaniak ;-P http://jastrzebski.wordpress.com/2009/06/12/domena-hosting-i-bezplatna-poczta/ http://jastrzebski.wordpress.com/2009/06/12/domena-hosting-i-bezplatna-poczta/#comments Fri, 12 Jun 2009 08:02:33 +0000 Dariusz Jastrzębski http://jastrzebski.wordpress.com/?p=61 ]]> Od pewnego czasu (ponad 2 lata) jestem posiadaczem domeny .pl. Początkowo strona podlinkowana była do konta na serwerze uczelnianym. W miarę upływu czasu i chęci rozwoju funkcjonalności musiałem pomyśleć o przeniesieniu jej na zewnętrzne DNSy, z czym, niestety wg. regulaminu firmy u której wykupiłem domenę, wiązała się utrata konta pocztowego wielkości 1 GB. Znalazłem więc firmę bplaced (przekonał mnie długi uptime serwerów) oferującą hosting na serwerach znajdujących się u naszego zachodniego sąsiada. W ofercie firmy niestety nie było mowy o koncie pocztowym, musiałem więc poszukać alternatywnego rozwiązania. Czymś takim okazała się usługa „Google for Domains” (7 GB powierzchni na skrzynkę pocztową, możliwość założenia do 50 kont etc.). Ponieważ firma hostingowa nie oferowała wpisów MX ani CNAME u siebie, pomocnym okazało się skorzystanie z serwera pośredniczącego – firmy everydns. Obecnie konfiguracja domeny wygląda następująco:

- na serwerach firmy, u której posiadam domenę, skonfigurowane mam przekierowanie na DNSy firmy everydns,

- na serwerach firmy everydns dopisane mam rekordy A, CNAME do konta na serwerze firmy hostingowej bplaced (oferującej dostęp po DNSach albo po IP!) jak i rekordy MX do usługi „Google for Domains”,

- na serwerach firmy google dopisany mam CNAME z everydns ułatwiający posługiwanie się subdomeną obsługującą pocztę domeny głównej

Obecnie, w związku z reorganizacją witryny i zmianą jej funkcjonalności, chwilowo zawiesiłem działanie www. Co z pewnością w niedługim czasie zmieni się

Statystycznie rzecz biorąc…

Do sprawdzenia jak wygląda wykorzystanie dysków twardych i pamięci podręcznej przy pracy z klastrem posłużyłem się funkcjami statystyk serwera PostgreSQL, a także narzędziami diagnostycznymi systemu Linux: procinfo, ipcs. Funkcje odpowiedzialne za obsługę informacji o odpytaniach, zapisach do bazy standardowo są wyłączone, dlatego pierwszą czynnością jaką należy podjąć jest zmiana takiego stanu rzeczy.

Konfiguracja serwera PostgreSQL znajduje się w pliku postgresql.conf. Sekcja odpowiedzialna za statystyki, jak nie trudno było domyślić się, to „RUNTIME STATISTICS”. To co musiałem zrobić to:

- włączyć kolektor statystyk (funkcja stats_start_collector),

- włączyć funkcję (stats_row_level) odpowiedzialną za zapis i odczyt statystyk do tabeli pg_statio_user_tables,

- włączyć funkcję (stats_reset_on_server_start) odpowiedzialną za restart tabeli statystyk wraz z restartem serwerem PostgreSQL’a.

Po takich zmianach mogłem zrestartować serwer, by załadowane zostały nowe ustawienia.

Testy jakie przeprowadziłem na kilku komputerach architektury x86 dotyczyły pełnej doby i wykonywane były systematycznie przez 1 tydzień o ściśle określonej godzinie, dlatego do pracy zaprzęgnąłem cron’a. Do crontab’a dopisałem skrypt pobierający informację z polecenia procinfo, tabeli statystyk, restartujący statystyki i wysyłający wszystko w pliku załącznika nail’em na mój adres e-mail. W ten sposób otrzymałem wszystkie informację zebrane razem

Najważniejsze informacje, z których korzystałem podczas późniejszej optymalizacji, to pochodzące z:

- bazy PostgreSQL: heap_blks_read (ilość stron odczytanych z dysku) oraz heap_blks_hit (ilość stron odczytanych z pamięci cache),

- wykorzystania systemu (pamięci dostępnej, współdzielonej i SWAPu).

Dla przykładu, wykorzystanie dysku i cache dla maszyny o wielkości klastra: ok. 190 MB i 512 MB RAM, przedstawia się następująco:

Kolejny przykład, tym razem wielkość klastra to ok. 550 MB, również 512 MB RAM:

Co prawda, na obu wykresach widać przewagę odczytu z cache niż z dysku, należy jednak pamiętać, że przy rozroście bazy w ciągu kilku miesięcy nawet o 100% sytuacja na pewno zmieni się.

3, 2, 1, START…

Po tygodniu przeglądania statystyk mówiących o „pracy” bazy przyszła pora na rozpoczęcie działań nad optymalizacją.

Zmianie w konfiguracji PostgreSQL’a w stosunku do wersji sprzed optymalizacji uległy następujące parametry:

- shared_buffers – wartość bufora pamięci jaka zostanie przydzielona serwerowi PostgreSQL (należy zwrócić uwagę na ten parametr, ponieważ po przydzieleniu za dużej wartości serwer zaczyna korzystać ze SWAPu, co z pewnością będzie zauważalne podczas pracy ),

- effective_cache_size – wielkość wydzielonego cache’u przez kernel,

- work_mem – część pamięci niewspółdzielonej, tzn. takiej którą serwer wyodrębniona i wykorzysta na wykonanie pełnej operacji przed zapisem na dysk,

- maintenance_work_mem – część pamięci wykorzystywana m.in. przy „porządkowaniu” bazy,

- max_fsm_pages – wartość mapy wolnego miejsca – wartość pomocna do określenia „wolnego miejsca” przy usuwaniu z tabeli i wprowadzaniu nowych danych.

Dla ułatwienia sobie pracy, wszystkie zmiany jakie ostatecznie dokonałem na pliku konfiguracji PostgreSQL’a, wykonywane były poprzez skrypt przekazujący odpowiednio dobrane dane (wielkość klastra, pamięci RAM – pobrane z systemu – bardzo przydatne narzędzie: awk ; następnie obliczający wszystkie wartości jakie zmieniałem) i zastępujący sed‘em wartości standardowe. Ot taka ze mnie sprytna bestia 

Po zmianach dokonanych w pliku konfiguracyjnym serwera przyszła kolej na przeładowanie usługi.

Oczywiście przy określaniu wielkości parametrów, których wartość mogę zmienić, przydatne okazały się wspomniane wcześniej narzędzia systemowe (procinfo oraz ipcs).

A teraz punkt kulminacyjny, czyli porównanie działań dla obu maszyn (pierwsza z klastrem wielkości ok. 190 MB, druga to klaster ok. 550 MB):

Nawet na tak małej bazie widoczne są różnice