Indexék cikket írnak "Kis ország, kis Google" címmel. A szerző a beavatottság és a top secret klasszifikáció légkörét idéző gondolatmenettel túráztatja a billenytűzetét, és csigázza az olvasó kíváncsiságát, amely körmeit rágva vár arra, hogy most végre megtudja az igazságot az UFO, izé a Google magyarországi szerverparkjáról (1, vagy 0, TRUE, vagy FALSE?):

[...] kivéve talán azt a vicces álláshirdetést, amelyben 8-10 kilogrammos tárgyak felemelésére is képes erőembereket keresett, nem sokkal a cégbejegyzés után.

Az éles eszű megfigyelők rögtön arra gondoltak, hogy a Google Magyarországon is felállít egy szerverparkot, mert mi másra kellene neki erőember, de hogy vannak-e a Google-nek szerverei itthon, az máig titok: a cég munkatársai szerint az infrastruktúrát úgy építették meg, hogy mindegy, vannak-e az országban a keresést és az alkalmazásokat kiszolgáló gépek, vagy nincsenek. "Lehet, hogy egy szerverpark sincs Magyarországon, de lehet, hogy három is van" – válaszolták a múlt héten az Index kérdésére.

Most persze mondhatnám, hogy hvazzeg Mártikám, minden nap a Google-höz megyek 8-10 kilogrammos tárgyakat emelgetni -és már kurvára unom, mert a hiedelmekkel ellentétben ezzel a Google-nél sem lehet BKV-s jövedelmeket kapni-, és ilyeténformán a saját fél (ép, a másikat kiszúrta egy kiálló Google-szerver éles sarkú alaplapja) szememmel láttam, hogy igenis van Magyarországon Google szerverpark. Sőt, nem csak láttam, de éreztem is, a Google szerverparkjában ugyanis -az itteni irodai dolgozók munkahelyével ellentétben, ami szimpla, és unalmas- ugyanolyan kreatív megoldások vannak, mint a külföldi Googleplexekben.
Mert hát az irodistákkal ellentétben az, hogy a szerverek jól érezzék magukat kiemelt fontosságú, így van nekik csúszda, amivel az első emeleti gépteremből a földszintibe csúszhatnak, ha fent megállna a router, van akvárium, amiben nézhetik a halakat a kádból (ez egyébként csak a you tub szerverek kiváltsága), és van pingpongasztal az ICMP könnyebb gyakorlásához, stb.

De persze nem mondom, mert akkor kiszúrják a másik szemem is.

suckit: cerfdeo Ja és az érzés: a Google hazai szerverparkjában Vint Cerf "v4" típusú dezodorral illatosítanak minden félórában! Bár állítólag ez már nem sokáig megy tovább, mert lassan kifogy, újabbat meg ebből már nem gyártanak, de majd jön a következő "v6" illat. Izgatottan várom, szeretem ezt a határozott, karakteres illatot.

Kicsit szégyellem bevallani, de otthonra is loptam már ilyet, hiába a nyomdában lehúzott évek nem múltak el nyomtalanul -éérted- (csak ott még a pornót loptuk, itt meg az illatot). Teljesen feldobja a lakást, és mindenki irigykedve kérdezi, hogy mi ez, mire büszkén felelhetem, hogy: a Google illata!

A barátnőm avonos barátnői, és az én amwayes ismerőseim is epekednek utána, de ilyet akárhogy is törik magukat, nem tudnak beszerezni a nyamvadt MLM ügynöküktől!

Na szóval mivel nem mondhatom, inkább mutatom. Jól figyeljetek, most kiderül minden!

Először is a ping. A www.google.com néhány helyről olyan közel van, hogy nem lehet távol. Tudjátok, lehet a Google-nek sok pénze, vehet terabiteket minden kontinensre, de Amerika innen a távoli Balkánról akkor is kurva messze van. A fény meg lassú, de az elektronok sem gyorsabbak. A Szub-Éta meg még csak a Galaxis Utikalauzban van.

Szóval az még jó eséllyel az otthoni csellóról is kiderül, hogy a www.google.com közelebb van, mint a mail.kisbőgő.hu. Ez meg már gyanús (már látom, körvonalazódik a fejekben a következő cikk, amelyben lerántják a leplet a kék articsókás cégről, hogy az alig létezik Magyarországon, ami itt látható az csak egy transzdimenzionális szubtrakció az ottani végtelen kapacitásrengetegből).

Még gyanúsabb, ha valami jobb helyről próbáljuk, mondjuk pár szerverhosting szolgáltatótól, mint például:

 2  GE-0-0-12.border0.interware.hu (195.70.32.4)  1.006 ms  0.649 ms  0.993 ms
 3  bpt-b2-link.telia.net (213.248.103.105)  0.980 ms  0.713 ms  0.977 ms
 4  bpt-b1-link.telia.net (80.91.250.64)  1.981 ms  1.674 ms  0.968 ms
 5  ffm-bb2-link.telia.net (80.91.247.54)  20.981 ms  20.697 ms  19.981 ms
 6  ffm-b7-link.telia.net (80.91.254.253)  20.984 ms
    ffm-b7-link.telia.net (80.91.251.234)  20.676 ms *
 7  google-118152-ffm-b7.c.telia.net (213.248.102.234)  18.976 ms
    google-ic-127675-ffm-b7.c.telia.net (213.248.89.42)  19.653 ms
    google-ic-127674-ffm-b7.c.telia.net (213.248.89.38)  28.681 ms
 8  209.85.255.176 (209.85.255.176)  19.778 ms
    209.85.255.178 (209.85.255.178)  19.747 ms  18.743 ms
 9  72.14.236.250 (72.14.236.250)  18.970 ms
    72.14.232.103 (72.14.232.103)  18.740 ms  18.771 ms
10  209.85.248.39 (209.85.248.39)  18.941 ms  19.692 ms
    209.85.248.43 (209.85.248.43)  18.974 ms
11  72.14.238.101 (72.14.238.101)  18.731 ms
    72.14.232.217 (72.14.232.217)  18.757 ms
    72.14.238.105 (72.14.238.105)  30.745 ms
12  hb-in-f99.google.com (74.125.87.99)  19.744 ms  19.662 ms  18.980 ms

Ja, bocs, nem, kivétel erősíti a szabályt, de:

  2  TenGE-7-1.hubud.datanet.hu (194.149.20.253)  0.296 ms  2.889 ms  0.718 ms
 3  74.125.50.141 (74.125.50.141)  0.572 ms  0.555 ms  0.572 ms
 4  209.85.242.228 (209.85.242.228)  0.717 ms  0.660 ms
    209.85.242.230 (209.85.242.230)  0.712 ms
 5  209.85.248.41 (209.85.248.41)  0.674 ms
    209.85.248.39 (209.85.248.39)  0.818 ms
    209.85.248.47 (209.85.248.47)  0.792 ms
 6  72.14.238.101 (72.14.238.101)  13.492 ms
    72.14.232.221 (72.14.232.221)  5.640 ms  13.230 ms
 7  hb-in-f99.google.com (74.125.87.99)  1.292 ms  1.134 ms  1.016 ms

és:

 3  84.1.104.212 (84.1.104.212)  0.459 ms  0.362 ms  0.416 ms
 4  google.osr1-dataplex.net.telekom.hu (81.183.247.98)  0.648 ms  0.698 ms 0.662 ms
 5  209.85.242.228 (209.85.242.228)  0.662 ms
    209.85.242.230 (209.85.242.230)  0.702 ms  7.555 ms
 6  209.85.248.39 (209.85.248.39)  0.664 ms
    209.85.248.47 (209.85.248.47)  0.709 ms  0.877 ms
 7  72.14.238.105 (72.14.238.105)  0.971 ms
    72.14.232.217 (72.14.232.217)  3.633 ms
    72.14.238.105 (72.14.238.105)  1.138 ms
 8  hb-in-f99.google.com (74.125.87.99)  1.134 ms  1.286 ms  1.285 ms

Azt mondja, hogy google.osr1-dataplex. Nahát, ezek szerint nem csak az derült ki, hogy van Google szerverpark Magyarországon, hanem az is, hogy a Dataplexben van. És még csak oda sem kellett mennünk. Hol tart már a technika!

De lehetünk még tudományosabbak: a minimum RTT 1,016 ms. Ez azt jelenti, hogy az ICMP kérés elküldése és a válasz megérkezése között legfeljebb kb. 1 ms telik el.

