Miesiąc: luty 2011

/var/lock i /var/run w RAM-ie na Debianie

Na co dzień mam do czynienia z Debianem, Gentoo i Ubuntu. W tych dwóch ostatnich systemach katalogi /var/lock i /var/run zamontowane są na ramdysku. Ma to sporo sensu ponieważ do tych katalogów dość często zapisywane są małe pliczki, a dane są ulotne (po resecie i tak tracą znaczenie). Dzięki przeniesieniu tych danych do RAM-u oszczędzamy mechanikę dysku, miejsce, a i pewnie trochę przyspieszamy działanie systemu.

Debian prezentuje bardziej konserwatywne podejście, wspomniane katalogi są tworzone w głównym katalogu. Na szczęście przeniesienie ich do RAM-u sprowadza się do zmiany dwóch linijek w pliku /etc/default/rcS:

TMPTIME=0
SULOGIN=no
DELAYLOGIN=no
UTC=yes
VERBOSE=no
FSCKFIX=no
RAMRUN=yes
RAMLOCK=yes

Zmienione linijki pogrubiłem. Po wykonaniu tych zmian trzeba wykonać reset i voila:

System plików         rozm. użyte dost. %uż. zamont. na
/dev/mapper/gt500-root
                      7,4G  1,6G  5,5G  23% /
tmpfs                 999M     0  999M   0% /lib/init/rw
varrun                999M  420K  998M   1% /var/run
varlock               999M     0  999M   0% /var/lock
udev                  994M  160K  993M   1% /dev
tmpfs                 999M     0  999M   0% /dev/shm
/dev/sda1              89M   16M   69M  19% /boot
/dev/mapper/gt500-home
                      104G   17G   88G  16% /home

Jak wyczytałem w dokumentacji Debiana, niektóre starsze programy źle działają jeśli /var/lock i /var/run nie są obecne na dysku. Na moim serwerku mam sporo softu (m.in. Apache, MySQL, PostgreSQL, Exim, ProFTPd, memcached) i nie zauważyłem żadnych problemów. Dlatego zgaduję, że w większości instalacji Debiana, zarówno desktopowych jak i serwerowych, warto pokusić się o wykonanie omawianej zmiany.

Doctrine Query Cache w Symfony

Dzisiaj o odkrywaniu Ameryki w konserwie. Właśnie takie miałem wrażenie, gdy dłubiąc w projekcie trafiłem na rozdział na temat cache w dokumentacji Doctrine. Wcześniej tam nie trafiłem, bo całe keszowanie robiłem w Symfony – wszak do pamięci podręcznej najlepiej wrzucać efekt końcowy. Dodatkowo w dokumentacji Symfony nie rzuciło mi się w oczy nic na temat cacheowania w Doctrine.

Nie zamierzam streszczać dokumentacji Doctrine. W kontekście tej notki ważne jest, że Doctrine może zapamiętywać w cache dwa rodzaje danych:

  • skompilowane zapytania
  • wyniki zapytań

Dzięki zapamiętywaniu zapytań czasochłonny proces parsowania zapytania i budowania docelowej SQL-ki jest wykonywany tylko raz, kolejne wywołania będą korzystać z danych zapamiętanych w pamięci podręcznej. Problem aktualności danych w cache nie istnieje ponieważ zmiana zapytania spowoduje automatyczne wygenerowanie nowych danych. Korzyści są niebagatelne, użycie proste jak konstrukcja cepa, a problemów nie ma. Dlatego zgodnie z dokumentacją i zdrowym rozsądkiem, pamięć podręczna zapytań powinna być zawsze włączona, nawet w środowisku testowym.

Włączenie cache dla Doctrine w projekcie Symfony jest banalne i sprowadza się do dodania króciutkiej metody w klasie config/ProjectConfiguration.class.php.

public function configureDoctrine(Doctrine_Manager $manager)
{
    $manager->setAttribute(Doctrine_Core::ATTR_QUERY_CACHE, new Doctrine_Cache_Apc());
}

Powyższy kod spowoduje, że skompilowane zapytania będą zapamiętywane w pamięci APC. Oprócz APC Doctrine może współpracować z serwerem memcached lub inną bazą danych (np. SQLite).

Cache można włączyć nie tylko na poziomie managera, równie dobrze można zrobić to w samym zapytaniu:

$q = Doctrine_Query::create()
    ->useQueryCache(new Doctrine_Cache_Apc());

Jak wspomniałem wcześniej, pamięć podręczna zapytań powinna być włączona zawsze. Na poziomie konkretnego zapytania więcej sensu ma włączanie zapamiętywania wyników:

$q = Doctrine_Query::create()
    ->useResultCache(new Doctrine_Cache_Apc());

Wymiatacze z TVN-u

Irytuje mnie postawa „Polak potrafi… spierdolić”, która często pojawia się w dyskusjach na temat różnorakich dokonań Polaków. Jednak gdy widzę coś takiego, jak „Wymiatacze” to zaczynam wierzyć, że coś jest na rzeczy.

W tym miejscu należy się wyjaśnienie. Dawno temu japoński teleturniej „Takeshi’s Castle” zauroczył mnie od pierwszych sekund. Ponieważ jeden obraz mówi więcej niż tysiąc słów posłużmy się dowodem rzeczowym numer jeden:

Czytaj dalej „Wymiatacze z TVN-u”

Bidet

Ta notka będzie stanowić dla mnie katharsis i to w sensie dosłownym, gdyż rzecz będzie o oczyszczeniu, jednak nie duszy. Z niejakim zażenowaniem muszę przyznać, że dopiero niedawno poznałem funkcję bidetu. Wcześniej przez długie lata sądziłem, że służy on do mycia nóg. Z błędu wyprowadziła mnie moja ukochana, a śmiechu było co niemiara.

Laughs have been had i w tym miejscu można by postawić kropkę, ale zacząłem zastanawiać się skąd wzięły się moje wyobrażenia o funkcji bidetu i jakim sposobem przez blisko trzydzieści lat brutalna prawda nie zdołała się przebić przez mury mej ignorancji. Uzupełniając wspomnienia domysłami wyszło mi, że po raz pierwszy z bidetem spotkałem się na zdjęciu, zapewne w jakimś katalogu wyposażenia łazienek, a miałem wtedy lat małonaście. Ponieważ z kontekstu w którym zdjęcie występowało nijak nie wynikała funkcja tego urządzenia, więc musiałem dorobić sobie własną interpretację na podstawie doświadczeń. Z doświadczenia zaś wiedziałem, że jeśli chce się dokonać szybkiej ablucji to niewygodnie jest zadzierać nogę do umywalki. Logicznym remedium na te niedogodności zdawało mi się urządzenie z bieżącą wodą wysokości mniej więcej klopa. Wypisz, wymaluj bidet. Logiczne, nie?

Teraz zastanawiam się ile jeszcze takich bidetów kryje mój leksykon.

W ramach post scriptum bidet z tubki.