Podczas surfowania po Gronie, Twoje żądanie dotyczące strony grona (request) trafia do jednego z naszych serwerów. Następnie serwer przypisuje obsługę Twojego requesta jednemu z wielu procesów Django. Pojedynczy proces generuje stronę Grona, ale może obsługiwać tylko jedno żądanie na raz. Linuxowcy mogą znaleźć podobieństwo w tym modelu z modelem “prefork” z konfiguracji Apache. Po wygenerowaniu strony proces jest znów dostępny i czeka na kolejne kliknięcia użytkowników.

Wynika z tego, że na pojedynczym serwerze możemy obsłużyć na raz tylko tyle żądań, ile mamy uruchomionych procesów Django¹. Niestety, pojedynczy proces zużywa dość dużo pamięci. Aby móc obsługiwać jak najwięcej użytkowników na raz, wypadałoby mieć możliwie dużo uruchomionych procesów. Jednak ich ilość jest limitowana wielkością pamięci operacyjnej.

Aby zwiększyć wydajność (czyli ilość stron które możemy wygenerować), staramy się w miarę możliwości zmniejszać wielkość pojedynczego procesu. W tym celu możemy zmniejszać ilość linii kodu lub optymalizować zużycie pamięci operacyjnej przez proces. Niestety oba zadania są bardzo trudne.

Ostatnio wpadliśmy na inny pomysł.

Nasze serwery używają 64 bitowej wersji linuxa. Administratorzy zdecydowali się na to już dawno temu. Głównym argumentem było to, że zamierzaliśmy używać większej ilości RAMu niż 4GB, oraz lepsza wydajność tej architektury.

Padł pomysł, żeby sprawdzić ile RAMu zaoszczędzimy przenosząc się na “stare” 32 bity. W sumie to w Pythonie całkiem sporo pamięci zajętej jest przez wskaźniki, a właśnie zmniejszenie jej dałoby największy zysk.

Efekt okazał się dużo lepszy niż przewidywaliśmy. W pełni załadowany proces Django na 32 bitach zajmuje około 60MB, czyli o 30% mniej niż na 64 bitach, gdzie jest to 95MB.

Oto przykład “topa” z maszyny 64 bitowej. Kolumna RES pokazuje orientacyjne zużycie pamięci przez proces:

VIRT  RES  SHR S %CPU   TIME+  COMMAND
212m  96m 3832 S    0  1:49.61 django '/gallery/3329236/0/'
203m  96m 3120 S    0  1:37.78 django '/gallery/4871149/6/0/'
211m  95m 3832 S    0  1:38.74 django '/mailbox/box/1/'
210m  95m 3824 S    0  1:45.45 django '/gallery/photo/40328359/'
210m  95m 3844 S    0  1:48.43 django '/users/index/'
210m  94m 3848 S    0  1:33.94 django '/users/'

A oto, dla porównania, analogiczny z maszyny 32 bitowej:

VIRT  RES  SHR S %CPU    TIME+  COMMAND
68396  62m 3484 S    0  2:06.94 django '/users/433317/'
67716  61m 3488 S    0  1:50.23 django '/gallery/photo/42009962/'
66264  60m 3488 S    0  2:01.94 django '/pub/join/'
65312  59m 3484 S    0  2:08.75 django '/users/'
65148  59m 3508 S    0  1:48.02 django '/users/1533943/friendlist/'
64884  59m 3508 S    0  1:51.48 django '/'

Podsumowując, możemy powiedzieć, że stosowane 64 bitów może nie być takie wspaniałe. Architektura x86_64 niewątpliwie ma wiele zalet, jednak w naszej sytuacji, gdzie ilość zajętego RAMu zaczyna mieć znaczenie, zaczynamy odczuwać jej wady.

Teoretycznie, po całkowitej migracji na 32 bity bylibyśmy w stanie obsługiwać o 1/3 więcej ruchu niż obecnie. Mamy więc o co walczyć.

¹ W praktyce nie jest to takie proste, bo mamy także inne ograniczenia, jak na przykład moc procesora.