Ez azt jelenti, hogy ha az adatutak szimmetrikusak, 0,5 ms-ba telik az információnak, míg odaér. Ebben persze benne van sok minden, például az információ sem nulla hosszú, illetve a fizikai továbbításhoz képest az eszközök okozta késleltetés (router kitalálja, hogy mi legyen, rossz esetben a route táblája alapján (ilyen elég sokszor volt, ahogy fent is látszik), jó esetben valami alacsonyabb réteg alapján (pld. MPLS, amely hopjait itt nem láthatjuk), checksumot ellenőriz, TTL-t csökkent, stb).
Legyünk jóindulatúak, és állítsuk azt a természettől elrugaszkodott elképzelést, hogy a hálózati eszközök semmit sem késleltetnek.

Ez esetben (299792458/1000)*(1,016/2)=152294, azaz a fény által megtett út 1 ms-ra vetítve, szorozva a RTT felével kiadja a maximális úthosszt, azaz 152 km-t.

A Google szerverei tehát Budapesttől legfeljebb 152 km-re vannak, azaz nagy eséllyel Magyarországon. Valójában persze az átvitel ennek kb. tizede (vagy még annyi sem), így a 152 km inkább 5-15 km, a többi a csomagfeldolgozás késleltetése.

Ennyi matek épp elég is volt mára, így búcsúzom is. Holnap korán kell kelni, és sok 8-10 kilogrammos tárgyat kell még emelnem.

Feküdjön tehát mindenki azzal a boldog tudattal, hogy van Google szerverpark Magyarországon!

Juhéj!

A korábbi cikkekből megtudhattuk hogy teljesít a MySQL FreeBSD-n, és hogy mennyit gyorsult a 8-as kiadással a 7-eshez képest. De ez elég vajon ahhoz, hogy a Linuxot és az OpenSolarist lekörözze?

Íme:

suckit: mysql-bsdlinsol-rw.png

A sysbench read-write teszten a Linux (ext3-mal, lásd korábbi cikket, ez adja Linuxon a legnagyobb teljesítményt) keményen otthagyja a FreeBSD-t és az OpenSolarist. A FreeBSD 64 szálig képes ráverni a Solarisra, de utána egy erősebb visszaesés következik, ahol az OpenSolaris kiengyensúlyozottabb teljesítményt képest nyújtani.

Ugyanez a read-only tesztekben a következőképpen alakul:

suckit: mysql-bsdlinsol.png

Az eredmények hasonlók, bár az OpenSolaris hamarabb veszi át a dobogó második helyét a FreeBSD-től, mint a RW tesztnél.

Konklúzió: a Linux visszavette a FreeBSD-től az elsőséget annak ellenére, hogy ez utóbbi is jelentős fejlődésen ment keresztül. Az OpenSolaris ugyanabban cipőben jár teljesítmény szempontjából, mint a FreeBSD, ha pedig megnéznénk a Solaris 10-et valószínűleg hasonló eredményeket látnánk, azaz a FreeBSD hetes és nyolcas kiadása kb. úgy arányulna egymáshoz, mint a Solaris 10 és az OpenSolaris.

Íme a világ legjobban fizetett vállalatvezetői 2008-ban:

suckit: ceo

Larry Ellisont nem kell bemutatni, hiszen aki eddig nem találkozott vele, most már a csapot megengedve is őt hallhatja, amint próbálja meggyőzni a nagyközönséget (Európát), hogy cége egyesülése a Sunnal jó lesz mindenkinek.

Az ábráról nem csak azt tudhatjuk meg, hogy a főemberek mennyi milliót tettek zsebre, hanem azt is, hogy ebből a pénzből hány minimálbéren élő embert lehetne eltartani... az USA-ban.

Nálunk persze nem 15.081 (amerikai) dollár, azaz 227.795 forint a havi minimálbér, hanem 69 ezer forint (2008-as adat), így a jól kereső felsővezetők zsámolyain szereplő számokat 3,3-del kell szorozni, azaz kedvencünk, Larry Ellison tavalyi pénzéből 18509 magyar minimálbérest lehetne eltartani.

A többit meg úgyis zsebbe kapják...

A Linux sok területen a választásról szól. És most nem arra gondolok, hogy nem muszáj használni, lehet mást telepíteni. :)

Fájlrendszer fronton számos lehetőségünk van, amelyek között sokan személyes preferencia (ezt ismerem, ezt szeretem) alapján választanak. De vajon melyik fájlrendszer teljesít a legjobban MySQL alatt?

Nézzük:

suckit: mysql-linuxfs-rw.png

A fájlrendszerek a standard beállításaikkal lettek megformázva, a hardver és szoftverkörnyezet a korábbiakban említett (MySQL és PostgreSQL történelem cikkek).

Meglepő, hogy az ext3 ilyen fölényesen gyaláz mindenkit, a feltörekvő, új generációs FS-ek (btrfs, ext4) pedig mennyire rosszul teljesítenek...

A MySQL és PostgreSQL történelem cikkek alapját képező adathalmaz további elemzése közben újabb grafikonok születtek. Ezek a MySQL és a PostgreSQL viselkedését mutatják FreeBSD (8) alatt, UFS és ZFS háttértáron. A (szoftver és hardver) konfiguráció változatlan, a MySQL-nél viszont két mérés is készült, amelyek között az eltérés a MySQL innodb_flush_log_at_trx_commit opciójában volt.
Az egyik esetben ennek értéke egy volt (ACID-compliant, minden tranzakció után flush), a másikban kettő (másodpercenkénti flush a logokon).

MySQL:

suckit: mysql-durable.png

Mint látható, a MySQL-t nagyrészt hidegen hagyja, hogy a fenti opció mire van állítva, sőt, az elvileg rosszabb teljesítményt adó 1-es értéknél 512 szálnál erős kiugrás látható.
Látszik továbbá, hogy az UFS és a ZFS közt elhanyagolható különbség van.
Ezek valószínűleg annak köszönhetők, hogy a két 15kRPM-es SAS diszk egy BBWC-s RAID vezérlőn csücsültek, az írás pedig nem volt annyira durva, hogy a ZFS dupla írását (journaling, ZIL) és a sűrű syncelést, vagy az UFS egyszeres írását és syncelését ne tudja "elkenni", és azokat gyorsan a cache-be tömni, majd visszaigazolni az OS-nek.

Ugyanez PostgreSQL-lel már kicsit szomorúbb képet fest:

suckit: pgsql-durable.png

A PostgreSQL alapból a MySQL fenti beállításának egyes értékét használja (fsync minden tranzakció után). Megfigyelhető, hogy ha valaki PostgreSQL-t szeretne ZFS-en használni, érdemes utánaolvasnia mind a ZFS, mind pedig a PostgreSQL működésének, ha valami teljesítményhez hasonlót ki szeretne húzni a rendszeréből.

Természetesen ez minden más esetben sem árt...

Itt van ez az indexes cikk a második nagy telekomos hálózati meltdownról.

A néha meg-megváltozó cikk mostani állapotában például ezt olvashatjuk:

Olvasóinktól annyit tudunk, hogy a Magyar Telekom adatközpontjában, a Datacenterben lévő weboldalak közül több elérhetetlenné vált, és hogy sok felhasználó panaszkodik az akadozó internetelérésre.

A Magyar Telekom sajtóosztályától elmondta, hogy péntek délután 16 óra körül az ügyfeleik egy része valóban tapasztalhatott problémát az internet elérésben. A szakértők intézkedtek, és 17 óra előtt a szolgáltatások már működtek.

(kiemelések tőlem) "a Datacenterben", ezen könnyesre röhögtem magam, de nem is ez a legjobb, hanem a cikk végén felejtett reklám:

A cikk T-Mobile szélessávú eszközök segítségével készült. (x)

Elképzeltem, hogy miközben "a Datacenterben" a routerek épp azon gondolkoztak, hogy most akkor merre is menjenek azok a fránya csomagok, meg a DNS szerverekkel is volt valami kefe, szóval eközben a mit sem sejtő indexes kollegák "T-Mobile szélessávú eszközök segítségével" írják bőszen a cikket. A Magyar Telekom hálózatából.

Kb. ennyire szenzációhajhász szokás szerint az egyik nagy magyar hírsite (amely többször változtatott már a cikken, lassan csurog az info, ha nincs internet, na :).

A HUP-on (szintén szokás szerint) viszont már pontosabb információk keringenek:

Állítólag leszakadt T-com, Hungarnet, UPC is a BIX-ről, mert túl alacsony prefixlimitjük volt.