W chwili obecnej całość działa już na PostgreSQLu, działa ładnie i szybko. Load maszyny z PostgreSQLem jest około 3 krotnie niższy niż load maszyny z MySQL’ em (przy tym samym obciążeniu).

Czym się maszyny różnią? tylko silnikiem bazy danych.

Obie są to dwuprocesorowe xeony 3ghz, z 16GB ramu i macierzą RAID10 z 6 dysków SCSI 72GB 15k rpm.

Wielkość bazy – około 60 gigabajtów w 150 milionach rekordów (i rośnie).

Średni “load” na tej maszynie wynosi ledwie 1.5.

Wychodzi na to, że da się zrobić by PostgreSQL był szybszy i nadal zachować pełną funkcjonalność.

Na wstępie warto przytoczyć parę faktów. Whois dla domeny grono.net:

[...]
Domain servers in listed order:
      DNS1.GRONO.NET
      DNS2.GRONO.NET

Odpytanie naszych serwerów dns o rekordy NS dla strefy grono.net

mieki@mieki-laptop:~$ host -t ns grono.net dns1.grono.net
Using domain server:
Name: dns1.grono.net
Address: 193.33.58.3#53
Aliases: 

grono.net name server dns1.grono.net.
grono.net name server dns2.grono.net.

oraz:

mieki@mieki-laptop:~$ host -t ns grono.net dns2.grono.net
Using domain server:
Name: dns2.grono.net
Address: 193.33.58.4#53
Aliases: 

grono.net name server dns2.grono.net.
grono.net name server dns1.grono.net.

Czyli jak widać, delegacja na nasze serwery jest zrobiona w sposób poprawny. Serwis grono.net posiada przyznaną przez RIPE klasę adresów 193.33.59.0/23. Jest to pula PI i rozgłaszamy ją z naszego routera (AS42782).

Jak wiadomo, powszechnym problemem w sieci internet jest wszędobylski spam. Wiadomości o treści reklamowej na przykład o powiększaniu pewnej części ciała. Najczęściej są rozsyłane z zainfekowanych wirusami (lub koniami trojańskimi) komputerów. Posiadacze zarażonego peceta nie są świadomi, że mogą rozsyłać kilkaset maili na sekundę. Odbiorcami spamu są maile użytkowników, zbierane do bazy przez spam-harvestery (czyli takie skrypty, monitorujące witryny webowe, grupy dyskusyjne i inne zasoby sieci w poszukiwaniu prawidłowych adresów email), a także pobierane są z książek adresowych popularnych programów pocztowych na zainfekowanych komputerach.

Protokół przesyłania poczty (SMTP) został zaprojektowany we wczesnych latach osiemdziesiątych XX wieku i praktycznie w niezmienionej formie pozostał do dziś. Ma on szereg błędów, których istnienie można było przewidzieć już na poziomie projektowania samego protokołu. Jednym z poważniejszych z nich jest możliwość podszywania się pod nadawcę. Do tego można użyć zwykłego programu telnet i udawać klienta pocztowego.

Poniżej zaprezentowałem próbę wysłania poczty z konta na nieistniejącej domenie:

mieki@mieki-laptop:~$ telnet mx.grono.net 25
Trying 193.33.58.136...
Connected to mx.grono.net.
Escape character is '^]'.
220 dakota.nemo.pl Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at  Thu, 4 Oct 2007 23:51:24 +0200 
ehlo jakasdomena.pl
250-dakota.nemo.pl Hello [82.210.166.16]
250-TURN
250-SIZE
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-TLS
250-STARTTLS
250-X-EXPS GSSAPI NTLM LOGIN
250-X-EXPS=LOGIN
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250-X-LINK2STATE
250-XEXCH50
250 OK
mail from: piotr@jakasdomena.pl
250 2.1.0 piotr@jakasdomena.pl....Sender OK
rcpt to: p.milczarek@grono.net
250 2.1.5 p.milczarek@grono.net 
data
354 Start mail input; end with <CRLF>.<CRLF>
From: Piotr Z JakiejsDomeny <piotr@jakasdomena.pl>
Subject: Przykładowa wiadomosc          