A T -nél igen, :)

A Hungarnet forgalmában drámai visszaesés nem látható:

suckit: hbone.png

A UPC viszont már jobban megszenvedte a dolgot:

suckit: upc1.png suckit: upc2.png

De a legdurvább változás a Magyar Telekom BIX kapcsolatában mutatkozik, amely gyakorlatilag szummában is nullára esett, azaz a private peeringeket nem számolva leszakadt a magyar internetről, hogy a haza forgalmát a nemzetközi uplinkeken cserélje ki a többi szolgáltatóval:

suckit: mt1.png suckit: mt2.png

 

Ez elvben túl sok problémát nem is kellett volna, hogy okozzon, azonban a T nemzetközi kapcsolatainak telítődése (valószínűleg azért sok van neki, az sem kizárt, hogy a BIX felé menő forgalom is elférjen rajta), és a többi hazai ISP limitáltabb nemzetközije olyan belassulást eredményezhetett, amitől sok minden szenvedett.

A zárt körű BIX levelezőlistáról származó információk alapján pár nappal ezelőtt (október 5-én) a BIX üzemeltetője tájékoztatta a BIX-tagokat arról, hogy egy új tag (AS9002, RETN) fog csatlakozni a BIX route szervereire, amely miatt a most kb. 5e-es prefix lista 9 ezresre fog nőni, és ez problémát okozhat pár routernél.

Ez a levél azonban "elakadt" a listaszerveren, így a BIX-tagok nem kapták meg. A BIX üzemeltető a levelet ma (16:20-kor) újraküldte (nézzünk csak egy kicsit feljebb...), kiegészítve némi infóval arra vonatkozóan, hogy ez hol okozhat még problémát (időközben kiderült?).

Az, hogy a legtöbb szolgáltató lazán átvészelte ezt az új helyzetet, a Magyar Telekom routerei viszont teljesen behaltak tőle azért felvet pár érdekes kérdést...

ZFS ARCvesztés

2009.10.08. 10:20

A ZFS ARC (Adaptive Replacement Cache, az IBM "találmánya") valósítja meg a fájlrendszer cache-t, azaz a sűrűn használt objektumokat igyekszik memóriában (vagy az L2ARC esetében valamilyen, a diszkeknél gyorsabban elérhető -pld. SSD- médián) tartani.

Az ARC külön válik a unified(VM) buffer cache-től, így a FreeBSD-n (is) sok problémát okozott a kezdeti időkben, a kis memóriával rendelkező (jellemzően 32 bites) gépeken a leggyakoribb probléma a kernelmemória elfogyása volt, amit az ARC és a kmem méretének gondos beállításával lehetett többé-kevésbé orvosolni.

A probléma kezelésére született meg még májusban az a FreeBSD commit, amely lehetővé teszi a VM számára, hogy ha memóriára van szüksége, visszavegyen a ZFS ARC-tól.

Sajnos ezzel viszont teljesen más problémák jöttek elő. A ZFS cache mérete egy ideig nőtt, majd -olyan esetekben is, ahol ez amúgy indokolatlan- drasztikusan csökkent, ahogy az alábbi képen is látni lehet:

A problémát többen felvetették, és visszaigazolták (a grafikon is egy ilyen bejelentésből származik), pld. itt és itt, a megoldás viszont váratott magára, annak ellenére, hogy Kip Macy, az egyik ZFS fejlesztő is elismerte a hibát.

Jó hír tehát azoknak, akik ettől a hibától szenvedtek, hogy (elvileg) végre megszületett a megoldás, amely lehetővé teszi a kernelnek, hogy visszavegyen a ZFS ARCából, de megakadályozza, hogy ez feleslegesen történjen.

Szerző: blackshepherd

2 komment

Címkék: arc zfs

Falcon vagy InnoDB?

2009.10.07. 22:05

A csecsemőhalált halt MySQL 6.0 újdonsága lett volna a Falcon storage engine, amely az ígéretek szerint "lightning fast, large memory, multi-cpu aware".

24 mag, 128 GiB RAM eléggé multi-cpu (jó, az UltraSPARC CMT-khez képest nem, és persze itt sem CPU-kból, mintsem magokból van sok) és large memory, nézzük meg mit tud ezen a MySQL!

Az Oracle-akvizícióval teljesen logikusnak tűnik, hogy a cég pénzt fektessen egy olyan ki-, vagy továbbfejlesztésébe, amellyel egyébként már rendelkezik (InnoDB, Berkeley DB), így hát könnyen megeshet, hogy most találkozunk utoljára a sólyommal. Temessük méltósággal, ha kell valakinek, úgyis kimászik a föld alól.

suckit: mysql-6.0.png

A képen a 6.0.11-es verzióban lévő InnoDB és Falcon engine küzd a felturbózott 5.4.1-es InnoDB-jével. Mint látszik, a Falcon a 6-os verzióban 32 szálig konzisztensen alatta marad az InnoDB-nek, de 32 szál felett már látszik valami teljesítmény.

Sajnos ez pont semmit sem ér az 5.4-ben meghegesztett InnoDB-vel szemben. Természetesen az InnoDB-t összehasonlítani az alfa verziós Falconnal nem biztos, hogy igazságos, de hát ez van, hasonlítanám én a GA-hoz is, ha lenne olyan...

Read write fronton a grafikon eképpen néz ki:

suckit: mysql-6.0-rw.png

A Falcon itt sem kápráztat el minket, de legalább kiegyensúlyozottabban lassú, mint az InnoDB. Ez is egy eredmény...

Téteket, fogadásokat: lesz-e falcon/maria a MySQL-ben? Lesz-e MySQL? :)

HP backup system ROM

2009.10.05. 19:27

Firmware frissítés HP szerveren. Rutinfeladat. De most az egyszer nem.

Indulás után a következő fogad:

FATAL ROM ERROR: The System ROM is not Properly Programmed

 No para, ezért van a backup system ROM. Mindjárt ki is írja, hogy azzal bootol...

... majd pár másodperc múlva...

... a következő bootnál...

... ha resetelem, azt fogja bootolni...

... ha kikapcsolom, azt fogja bootolni...

MIKOR FOGJA AZT A ROHADT BACKUP ROM-OT BOOTOLNI?!

Manual elővesz, megnéz mi a teendő ilyenkor. Azt mondja, hogy:

FATAL ROM ERROR: The System ROM is not Properly Programmed.
      Audible Beeps: 1 long, 1 short
      Possible Cause: The System ROM is not properly programmed.
      Action: Replace the physical ROM part.

B+. Google. Azt mondja, hogy nyomjak F9-et, majd a BIOS-ból válasszam ki, hogy az előző ROM-ot szeretném bootolni. DE NINCS BIOS!

Aztán ráakadtam erre:

To Boot to a Backup ROM:

To access the redundant ROM through RBSU:
1. Access RBSU by pressing the F9 key during powerup when the prompt is displayed in the upper right corner of the screen.
2. Select Advanced Options.
3. Select Redundant ROM Selection.
4. Select the ROM version.
5. Press the Enter key.
6. Press the Esc key to exit the current menu or press the F10 key to exit RBSU. The server restarts automatically.


To access the redundant ROM manually:
1. Power down the server
2. Remove the access panel
3. Set positions 1, 5, and 6 of the system maintenance switch to On.
4. Install the access panel
5. Power up the server
6. Wait for the server to emit two beeps.
7. Repeat steps 1 and 2.
8. Set positions 1, 5, and 6 of the system maintenance switch to Off.
9. Repeat steps 4 and 5.

(az első értelemszerűen NO GO nálam)

Eljátszottam, vártam a két bip-et. Nem volt. Kezdtem aggódni. A biztonság kedvéért vártam kb. négy percet, majd folytattam.

A poweron után lélegzetvisszafojtva vártam az eredményt.

HP logo... Szünet. Indul!

Huh.

Igen, a válasz egyértelmű igen:

suckit: mysql-fbsd78.png suckit: mysql-fbsd78-rw.png suckit: pgsql-fbsd78.png suckit: pgsql-fbsd78-rw.png

Brutálisnak tűnik, és az is:

FreeBSD performance improvement between 7.x and 8.x
Test Peak performance 7.x->8.x
MySQL OLTP RO 1.6970x
MySQL OLTP RW 1.7843x
PostgreSQL OLTP RO 1.9257x
PostgreSQL OLTP RW 3.1556x