Tutaj tresc wiadomosci, czy to dojdzie ?

.
250 2.6.0 <DAKOTAogkJXrRjbDt3H000001ad@dakota.nemo.pl> Queued mail for delivery
quit
221 2.0.0 dakota.nemo.pl Service closing transmission channel
Connection closed by foreign host.

Dopiero po zajrzeniu w nagłówki możemy stwierdzić, że pole From jest sfałszowane.

Received: from jakasdomena.pl ([82.210.166.16]) by dakota.nemo.pl with Microsoft SMTPSVC(6.0.3790.3959);
         Thu, 4 Oct 2007 23:52:26 +0200

podczas gdy:

mieki@mieki-laptop:~$ host jakasdomena.pl
jakasdomena.pl has address 83.133.126.177
jakasdomena.pl mail is handled by 0 jakasdomena.pl.

Czyli host 82.210.166.16 nie jest ani wpisem IN A dla jakasdomena.pl, ani wpisem MX w tej domenie (wybór domeny był całkowicie przypadkowy).

Aby zapobiec procederom tego typu jak powyższy, w Kwietniu 2006 powstał dokument RFC opisujący jak definiować na serwerach dns rekordy dotyczących uprawnień wysyłania poczty.

Typ rekordu, w jakim definiujemy które serwery mogą rozsyłać pocztę z danej domeny, a które nie, to TXT. Przykładowy rekord dla przykładowej domeny grono.net :-)

mieki@mieki-laptop:~$ host -t txt grono.net
grono.net descriptive text "v=spf1 +ip4:193.33.58.0/23 -all" // o tym teraz
grono.net descriptive text "spf2.0/mfrom,pra +ip4:193.33.58.0/23 -all" // natomiast o tym troche później

Ten rekord oznacza deklaracje mechanizmu Sender Policy Framework dla domeny grono.net. Pierwszym elementem rekordu SPF jest deklaracja wersji czyli "v=spf1", następnie występuje lista elementów dla których ustalamy politykę rozsyłania poczty.

Każdy taki element składa się z kilku części. Część pierwsza – kwalifikator – jest to mały znaczek od którego zaczyna się element, wskazujący co zrobić z pocztą przychodzącą od danego elementu. Wszystkie poniższe elementy przedstawiłem w maksymalnym uproszczeniu:

• ”+” – whitelisting – czyli bezwarunkowe zaakceptowanie poczty i oznaczenie jej jako nie SPAM
• ”-” – blacklisting – oznaczenie poczty jako niechciana/niepożądana
• ”˜” – greylisting – w skrócie: zastosuj swoje mechanizmy filtrowania poczty i detekcji spamu

Istnieje jeszcze kwalifikator ”?”, który działa podobnie do ”˜”, ale nie będziemy się zagłębiać w szczegóły. Część druga – typ obiektu:

• “a” – rekord IN A w danej domenie np +a – oznacza deklaracje o wysyłaniu poczty z rekordu (bądź rekordów) IN A dla samej domeny
• “ip4” – oznacza zakres hostów przedstawiony w postaci CIDR, bądź jeden host bez maski podsieci np. -ip4:193.33.58.0/23
• “mx” – oznacza wpis lub wpisy mx w danej domenie, na przykład -mx oznacza deklaracje, że z serwerów pocztowych nie rozsyłamy poczty :>
• “all” – oznacza wszystkie inne niezdefiniowane w SPF

Część trzecia (opcjonalna) – wartość parametru: W przypadku domeny grono.net użyty tylko raz – chodzi o “193.33.58.0/23” – czyli klasę adresów IP którą posiada Grono.net

SPF przyjął się jako standard jeżeli chodzi o politykę rozsyłania poczty. Jednakże istnieje sobie firma na świecie o nazwie Microsoft, która stwierdziła, że stworzy swój własny mechanizm polityki walki z pocztą – SenderID. Do deklaracji tego mechanizmu służy właśnie drugi rekord TXT.

Niestety, portale o których wspomniałem na samym początku wykorzystują tę drugą technologię.(Nie wnikam już kto jest rzeczonych serwisów). SenderID nie wnosi tak naprawdę nic więcej do walki ze spamem niż SPF (nawet składnia jest identyczna jeżeli chodzi o deklaracje obiektów). Faktem jest, że wprowadza bardziej szczegółowe sprawdzanie nagłówków które pojawiają się w poczcie (From: i Return Ptah:), oraz tego co jest podawane po HELO/EHLO.

Niestety po mimo zastosowania się do rad potentata z Redmond, nie ma skutecznego sposobu na dostarczenie poczty do adresata, który ma konto przykładowo na serwisie hotmail.com.

Po długich i mozolnych testach udało nam się zaobserwować 2 zachowania serwisu:
1. Poczta ląduje w folderze Junk, z którego jest automagicznie wywalana po 10 dniach
2. Poczta wcale nie dociera do adresata.
W jednym i drugim przypadku serwer smtp hotmaila zwraca:

250 <BAY0-MC10-F5snIXriu0001e384@bay0-mc10-f5.bay0.hotmail.com> Queued mail for delivery

Jeżeli poczta wpadnie do folderu junk i sprytny użytkownik ją oznaczy, że spamem nie jest(kliknie w “znam nadawcę”), kolejna poczta od tego adresata (z tego samego serwera pocztowego), nie jest wrzucana do folderu “Junk” ... ale tylko przez ok. tydzień.

Po przewertowaniu zasobów Usenetu jestem w stanie wysnuć tezę, iż serwery stosujące technologię SenderID zachowują się zgoła niedeterministycznie, albo rządzi nimi jakaś mroczna logika rozmyta, do której zwykły śmiertelnik nie ma dostępu. Na domiar tego dodam, iż ta cudowna technologia jest opatentowana oraz jej nie można stosować bez zgody Microsoftu. Próby kontaktu z kimś ze strony MS są z góry skazane na niepowodzenie. Na maile odpowiadają automaty, albo nic nie odpowiada (w sumie nie dziwne, może im ktoś problem zgłaszał, że im nie działa poczta jak powinna – drogą właśnie pocztową). Po kilku telefonach do MS w pięknym kraju nad Wisłą nie udało się znaleźć osoby kompetentnej, która by podpowiedziała jak w/w problem rozwiązać. Nawet więcej, nie udało się znaleźć osoby, która potrafi skontaktować z personą kompetentną w dziedzinie SenderID.

Dla ciekawskich dodam, iż były zmieniane TTLe rekordów w dnsach, oraz wpisy PTR serwerów dns i pocztowych, z których chcemy coś skutecznie dostarczyć do hotmaila – efekt zawsze ten sam. Zrobiliśmy to już na wszystkie możliwe sposoby – zaglądając nawet do nagłówków, poczty która do hotmaila jakimś cudem dotarła.

My chcemy tylko powiadomić o urodzinach znajomego… a nie powiększyć pewną część ciała.

Dla cierpliwych i szukających wrażeń opis jak działa (albo jak powinno działać) SenderID można znaleźć tutaj: http://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx.

Dzisiaj, o ile nadal w dziedzinie interakcji z użytkownikiem, słowo widget oznacza konstrukcje bardziej skomplikowane. W najogólniejszym znaczeniu, widget to graficzny element pozwalający zrealizować jakieś funkcje lub prezentujący informacje. Przykładem najprostszego widgeta jest zegarek w pasku zadań na dole ekranu. Prezentuje bieżący czas oraz datę i pozwala na wykonanie kilku związanych z tym czynności – możemy ustawić godzinę, dzień, miesiąc, zmienić strefę czasową, obejrzeć cały kalendarz.