Ha valaki azt gondolná, hogy nem normális, ha egy OS két verziója között másfél-háromszoros teljesítménykülönbség van két ilyen komplex alkalmazásban, valószínűleg igaza van. Ez azt mutatja, hogy a FreeBSD messze van még a multicore mennyországtól, de minden kiadással közelebb kerül hozzá, ahogy Kris Kennaway FreeBSD fejlesztő korábbi mérései is mutatják.
Nem is beszélve arról, hogy az akkor mért Linux sem állt éppenséggel a csúcson.

Hogy mégis mi okozza ezt a gyorsulást? A FreeBSD 8-ban már alapértelmezetten engedélyezett a superpages támogatás, aztán az ULE ütemezőn is reszeltek kicsit, amely immáron képes a CPU-k, illetve a rajtuk található cache-ek hierarchiáját is felismerni, és hasznosítani.
Sajnos ez a felismerés még messze van a tökéletestől, ugyanis a tesztgép topológiája az alap FreeBSD 8 szerint így néz ki:

kern.sched.topology_spec: <groups>
 <group level="1" cache-level="0">
  <cpu count="24" mask="0xffffff">0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23</cpu>
  <flags></flags>
  <children>
   <group level="3" cache-level="2">
    <cpu count="6" mask="0x3f">0, 1, 2, 3, 4, 5</cpu>
    <flags></flags>
   </group>
   <group level="3" cache-level="2">
    <cpu count="6" mask="0xfc0">6, 7, 8, 9, 10, 11</cpu>
    <flags></flags>
   </group>
   <group level="3" cache-level="2">
    <cpu count="6" mask="0x3f000">12, 13, 14, 15, 16, 17</cpu>
    <flags></flags>
   </group>
   <group level="3" cache-level="2">
    <cpu count="6" mask="0xfc0000">18, 19, 20, 21, 22, 23</cpu>
    <flags></flags>
   </group>
  </children>
 </group>
</groups>

Holott, ahogy az az alábbi képen is látható, ezen a CPU-n teljesen máshogy néz ki a cache-hierarchia: suckit: 7356 large intel dunnington.png

A korrekt hierarchia felismerése végett az alábbi kernelpatch-csel bővítettem az egyelőre elég manuális listát a subr_smp.c-ben:

       case 8:
               /* six core, 3 dualcore parts on each package share l2.  */
               top = smp_topo_2level(CG_SHARE_L3, 3, CG_SHARE_L2, 2, 0);
               break;

amely módosításnak köszönhetően immár megfelelően látta a kernel a topológiát:

kern.sched.topology_spec: <groups>
 <group level="1" cache-level="0">
  <cpu count="24" mask="0xffffff">0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23</cpu>
  <flags></flags>
  <children>
   <group level="3" cache-level="3">
    <cpu count="6" mask="0x3f">0, 1, 2, 3, 4, 5</cpu>
    <flags></flags>
    <children>
     <group level="5" cache-level="2">
      <cpu count="2" mask="0x3">0, 1</cpu>
      <flags></flags>
     </group>
     <group level="5" cache-level="2">
      <cpu count="2" mask="0xc">2, 3</cpu>
      <flags></flags>
     </group>
     <group level="5" cache-level="2">
      <cpu count="2" mask="0x30">4, 5</cpu>
      <flags></flags>
     </group>
    </children>
   </group>
   <group level="3" cache-level="3">
    <cpu count="6" mask="0xfc0">6, 7, 8, 9, 10, 11</cpu>
    <flags></flags>
    <children>
     <group level="5" cache-level="2">
      <cpu count="2" mask="0xc0">6, 7</cpu>
      <flags></flags>
     </group>
     <group level="5" cache-level="2">
      <cpu count="2" mask="0x300">8, 9</cpu>
      <flags></flags>
     </group>
     <group level="5" cache-level="2">
      <cpu count="2" mask="0xc00">10, 11</cpu>
      <flags></flags>
     </group>
    </children>
   </group>
   <group level="3" cache-level="3">
    <cpu count="6" mask="0x3f000">12, 13, 14, 15, 16, 17</cpu>
    <flags></flags>
    <children>
     <group level="5" cache-level="2">
      <cpu count="2" mask="0x3000">12, 13</cpu>
      <flags></flags>
     </group>
     <group level="5" cache-level="2">
      <cpu count="2" mask="0xc000">14, 15</cpu>
      <flags></flags>
     </group>
     <group level="5" cache-level="2">
      <cpu count="2" mask="0x30000">16, 17</cpu>
      <flags></flags>
     </group>
    </children>
   </group>
   <group level="3" cache-level="3">
    <cpu count="6" mask="0xfc0000">18, 19, 20, 21, 22, 23</cpu>
    <flags></flags>
    <children   <group level="5" cache-level="2">
      <cpu count="2" mask="0x300000">20, 21</cpu>
      <flags></flags>
     </group>
     <group level="5" cache-level="2">
      <cpu count="2" mask="0xc00000">22, 23</cpu>
      <flags></flags>
     </group>
    </children>
   </group>
  </children>
 </group>
</groups>

Sajnos azonban van még mit faragni az ütemezőn, mert jól látszik, hogy nem bírja ellátni munkával ezt a gépet, amely erősen kihat a rá futó alkalmazások teljesítményére...

MySQL történelem

2009.10.03. 19:40

You can read this article in english!

Ez a cikk a PostgreSQL történelem folytatása, az előzményeket, és a mérés hátterét ott ismerheted meg.

Láttuk mit tud a PostgreSQL, nézzük mire képes a nagy ellenség!

Először is tekintsük át, hogy a tesztelt verziók (4.1.25, 5.0.85, 5.1.38, 5.4.1 és 6.0.11) mikor jelentek meg:

MySQL versions
branch/version/release date First release Tested release
4.1 2003-04-03 2008-12-01
5.0 2003-12-22 2009-08-11
5.1 2005-11-29 2009-09-01
5.4 2009-04-05 2009-06-22
6.0 2007-04-30 2009-05-11


Két kakukktojás van a tesztben. Az egyik az 5.4, amely a Sun szerint egy "performance & scalability" release:

suckit: mysqlwater.pngAz 5.4-es kiadás a MySQL azon problémáját igyekszik valamelyest kiküszöbölni, amely elsősorban a -milyen ironikus- a Sun CMT-s szerverein jelentkezik: sok szálnál elég gyatrán teljesít. Az 5.4-es release tulajdonképpen egy nem várt kiadás, hiszen korábban a 6.0 volt napirenden, de nyilván ki kellett valamit tolni az ajtón, ha már egy milliárd elment az akvizícióra...
Az 5.4 egyelőre béta állapotban van, a tapasztalatok szerint azért túl sok probléma az 5.1-hez képest nincs vele.

A másik gyanús versenyző a 6.0, amely tulajdonképpen már meg is szűnt, ilyen formában ugyanis sosem lesz kiadva. Ez a kiadás számos újdonságot hozott volna (falcon, maria storage engine), csak időközben sok minden megváltozott...

Ugyanúgy a read only sysbench OLTP teszttel kezdünk, 1 millió soron, 24 processzoros, 128 GiB memóriás 8086-klónunkon. A használt backend az InnoDB.

suckit: mysql-history.png

A grafikon igen látványos. Értelemszerűen a leggyegébb eredményeket a 4.1-es verziótól kapjuk, amely 64 szálon valamiért nagyon rosszul érzi magát, viszont utána még az 5.0-ás fölé is gyorsulja magát. A többire nem is nagyon vesztegetném a szót, hiszen az 5.4-es mindenkit kenterbe ver. Bár a maximumát 16 szálnál éri el, és utána már csak komoly veszteségek árán képes a klienseket kiszolgálni, viszonylag szépen tartja magát 128 szálig, ahonnan kisebb csökkenés után durva esés következik. Hiába van brutálisan sok, brutálisan erős CPU-nk, ha 1024 kliens rángatja a MySQL szerverünket, pont ugyanannyi teljesítményt kapunk, mint ha egy CPU-nk lenne (egy klienssel).

Nézzük táblában:

MySQL RO OLTP performance
  Peak TPS Peak performance at # of clients
4.1.25 3959 16
5.0.85 4423 14
5.1.38 4504 16
5.4.1 4795 16
6.0.11 4566 16


Érdekes módon szinte mindegyik MySQL verzió 16 szálnál érte el a csúcsteljesítményét, a legnagyobb, és a legkisebb között az eltérés 21 százalék, ennyit sikerült gyorsulnia a MySQL-nek a 4.1-ről az 5.4-re. Látszik, hogy az 5.4-be belepakolt változások hiányoznak a 6.0-ból, amely körülbelül az elődje (az 5.1) teljesítményét hozza.

Nézzük a read write tesztet is!

suckit: mysql-history-rw.png

Az 5.4 itt is szépen teljesít, bár a görbe vége gyorsabban konyul lefelé, de ez bőven betudható a FreeBSD gyengeségének is (mint ahogy természetesen minden más része is grafikonnak, a PostgreSQL-es tesztekből mindenesetre az látszik, hogy a FreeBSD többre is képes lenne).

A 4.1-es ugyanazt a furcsa mintát produkálja, csak nagyobb lyukkal, és sok szálon némiképp érthetetlen emelkedéssel.

A PostgreSQL-hez képest a MySQL becsületére válik, hogy bár a read only teljesítménye töredéke a Postgresének, a RO és RW tesztek közötti eltérés viszont sokkal kisebb:

Difference between RO and RW TPS
 RO/RW performance quotinent
MySQL1.21x
PostgreSQL5x


Azt hiszem kimondható tehát, hogy a jellemzően olvasásintenzív feladatokra a PostgreSQL jelenleg a (sokkal) jobb választás, míg a MySQL akkor lehet jó, ha változik is az adatbázis (némi tuninggal valószínűleg a PostgreSQL is feljebb hozható).

Táblázatos forma:

MySQL RW OLTP performance
  Peak TPS Peak performance at # of clients
4.1.25 2124 10
5.0.85 2445 10
5.1.38 2604 12
5.4.1 3193 14
6.0.11 2659 14

 

A fentiekből egyet biztosan állíthatok: a vizsgált verziók között a teljesítmény (bár nem túl nagy mértékben, de) folyamatosan nőtt, így a MySQL-re sem mondható az, hogy az új funkciók bekerülése mindenképpen lassítaná az adatbázist.

A használt konfiguráció a következő volt:

[mysqld]
datadir = /mnt/mysql
port = 3306
socket = /tmp/mysql.sock
skip-locking
max-connections = 3500
set-variable = key_buffer=1600M
transaction_isolation = REPEATABLE-READ
innodb_data_file_path = ibdata1:100M:autoextend
innodb_buffer_pool_size = 64G
innodb_additional_mem_pool_size = 20M
innodb_log_file_size = 1G
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 2
innodb_lock_wait_timeout = 300
innodb_locks_unsafe_for_binlog = 1
innodb_max_dirty_pages_pct = 90
innodb_thread_concurrency = 0
[isamchk]
set-variable = key_buffer=12M

A válság egy nagy kamu

2009.09.30. 16:57

suckit: imfturo.png

Sokan mondják, hogy kamu ez az egész válság, mesterségesen felfújt lufi, ami kipukkant, meg az is, hogy kipukkant.

Erre mit olvashat a kisember? 4000 milliárd helyett csak 3400 dollár a globális bankszektor várható vesztesége! Ilyenkor sokan előveszik a számológépet, kiszámolják a magyar államadósság rájuk eső részét, és elcsodálkoznak, hogy a bankok csak a negyedét bukták annak, amivel mi tartozunk nekik.

Jól szemlélteti a pénzintézetek helyezkedőképességét az is, hogy kicsivel lejjebb olvasható, hogy Csányi beeszi magát az alapvető élelmiszerek piacába, hiszen lassan nem csak előrecsomagolt ipari hulladék hústerméket, hanem túrórudit sem tudunk mástól venni!

Mi lesz itt...

:)

PostgreSQL történelem

2009.09.29. 09:00

You can read this article in english!

Nem, nem az a történelem, amely arról szól, hogy miként lett Ingresből PostgreSQL, hanem az, amely elmondja mennyivel lett gyorsabb a lassabb nyílt forrású adatbáziskezelőként ismert RDBMS.

A PostgreSQL-t nem kell bemutatni, hiszen az a két tábor, amely már találkozott vele, szentül, és megváltoztathatlanul meg van győződve a saját igazáról. Az egyik szerint a PostgreSQL lassú, és a MySQL-ben már úgyis vannak tárolt eljárások (bár használni még sosem használta), így az mindent tud, amit a PostgreSQL. A másik szerint a MySQL buta, és ahogy egyre-másra kerülnek bele az újabb funkciók, úgy lassul. Persze a PostgreSQL is egyre funkciógazdagabb lesz, így ezen elmélet szerint annak is egyre lassabbnak kell lennie.

Ennek próbálok meg utánajárni azzal, hogy végigpróbálom az öt utolsó kiadást mindkét szerverből, és változatlan hardver- és szoftverkörnyezetben megmérem a teljesítményüket.

A változatlan hardver- és szoftverkörnyezet esetünkben egy 24 magos (2,4 GHz-es, hat magos Intel E7450 CPU-k, 3x3 MiB L2 és 12 MiB L3 cache-sel), 128 GiB RAM-mal ellátott pécé szervert és a rajta futó FreeBSD 8/amd64 operációs rendszert jelenti.

suckit: 7356 large intel dunnington.png

A "Dunnington" kódnevű CPU felépítése és a CPU-k száma fontos tényező mind az OS-nek, mind pedig az adatbázisnak, hiszen ennél a processzornál rengeteg mag osztozik a szűkös FSB-n, amelyen keresztül a lassú memóriát, és a még lassabb perifériákat kell, hogy elérje. A több szintű cache-hierarchia és a lassú FSB-kapcsolat miatt különösen fontos szerepet kap az ütemező, és a memória-allokátor, amelyek a jó kiterheltség érdekében úgy kell balanszírozzanak az adatokkal, hogy azok minél nagyobb részét a cache-ekből tudja elérni az adott mag.

Ez komoly feladat, és a FreeBSD még messze nincs az út végén (sőt, amit azt illeti, épp csak rálépett), de itt alapvetően az volt a kérdés, hogy az adatbázis milyen utat járt be az egyes verziók között, nem pedig az, hogy az adott platformból az adott adatbázissal mekkora teljesítmény hozható ki. Utóbbi azt is magyarázza, hogy az adatbázis(ok)nál és az OS-nél minimális tuning volt csak, hiszen erre sajnos sem idő, sem erőforrás nem állt rendelkezésre.

A FreeBSD-re egyébként -azon kívül, hogy szeretem- azért esett a választás, mert a portjaiból könnyen elérhetők a PostgreSQL (és MySQL) korábbi verziói(-nak legfrissebb kiadásai). A tesztet magát a sysbench 0.4.12-es verziójával, annak is az OLTP tesztjével végeztük, 1 millió sorral, amely természetesen belefért a gép memóriájába. Az adatok két darab 15kRPM-es SAS diszken (RAID1-ben) voltak, amely azért messze van egy komolyabb adatbázis storage hátterétől, viszont kb. tipikusnak mondható egy egyszerűbb, webszerveres környezetben, ahol a gépekben lévő belső diszkekkel kell főzni.

A tesztek minden esetben egy percig futottak, ötször egymás után, és az ezen futások során keletkezett eredmények 95%-os konfidencia szint melletti értéke szerepel.

Nézzük:

suckit: postgresql-history.png

A grafikon jobb oldalán lévő színkód-magyarázatról látszik, hogy a tesztelt PostgreSQL verziók a következők voltak: 8.0.21, 8.1.17, 8.2.13, 8.3.7 és 8.4.1.

A teszteknél a sysbench localhoston, UNIX socketen érte el a szervert, azaz ugyanazon a gépen futott, mint maga az adatbázis. Fontos lehet még, hogy a sysbench RDBMS-kliens libraryja megegyezett a szerverével, azaz például a 8.1.17-es szervert a 8.1.17-es libpq-val hajtottuk.

A fenti grafikon a sysbench OLTP tesztjének read only verziójával készült eredményeket mutatja. Egy példa a futásra (ez mondjuk pont a read-write teszt):

/usr/local/bin/sysbench --test=oltp --db-driver=pgsql --pgsql-host=/tmp --oltp-read-only=off --oltp-test-mode=complex --oltp-table-size=1000000 --num-threads=2 --max-time=60 --max-requests=0 run

Ha megnézzük a grafikont, jól látható, hogy a PostgreSQL nem lassul, hanem épp ellenkezőleg: gyorsul.

Érdekes lehet áttekinteni a kiadások megjelenési dátumait:

PostgreSQL versions
branch/version/release date First release Tested release
8.0 2005-01-19 2009-03-16
8.1 2005-11-08 2009-03-16
8.2 2006-12-05 2009-03-16
8.3 2008-02-04 2009-03-16
8.4 2009-07-01 2009-09-09