Ta definicja nie mówi nic o środowisku, w którym widget jest prezentowany. Może być to zatem pulpit systemu operacyjnego, okno jakiegoś programu, a nawet strona internetowa. Typowe widgety prezentują informację w sposób ciągły, nie wymagając akcji ze strony użytkownika. Jeśli zajrzymy do historii – w 1996 roku Microsoft wypuścił zestaw Power Toys, który prezentował zaawansowane możliwości systemu Windows 95. Jednym z elementów zestawu był program prezentujący czas, czyli zegar. Nowością był fakt, że ów zegar nie miał prostokątnego okna i dzięki temu wpasowywał się doskonale w każdy pulpit. Możemy więc uznać go za wczesny przykład widgeta. Rok później, ta sama firma wypuściła przeglądarkę Internet Explorer 4, a razem z nią funkcję Active Desktop. Dzięki niej pulpit stawał się hybrydą klasycznego pulpitu oraz strony internetowej. Można było na nim umieszczać fragmenty kodu, które prezentowały np. kursy akcji, pogodę czy na żywo, obliczane pozycje satelitów na orbicie Ziemi. Znowu – widgety.

Dziś widgety obsługiwane są przez wiele platform – zarówno systemów operacyjnych, programów jak i stron internetowych. Sztandarowym przykładem pierwszego jest najnowszy Windows Vista, który obsługuje widgety, nazwane tam gadgetami, na pulpicie oraz w pasku bocznym (Sidebar). Inne systemy operacyjne i środowiska również obsługują widgety, według tej definicji – w Mac OS X mamy Dashboard, w Linuksie jest to SuperKaramba lub gDesklets, zależnie od używanego środowiska graficznego. We wcześniejszych wersjach Windowsa możemy używać Kapsules, Klipfolio (gdzie widgety nazywane są Klips), albo Google Desktop. Ten ostatni funkcjonuje również pod Mac OS X i Linuksem.

Jeśli chodzi o aplikacje, to na pierwszym miejscu wymienić należy przeglądarkę Opera, która posiada już duży zestaw widgetów, oraz Firefoxa, który poprzez rozszerzenie Firefoxit obsługuje widgety w sposób zbliżony do wymienionego wcześniej Dashboarda. Inne rozszerzenia do Firefoxa również mogą być zakwalifikowane jako widgety – np. prezentujące pogodę, najnowsze wiadomości z RSS, czy ranking oglądanej strony w pasku statusu.

Na stronach www, dawno temu „bajerem” był zegarek w tekście strony lub w pasku statusu, zrealizowany Javascriptem. Kwalifikuje się jako prosty widget. Dziś te są bardziej rozbudowane – często w technologii Flash. Można na swojej stronie czy blogu umieścić gierki, graficzne zegarki, swoje najnowsze filmy wgrane na któryś z serwisów. Można pozwolić użytkownikom na zostawianie komentarzy głosowych, wyświetlić swój kalendarz, status w Skype, umieścić quiz, rozmawiać przez komunikatory albo cały swój blog zamienić w widget który inni mogą wstawić u siebie.

Istnieją też strony internetowe będące swego rodzaju agregatorami widgetów. Użytkownik może sam skomponować stronę, składającą się z wybranych elementów, np. czytników wiadomości RSS z różnych źródeł, swoim kalendarzem czy podglądem poczty. Takimi miejscami są iGoogle, Netvibes, Pageflakes.

Wszystkie wymienione wyżej kategorie są, w ramach konkursu, widgetami. Akceptujemy więc bardzo szeroki zakres prac, pod wiele platform i środowisk, dając wiele możliwości w wykazaniu się umiejętnościami oraz pomysłem. Regulamin określa, że najważniejszymi kryteriami będzie funkcjonalność i stopień wykorzystania zasobów Grona. Stawia za to niewiele ograniczeń co do techniki realizacji projektu, zostawiając ogromne pole do popisu.

Więcej informacji o konkursie na apidoc.grono.net, znajdziecie tam również dokumentację udostępnionych funkcji, przykładowy kod pokazujący jak z nich korzystać, info o kontakcie i pomocy, oraz formularze zgłaszania błędów.