Az egyes kiadások közti változások pontos és részletes listáját a "Release Notes" tartalmazza, amelynél kevésbé részletesen, de sokkal átláthatóbban magyarázza el az egyes verziók által behozott újdonságokat a "Feature Matrix".

Mint az látható, a 8.0-ás PostgreSQL bár jól kezd egy szálon, már két szálnál elkezd leszakadni, négynél után pedig nem hogy nőne a teljesítmény, hanem erőteljesen csökken. Gyakorlatilag az adatbázis képtelen két magnál (CPU-nál) tovább skálázódni, nagyobb kliensszámnál pedig szinte értékelhetetlen teljesítményt nyújt.

A 8.1-es PostgreSQL már sokkal szebben szerepel, a letörés négy szál helyett 14-nél jön el, ahonnan 32 szálig erősen zuhan, viszont utána már többé-kevésbé tartja magát 1024 szálig.

A 8.2-es verzió újabb előrelépést jelent, hiszen ennek a csúcsteljesítménye már 18 magnál van, ahonnan sajnos ez is ugyanúgy megkezdi a zuhanását, mint a korábbi verziók (a 64 szál feletti mérési eredmények sajnos hiányoznak).

Masszív előrelépést jelent a 8.3-as, amely majdnem a gépben lévő CPU-k számáig (24) tolja a maximális teljesítményt jelző 14000 TPS értéket, azaz 22 szálon teljesít a legjobban. A korábbi verziókhoz képest rendkívül pozitív üzenet, hogy mind az abszolút teljesítmény, mind pedig a teljesítménycsúcs kitolódott.

Sajnos a 8.4-es ehhez képest némi visszalépést jelent, egyedül a 256 feletti kliensszámnál tudott nagyobb teljesítményt leadni, mint az elődje, máshol pedig némileg elmarad attól.

A fenti adatok a jobb áttekinthetőség érdekében táblázatos formában:

PostgreSQL RO OLTP performance
  Peak TPS Peak performance at # of clients
8.0.21 1256 4
8.1.17 5620 14
8.2.13 8109 18
8.3.7 13984 22
8.4.1 13546 22


A PostgreSQL bebizonyította tehát, hogy olvasni nagyon tud, nézzük mi a helyzet, ha írni is akarunk!

A sysbench RW tesztjének eredménye:

suckit: postgresql-history-rw.png

Természetesen a read only teszthez képest jóval alacsonyabb számokkal találkozhatunk, hiszen itt már a diszkeket is mozgatni kellett. Az arányok viszont hasonlóak, ami mindenképpen jó hír, hiszen látható, hogy a PostgreSQL az elmúlt öt verzió alatt (a 8.4 kivételével) folyamatosan gyorsult, a 8.3-mal pedig szinte hihetetlen, több mint 100%-os teljesítménynövekedést ért el!

Lássuk ugyanezt táblázatban:

PostgreSQL RW OLTP performance
  Peak TPS Peak performance at # of clients
8.0.21 361 2
8.1.17 873 10
8.2.13 1358 14
8.3.7 2795 18
8.4.1 2713 12


Itt a kép már vegyesebb, hiszen a 8.3-as verzió csúcssebessége távolabb került az optimális 24 klienses értéktől, ráadásul a 8.4-es nem csak csúcssebességben, hanem a csúcs balra tolódásában is romlott, viszont a mindössze 3%-os teljesítménycsökkenést hat CPU-val "odébb" tudta produkálni, ami a későbbiekben akár azt is jelentheti, hogy abszolút teljesítményben is megverheti majd a korábbi verziót.

Összefoglalásként azt hiszem elmondható, hogy ha a PostgreSQL-t lassúnak ismertük (vagy tapasztaltuk) a múltban, ideje lehet újragondolni (vagy -mérni), hiszen az elmúlt három évben óriásit javult a sebessége és a skálázhatósága. Az általa nyújtott szolgáltatásokról már nem is beszélve.

Hamarosan jön a MySQL történelem is!

Update: postgresql.conf

datestyle = 'iso, mdy'
default_text_search_config = 'pg_catalog.english'
lc_messages = 'C'                       # locale for system error message
lc_monetary = 'C'                       # locale for monetary formatting
lc_numeric = 'C'                        # locale for number formatting
lc_time = 'C'                           # locale for time formatting
listen_addresses = ''           # what IP address(es) to listen on;
log_destination = 'syslog'
maintenance_work_mem = 64MB
max_connections = 1064                  # (change requires restart)
shared_buffers = 1024MB
silent_mode = on
unix_socket_directory = '/tmp'          # (change requires restart)
unix_socket_group = 'pgsql'                     # (change requires restart)
unix_socket_permissions = 0777          # begin with 0 to use octal notation
update_process_title = off
work_mem = 16MB

Szaros a gatya

2009.09.25. 12:52

Úgy látszik a HWSW-nél azért még próbálják tartani a színvonalat, de néha az RSS lebuktatja őket. :)

suckit: szar.pngsuckit: gatya.png

Fujitsu attacks

2009.09.25. 11:39

A HUP-on rendszeresen kattogtatok a hirdetésekre, mivel úgy érzem trey sokat dolgozik az oldallal, így megérdemli a bevételt.

Most sem tettem másként (egy olyan hirdetéssel, amely a szövege alapján egyébként érdekelt is), így rákattintottam a google adsense dobozban lévő szövegre.

A hirdetés (az URL alapján) a Fujitsu-tól származik, akik úgy látszik olyan komoly reklámhadjárattal támadták le az internetet, hogy azt már a google (bár lehet, hogy ezt nem is ők adják) sem nézhette:

suckit: fujitsu-attacks.png

 

Ahogy az sejthető volt, megjelent a libdispatch, a Mac OS X Snow Leopardban bemutatkozott Grand Central Dispatch API-jának userspace implementációja a FreeBSD-ben, egyelőre(?) egy portként.

Az Apple nemrég tette nyílt forrásúvá a projektet, amely az amúgy is az LLVM felé tendáló FreeBSD-ben igazán hasznos kiegészítő lehet majd valamikor...

Gondoltam rákukkantok hol tart a MySQL "vérző él" verzió, a sólymos-máriás adatbázis-backendekkel. Először semmi furcsa sem történt, letöltöttem, telepítettem, elkezdtem olvasgatni a manualt, minden jónak tűnt (leszámítva a teljesítményt, de hát ez MySQL, mit vár tőle az ember ;).

Aztán egyszer csak furcsa dolgok történtek, a dev.mysql.com-on lévő leírásban némely linkre kattintva egy keresőoldal fogadott. Ha visszamentem az előző oldalra, majd újból rákattintottam, megjelent az, amit kerestem. Azt gondoltam csak valami adatbázishiba (LOL).
Tegnap ismét meg szerettem volna valamit nézni a doksiban, amit szokás szerint a dev.mysql.com->documentations, és ott a 6.0 manual kiválasztásával értem el, de már csak a hűlt helye fogadott:

Note: The MySQL 6.0 Reference Manual has been retired. MySQL 6.0 was not developed beyond Alpha status and new releases have not been made for some time, so the manual has been withdrawn as well.

OK, hogy ott van az 5.4, de az mégis csak egy teljesítménytuningolt (jaj, megint egy mondatban említettem a MySQL-t és a teljesítményt, le kellene szoknom róla!) verzió, kb. nulla extra feature-rel (nem, nem úgy, mint a Snow Leopard), de a 6.0 mégiscsak egy rakás^W^Wsok^Wnéhány újdonságot ígért 2008 Q4-re.

Például a falcont, amely a BDB és az InnoDB "elvesztése" után az Oracle-től való függőséget szüntette volna meg, na meg persze "lightning fast, large memory, multi-cpu aware", mert hát mint tudjuk, az InnoDB-nek azért vannak bajai a Sun-féle megközelítéssel (ordenáré lassú magok, de azokból viszonylag sok, megfejelve a hardveres threadekkel). Az meg mégis hogy néz ki, hogy a Sun adatbázisa az adatbázisra oly jónak mondott hardveren lassabban fut, mint egy iphone-on.

Vagy a mariát, amely(nek írója, Monty Widenius) hasonló célokat tűzött ki maga elé, például az InnoDB leváltását, aztán az InnoDB stabilabbnak bizonyult, Monty rosszabbul skálázódott, és dobbantott a napos oldalról. Most persze a szabad szoftverek élharcosaként osztja az észt a MySQL-ért fizetőknek a kispadról:

The basic idea for our dual-licensing was this: if you bought a license then we waived the GPL restriction that you have to redistribute your code as GPL. You could change, modify, extend, distribute, and redistribute the copy in any way you wanted (but of course not change the license of the MySQL code).[...]

I was recently made aware that the above is no longer the case with the standard MySQL OEM agreement. Sun is now, by default, putting the following limitations on their licensees:

  • You cannot modify MySQL in any way (for example to fix bugs, optimise MySQL for your applications, include publicly available enhancements (such as the BSD licensed "Google patch" or compile it with another storage engine) to improve your MySQL as part of your product.
  • You cannot use any forks of MySQL (such as Drizzle, ExtSQL or MariaDB).
  • You are tied in to the current major release of MySQL enterprise (i.e. you have to pay for upgrades). This may be normal in a closed source environment, but not normal when it comes to Open Source.
  • There are serious limitations for what kind of applications you can build with the MySQL code, for instance, the default agreement prohibits installations in hosting facilities or to use your version as a SQL server.
  • The end user can't transfer/sell the license to someone else (to be used under the same conditions).

[...]

With above limitations in place, you should consider if it's worth it to you to buy licenses for MySQL under the current terms.

Alakul az élet, szerencsére annak, aki gyors, megbízható, sokat tudó nyílt forrású adatbázist szeretne nem sokat kell törődnie a MySQL-lel. >;-)

ui: ha valakinek mégis szüksége lenne a doksira, a facebook.netről még elérhető online.

ZsebBSD

2009.09.18. 12:22

Egy elég hosszú cikk jelent meg a napokban az InformIT-on, amelyben az OpenBSD ARM portjáról beszélgetnek.

Néhol kicsit bilibelógós...

Suck IT

2009.09.17. 19:27

A következő cikket csak akkor nézd meg, ha elmúltál 18 éves!

Ott lesz vajon Lőrinc?

2009.09.15. 20:34

suckit: larryellison-hdA Munkás István személyi kultusz után érik a következő nagyágyú az IT iparban. Eloson Lőrinc eddig csak a háttérben szívta laposra az "adatbázist csak profi vendortól" típusú cégek pénztárcáját, amelyek minden évben kemény matekozással próbálják követni, hogy az Oracle szerint most egy mag hány mag az adott platformon.

De most itt van, a Sun-szimpatizánsok, szándékosan, vagy véletlenül beragadt ügyfelek, no és persze a mezei ott dolgozók körömrágva várják, hogy "ez egy előfizetéses cég" Lőrinc megmondja a tutit, és kirángassa a céget a szarból.

Most éppen a titokzatos "Oracle Database Machine" a sláger, amelyet ma este jelent be Lőrincünk. Flash, OLTP, meg minden, a promókban meg az Oracle Exadata dobozok mindenütt, amelyek ugyebár jelenleg HP dolgokra épülnek.

Biztos izgi lesz, de addig is van bő egy óránk, hogy kitaláljuk mi lesz a szeretett/utált SPARC/Solaris/MySQL/javabizbasz technológiánkkal, amelynek kinyírására/megtartására minden oka meglenne Lerinek.
Egyébként szerintem a kérdés -hosszú távon legalábbis- egyszerű:

suckit: larrycrash

suckit: jonathan schwartz photo copyright yeshim denizAz elmúlt napokban pjd (Pawel Jakub Dawidek, a ZFS-t FreeBSD-re portoló fejlesztő) egy rakás PR-t feldolgozott, és javított, majd ma, egy masszív commit keretében MFC-zte (Merge From Current) a 8-as ágba.

A módosítás kompatibilitási, megbízhatósági és teljesítménybeli javulásokat hoz, némi funkcionális változással (pld. a snapshotok ezentúl nem jelennek meg alapból a df és a mount kimenetében).

Ezt követően pedig megszületett az a commit, amit már sokan vártak:

Author: pjd
Date: Tue Sep 15 11:34:53 2009
New Revision: 197218
URL: http://svn.freebsd.org/changeset/base/197218

Log:
  We believe ZFS is ready for production use. Remove a warning about it being
  experimental. :)