Freestyle – może to być widget na PC, Maca lub stronę www.

Żadnych formalności – przesyłasz aplikację z opisem i swoje dane na adres api@grono.net, otrzymujesz potwierdzenie i jesteś w konkursie.

DO WYGRANIA:

• Staż w Dziale IT Grono.net
• Apple MacBook Pro
• Apple MacBook
• 3 iPody
• Wieczna sława twórcy ulubionego widgeta dla ponad 1,3 miliona naszych użytkowników!

Zgłoszenia przyjmujemy od 1 października do 30 listopada 2007

WSZYSTKO CZEGO POTRZEBUJESZ ZNAJDZIESZ NA apidoc.grono.net

Egzemplarz, który testowaliśmy miał 15 dysków sas, każdy o pojemności 72gb i prędkości obrotowej 15000 rpm. Macierz ma być używana jako nośnik dla bazy danych, więc zanim zostanie użyta musieliśmy przeprowadzić testy (by wiedzieć co i jak podzielić na poszczególne dyski logiczne). Podłączyliśmy ją do wolnego serwera (także Dell'a, ale nieużywanego), którego parametry są "całkiem, całkiem" :

• 4 dwurdzeniowe xeon'y (3.4ghz)
• 32gb ram
• 2 wewnętrzne dyski, sas, 72gb, 15000 rpm, 72g zestawione w raid1

Testy przeprowadziliśmy przy pomocy bonnie++, procedura testowa była prosta:

1. zestawienie nowego raida
2. mke2fs -j (ext3)
3. zamontowanie partycji z opcjami noatime i nodiratime
4. uruchomienie bonnie++ z tymi opcjami:"-u nobody:nobody -f -s 65000,8192 -n 0 -x 3" (8192 gdyż taka jest wielkość strony w postgresie)
5. rezultaty dla każdego raida (-x 3!) były uśrednione

Wiedzieliśmy, że docelowo zostanie użyty raid10, więc testowaliśmy głównie różne jego kombinacje. Przeprowadziliśmy 2 oddzielne serie testów:

1. raid 10, czysto sprzętowy, używając 2, 4, 6, 8, 10, 12 i 14 dysków
2. raid 10, mieszany sprzętowo/software'owy - sprzęt był użyty do zrobienia 7 oddzielnych dysków logicznych, każdy z użyciem 2 dysków fizycznych spiętych w raid1, ale potem były one składane w jeden dysk logiczny przy pomocy software'owego raida (linux, raid0) w urządzenie na 4, 6, 8, 10, 12 i 14 dyskach fizycznych

Testy przeprowadzono z wyłączeniem read-aheada, zapisy były w trybie write-back, gdyż macierz jest wyposażona w pamięć z podtrzymaniem bateryjnym. Rezultaty są trochę dziwne (czerwona linia - raid10 czysto sprzętowy, zielona linia - rozwiązanie mieszane: sprzęt/software):


Jeśli wolisz wyniki w postaci tabelek:

name	put_block	put_block_cpu	rewrite	rewrite_cpu	get_block	get_block_cpu	seeks	seeks_cpu
2xraid1	34820	12	25105	6	97459	9	436	1
4xraid10	95427	37	65661	19	246490	23	615	1
6xraid10	100367	39	70955	20	288188	27	672	1
8xraid10	165980	66	98887	29	423983	39	737	1
10xraid10	164195	64	96039	28	394442	36	618	1
12xraid10	185671	72	103271	30	414942	38	686	1
14xraid10	195349	76	104087	30	439088	40	821	2
2s0@2h1	86651	32	61836	18	251109	24	618	1
3s0@2h1	110977	42	79381	24	356231	34	708	2
4s0@2h1	120232	45	91988	28	391041	37	748	2
5s0@2h1	131024	50	92403	28	556601	55	788	2
6s0@2h1	123812	47	93563	28	482090	47	778	2
7s0@2h1	137513	53	100083	31	657221	65	839	2
2s0@6h10	160090	61	104375	32	482106	46	716	2
2s1@2h1	44373	16	25972	6	99071	10	651	1
13xraid5	222225	87	113040	32	392238	36	806	2
14xraid5	222690	87	114142	33	398201	36	809	2

Znaczenie kolumny name:

• (\d+)xraid(\d+) - $1 dysków w czysto sprzętowym raidzie $2. przykładowo - 6xraid10 oznacza 6 dysków w sprzętowym raidzie 10
• (\d+)s0@2h1 - $1 dysków logicznych (gdzie każdy dysk logiczny, to 2 dyski fizyczne spięte w sprzętowy raid1) połączone w software'owy raid0. przykładowo 5s0@2h1 oznacza 5 dysków logicznych (każdy z 2 napędów, w raid1) połączonych, dając razem raid 10 na 10 dyskach w układzie mieszanym sprzętowo/software'owym
• 2s0@6h10 - 2 dyski logiczne, każdy składający się z 6 dysków fizycznych połączonych w sprzętowy raid10, połączone w software'owy raid 0
• 2s1@2h1 - 2 dyski logiczne, każdy będący 2 dyskowym, sprzętowym, raidem 1, połączone w software'owy raid1. daje to 4 dyskowa macierz o pojemności pojedynczego dysku.

Jak widać, przetestowaliśmy kilka układów więcej niz pokazane jest to na wykresach powyżej, ale wszystkie pozostałe były jedynie testowe, bez realnego wpływu na jakiekolwiek decyzje. Dziwna sprawa - czysto sprzętowy raid wykazuje "schodki" w wydajności zapisów (i przepisywania danych). Przyrost wydajności był tylko wtedy, gdy ilość dysków była potęgą 2. W raidach mieszanych (sprzęt/software) nie było takiego efektu. Ponieważ macierz ma 15 dysków, zdecydowaliśmy się na użycie takiego layoutu:

• 1 dysk jako globalny hot-spare
• 2 diskowy raid1 (sprzętowy) na logi postgresa
• 8 dyskowy raid10 (sprzętowy) jako główna przestrzeń (tablespace) bazodanowa
• 4 dyskowy raid10 (sprzętowy) jako dodatkowa przestrzeń bazodanowa

Teoretycznie układ ten powinien zapewnić najlepszą wydajność, czy tak było? Po stworzeniu macierzy, założeniu systemów plików, przetestowaliśmy wydajność wszystkich 3 dysków logicznych jednocześnie. Wyników nie rozrysowywaliśmy, gdyż i tak nie miałoby to zbyt dużego sensu. Ale wyniki z testu można podać tabelarycznie:

name	put_block	put_block_cpu	rewrite	rewrite_cpu	get_block	get_block_cpu	seeks	seeks_cpu
2xraid1	30875	12	15438	5	39867	5	224	1
2xraid1	32489	14	24037	7	99700	9	389	1
2xraid1	35096	13	24708	6	96969	9	383	0
4xraid10	41343	18	31910	11	61798	8	109	0
4xraid10	80630	34	35707	12	137488	18	306	1
4xraid10	40136	17	38388	12	147282	16	255	0
8xraid10	42376	18	37513	13	155740	19	302	1
8xraid10	156044	65	34153	11	177690	22	338	1
8xraid10	146096	61	71307	25	29568	3	154	0

(pokazano tu wyniki każdego testu, czyli po 3 wyniki dla każdej z partycji). Jak widać, wyniki są niższe od oczekiwanych. Dodatkowo, analizę utrudnia fakt, iż test macierzy 8xraid10 skończył się jako pierwszy (bo jest najszybsza), 4xraid10 skończył się trochę później, a 2xraid1 trwał i trwał, i trwał:)
Myślę, że wybraliśmy rozwiązanie optymalne przy tej macierzy i kontrolerze, ale tak czy inaczej zastanawiające jest czemu wydajność tak mocno jest powiązana z potęgami dwójki.