Modified:
  head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c

Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
==============================================================================
--- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c	Tue Sep 15 11:23:59 2009	(r197217)
+++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c	Tue Sep 15 11:34:53 2009	(r197218)
@@ -3072,8 +3072,6 @@ zfs_modevent(module_t mod, int type, voi
 	switch (type) {
 	case MOD_LOAD:
 		zfs_root_token = root_mount_hold("ZFS");
-		printf("WARNING: ZFS is considered to be an experimental "
-		    "feature in FreeBSD.\n");
 
 		mutex_init(&zfs_share_lock, NULL, MUTEX_DEFAULT, NULL);

Azaz Pawel szerint a ZFS már ivarérett FreeBSD-n, és képes arra, hogy odab.sszon. :)

Remélem addig a rövid ideig, amíg nem jön valami jobb fájlrendszer ez valóban így lesz, és marad is.

ui: azért én drukkolok az innovatív elméknek, lehet ennél a ZFS-nél jobbat csinálni...

Amikor egyesek azon rágódva forgolódnak álmatlanul éjszaka, hogy szeptember kilencedikén ott lesz-e István egy rendezvényen, vagy sem, akaratlanul is azon kezdek el gondolkozni, hogy miként lett ezeknek az embereknek vallásuk az István.

Kezdjük az elején.

A történet KapØrszakállú (aka. 1st3n) barátunknál kezdődik, aki egy hét kényszerszabadságán végtelen() unalmában kedvenc hobbijának hódol... Populoust játszik...

suckit: adameve

  1. Kezdetben teremté 1st3n az eget és a lakótelepet.
  2. A lakótelep pedig kietlen és puszta vala, és setétség vala a mélység színén, és az 1st3n Lelke lebeg vala a vizek felett.
  3. És monda 1st3n: Legyen világosság: és lőn világosság, harminckétezer lesz számla nélkül, monda a Szerelő.
  4. És látá 1st3n, hogy jó a világosság; és lassan, nehezen, elválasztá 1st3n a világosságot a setétségtől.
  5. És nevezé 1st3n a világosságot nappalnak, és a setétséget nevezé éjszakának: és lőn este és lőn reggel, és lőn este és lőn reggel, és lőn este és lőn reggel, első nap. És akkor monda 1st3n: le kellene jönnöm az anyagról végre.
  6. És monda 1st3n: Legyen mennyezet a víz között, a mely elválaszsza a tizedikről lezúduló vizeket a negyedikről lezúduló vizektől.
  7. Teremté tehát 1st3n a mennyezetet, és elválasztá a mennyezet alatt való vizeket, a mennyezet felett való vizektől. És úgy lőn, két és fél négyzetméteres fürdőszobák lőn.
  8. És nevezé 1st3n a mennyezetet vasbeton födémnek: és lőn este, és lőn reggel, és lőn este, és lőn reggel, és lőn este, és lőn reggel, és lőn este, és lőn reggel, második nap. Egyre durvább az anyag, ráadásul el is fogyá.
  9. És monda 1st3n: Gyűljenek egybe az ég alatt való vizek egy helyre, hogy tessék meg a száraz. És úgy lőn.
  10. És nevezé 1st3n a szárazat földnek; az egybegyűlt vizeket pedig vécének nevezé. És látá 1st3n, hogy a hányásban mindig van borsó, vagy sárgarépa.
  11. Azután monda 1st3n: Hajtson a föld gyenge fűvet, maghozó fűvet, gyümölcstermő szófát, a mely gyümölcsöt hozzon az rajta paráználkodók neme szerint, a melyben legyen néki magva e földön. És úgy lőn, a szőnyegpadló maghozó füvétől kialakuló tünetegyüttest pedig elnevezé allergiának.
  12. Hajta tehát a föld gyenge fűvet, maghozó fűvet az ő neme szerint, és gyümölcstermő szófát, a melynek gyümölcsében mag van az ő neme szerint. És látá 1st3n, hogy jó.
  13. És lőn este és lőn reggel, harmadik nap. Nehéz volt az kelés, de az APEH miatt muszáj volt.
  14. És délután, az APEH után monda 1st3n: Legyenek világító testek az ég mennyezetén, hogy elválaszszák a nappalt az éjszakától, és legyenek jelek, és meghatározói ünnepeknek, napoknak és esztendőknek, hogy kitaláltathassék a négy-napos-máskor-ledolgozós-hétvége.
  15. És legyenek világítókul az ég mennyezetén hogy világítsanak a földre. És úgy lőn.
  16. Teremté tehát 1st3n a két nagy világító testet: a nagyobbik világító testet, hogy uralkodjék nappal az ablaktalan panelben és a kisebbik világító testet, hogy uralkodjék éjjel; és a csillagokat, akik képivel ki lehet tapétázni a hálószobát.
  17. És helyezteté 1st3n azokat az ég mennyezetére, hogy világítsanak a földre;
  18. És hogy uralkodjanak a nappalon és az éjszakán, és elválaszszák a világosságot a setétségtől. És látá 1st3n, hogy jó.
  19. És lőn este és lőn reggel, negyedik nap, mintha kezdene elmúlni az anyag hatása.
  20. És monda 1st3n: Pezsdűljenek a vizek élő állatok nyüzsgésétől; és madarak repdessenek a föld felett, az ég mennyezetének színén.
  21. És teremté 1st3n a nagy vízi állatokat, és mindazokat a csúszó-mászó állatokat, a melyek nyüzsögnek a vizekben az ő nemök szerint, és mindenféle szárnyas repdesőt az ő neme szerint. És látá 1st3n, hogy jó, de azért a Domestost és a Chemotoxot is megteremté.
  22. És megáldá azokat 1st3n, mondván: Szaporodjatok, és sokasodjatok, és töltsétek be a tenger vizeit; a madár is sokasodjék a földön, de szigorúan csak kalitkában, lakógyűlési bejelentési kötelezettség terhe mellett.
  23. És lőn este és nagysokára lőn reggel, ötödik nap, kezd hiányozni az anyag.
  24. Azután monda az 1st3n: Hozzon a föld élő állatokat nemök szerint: barmokat, csúszó-mászó állatokat és szárazföldi vadakat nemök szerint. És úgy lőn, beköltözék Kovácsék, Hajdúék és Szabóék a szomszédba.
  25. Teremté tehát 1st3n a szárazföldi vadakat nemök szerint, a barmokat nemök szerint, és a földön csúszó-mászó mindenféle állatokat nemök szerint. És látá 1st3n, hogy jól kibaszott a társasházzal.
  26. És monda 1st3n: Teremtsünk számító gépet a mi képünkre és hasonlatosságunkra; és uralkodjék a tenger gondjain, az égő kínjain, a barmokon, mind az egész földön, és a földön csúszó-mászó mindenféle állatokon.
  27. Teremté tehát az 1st3n az számító gépet az ő képére, 1st3n képére teremté őt: P. PC MacAdamsnek és PC-nének (EVA) teremté őket, és személyi számító gépnek nevezé őket.
  28. És megáldá 1st3n őket, és monda nékik 1st3n: Szaporodjatok és sokasodjatok, és töltsétek be a földet és hajtsátok birodalmatok alá; és uralkodjatok a tenger halain, az ég madarain, és a földön csúszó-mászó mindenféle állatokon.
  29. És monda 1st3n: Ímé néktek adok minden maghozó fűvet az egész föld színén, és minden fát, a melyen maghozó gyümölcs van; az legyen néktek eledelül.
  30. A föld minden vadainak pedig, és az ég minden madarainak, és a földön csúszó-mászó mindenféle állatoknak, a melyekben élő lélek van, a zöld fűveket adom eledelűl. És úgy lőn.
  31. És látá 1st3n, hogy minden a mit teremtett vala, ímé igen jó. És lőn este és lőn reggel, hatodik nap. A zöld fűvek már nagyon hiányoznak.

Ennyit az őstörténetről. De nézzük tovább.

suckit: imapcimamacP. PC MacAdams (eredetileg Manfred "68" Károly, de később nemet és nevet váltott) és felesége, leánykori nevén IBM EVA (Ilona Boldog Mária Eszméletlenül Vacak Architektúra) három gyereket nemzett, C=aint, Apelt és PeeSeeth-t. C=ain és Apel az apjuk eszét örökölte, míg PeeSeeth inkább az anyjára hasonlított.

Akkoriban emiatt a különbözőség miatt jól össze is vesztek, és elváltak útjaik.
suckit: xerox-starApel messzire vándorolt, és sokáig megőrizte karakteres mivoltát. Ezen a téren nagyobb változás csak akkor történt, amikor Hunorral, Macorral és Istvánnal ráakadtak a csodaszarvasra a Xerox parciális sztyeppéin.
Bár a csodaszarvas elszaladt, István, a betegeskedő Apel fia rögtön meglátta a lehetőséget a szarvas-GUI-no-ban, és rögtön elkezdett dolgozni Apel Lizán (eltökélt szándéka volt így nevezni majdani leányát).

Sajnos már csak Liza születése után derült ki, hogy "anyut" Istvánon kívül más is "macin toszta" (gyk: kan dalló elé terített medvebőrön fekvő nőn aktust gyakorolni) -valami félvér skót, egyébként (minő irónia) anyja után Mac Intosh nevű-, aki egyébként Apel titkos kedvenc zabigyereke.

A lehetetlen történések miatt István és Apel kapcsolata megromlott, így István ismereXTlen helyre távozott. Apel a "System 7" rendszer bevezetésével a hét vezérnek adta az irányítást, akik számtalan klón létrehozásával gyengítették Apel birodalmát (István nagyapja egyébként körülbelül ekkor váltott nevet).

Mikor ez István tudomására jutott, azonnal visszatért, és miután újból bedolgozta magát apja birodalmába, elkergette a klónokat, eltörölte a "System 7" rendszert, és meghirdette a "MegszOxS 8" rendszert. A honfoglalás utáni Istvánt hívják hívei Szent Istvánnak, már azért, amit az Apel birodalommal tett.

suckit: c2581sf503Szent István életének egyik legvitatottabb eseménye az volt, amikor szakított a P. PC MacAdams (nagyapai) nézeteivel, és áttért anyja sokkal együgyűbb világnézetére. Egyesek szerint az időskori szenilitás válthatta ki ezt a radikális elbutulást, mások szerint pedig nagyanyja ajánlott neki olyan pénzeket, amelyek miatt István elszánta magát erre a lépésre.

suckit: caption1002 0István élete ezután tulajdonképpen unalmas. Leginkább farmer és fekete garbó. Nameg a pletykák, melyek szerint István néha úgy érzi, hogy nem ő forog a Nap körül, hanem fordítva.
A hozzá hasonló vállalatvezérekről általában a "hard worker" imidzset terjesztik: korán reggel bent van, még kávé előtt leordítja mindenkinek a fejét, majd este nyolckor, mikor már rohadtul mennél a gyerekért, körbeszaglászik még kicsit a cubicle-ök körül, és akit bent talál, annak leüvölti a haját. Akit meg nem, annak holnap reggel.

Ezt nem tudom, mindenesetre az Apple erősebb, mint valaha. Most is 2,7%-os pluszban áll a tőzsdén, biztos odaát is olvassák a cikkem. :)

ui: de vajon ott lesz kilencedikén?

Don't be evil

2009.09.03. 18:06

Nahát, a Google szabadalmaztatta a kezdőlapját.

Don't be evil, eh?

suckit: 500x 500x PreviewScreenSnapz006

Brabusban meghalni

2009.09.01. 09:40

730 lóerő, 366 km/h. Ez a Brabus Rocket (Brabus CLS V12 S), amelyben büszkén, anyagi felsőbbrendűségedet hangoztatva dögölhetsz meg, mindezt úgy, hogy egészen biztosan lesz olyan, aki még a véres cafataidat látva is irigyelni fog.

Jó, meghaltál, de mi vigye egykor szebb napokat megért, de mostanra szénné csoffadt testedet a látványos, sokmilliós kriptába? Nem ciki Brabusban meghalni, és aztán valami szar tragacsban megtenni utolsó földi kilométeredet?

Na ezt a rétegigényt elégítheti ki az alábbi tuningautó, nevezzük Brabus FunCarnak (nem mert vicces, hanem mert funeral):

suckit: funcar

A Brabus FunCar rendelkezik mindennel, amire vágysz: áramvonalas, egyedi, kurva gyorsan tud beleborítani a sírodba, és külön a te óriási arcodra méretezve meghosszabbított csomagtérrel rendelkezik (amelyben ezúttal te leszel a csomag). Egyik volt csajod sem mondhatja majd, hogy neked kicsi volt...

ui: a képért köszönet névtelenségbe burkolózó olvasónknak

süti beállítások módosítása