Vypustili sme do sveta verejnú betaverziu projektu Nicereply. Je to služba, ktorá umožní napríklad vašim zákazníkom hodnotiť kvalitu vašich emailových odpovedí. Poučte sa z hodnotení a vylepšite spôsob, ako komunikujete. V  betaverzii je možné zadarmo vyskúšať nástroj, ktorý nám pomohol vybudovať skvelú zákaznícku podporu.

Ako to funguje?:

• vytvoríte si konto na nicereply.com
• vytvoríte kontá svojim zamestnancom
• pre každého dostanete link, ktorý vložíte do vašich mailov (signatúr, ticket systémov)
• prijímateľ správy obdrží vašu odpoveď a má možnost ohodnotiť ju
• potom už len stačí sledovať hodnotenia a štatistiky. Na ich základe vylepšovať svoje maily a maily svojich zamestnancov

Pre koho je Nicereply?

• pre všetkých, ktorí používajú email a stoja o spätnú väzbu
• helpdesk (Nicereply sa dá jednoducho prepojiť s každým ticket systémom)
• pre ľudí s e-shopmi – tu je komunikácia veľmi dôležitá
• dá sa použiť napr. aj na hodnotenie mailing listov, newsletterov a automatických mailov
• kreativite sa medze nekladú a hodnotiaci link môžete využiť na čokoľvek. (napr. aj na ohodnotenie tohoto článku. Predstavte si že je to email, ohodnoťte nám ho: http://nicereply.com/websupport/Truban/666)

Prečo sme vytvorili Nicereply?

Hovorí sa že človek/firma by sa mal držať toho, v čom je dobrý, a nám okrem hostingu celkom dobre ide aj zákaznícka podpora. Hodnotenie emailov sme vyvinuli a dlho používali (ak ste s nami komunikovali, určite ste si hodnotiaci link v mailoch všimli). Zamestnanci jednoducho vybavovali emaily a zákazníci ich hodnotili. Už po pár dňoch sme mali jasnú predstavu o tom, s ktorými zamestnancami sú zákazníci najviac a najmenej spokojní. Takže preto – tento nástroj nám tak pomohol a prišiel nám taký parádny, že sme sa rozhodli s ním podeliť.

Budeme radi, ak nám novú službu pomôžete otestovať a napíšete nám váš názor na contact@nicereply.com.

Berte a vychutnavajte.

Počet domén vzhľadom na TLD

Nasledujúca štatistika bola vygenerovaná prostredníctvom http://www.registrarstats.com a poskytuje základné informácie o počte celkových domén v miliónoch na každé TLD.

Počet európskych domén

Nasledujúci obrázok zase ilustruje počet zaregistrovaných .eu domén z jednotlivých krajín v rámci Európy (Zdroj).

Ďalšie zaujímavé fakty

A ešte pár perličiek a zaujímavostí o doménach:

• Prvou najstaršou doménou na svete je SYMBOLICS.com, ktorá bola vytvorená 15. marca 1985. Hneď za ňou bola vytvorená BBN.com a THINK.com.
• Pri príležitosti 25. výročia zápisu prvých .Com domén spustil VeriSign stránku www.25yearsof.com – na ktorej môžete nájsť okrem videa pripomínajúceho históriu internetu aj rôzny multimediálny obsah, osvetu inovátorov a podnikateľov, ktorí sa podieľali na rozvoji internetu.
• Prvých top 10 najstarších domén:
  1. 15-Mar-1985 SYMBOLICS.COM
  2. 24-Apr-1985 BBN.COM
  3. 24-May-1985 THINK.COM
  4. 11-Jul-1985 MCC.COM
  5. 30-Sep-1985 DEC.COM
  6. 07-Nov-1985 NORTHROP.COM
  7. 09-Jan-1986 XEROX.COM
  8. 17-Jan-1986 SRI.COM
  9. 03-Mar-1986 HP.COM
  10. 05-Mar-1986 BELLCORE.COM
• Kompletný zoznam nájdete na https://www.iwhois.com/oldest.
• Na konci roka 2009 bolo na Internete registrovaných spolu vo všetkých doménach najvyššej úrovne celkom 192 miliónov domén druhej úrovne. (Zdroj)
• Všetky 3-znakové .com domény už boli dávno zaregistrované. (čo sa týka .sk domén, 11866 domén je zatiaľ ešte stále nezaregistrovaných)
• Každá jedna doména obsahujúca iba čisto znak „a“ (t.j. a.com, aa.com, …, až po aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.com) už bola registrovaná.
• Najdrahšia doména v histórii bola predaná za $14 miliónov 19. Januára 2006 a bola ňou Sex.com. Fund.com sa predala v roku 2008 za takmer $10 miliónov a Porn.com sa predala v 2007 za $9 miliónov. (Zdroj)

Štatistika slovenských domén v roku 2010

Štatistika bola vytvorená z vygenerovaného zoznamu od spoločnosti Sk-nic, a.s. (https://www.sk-nic.sk/documents/domeny_1.txt) dňa 22.2.2010 o 04:30 hodiny rannej. Jednotlivý súbor poskytuje základné informácie ako názov SK domény, identifikátor registrátora a držiteľa domény, a pod.

Súbor obsahuje kompletný zoznam všetkých funkčných slovenských domén v počte 197980. Aktuálny počet zaregistrovaných SK domén k dňu 22.02.2010 predstavoval podľa Sk-nic-u 206719 domén, z čoho vyplýva, že zvyšných 8739 domén bolo nefunkčných.

Znaky v slovenských doménach

Všetky zaregistrované slovenské domény musia mať minimálne 2 a maximálne 63 znakov, z ktorých ani jeden nemôže obsahovať diakritiku a ich spojením nemôže vzniknúť vulgárne slovo.

• Celkový počet znakov v rámci všetkých domén –  1818601, čo je približne 1011 strán popísaných A4 (pri počte 1 normovaná strana = 1800 znakov na stranu vrátane medzier)
• Celkový počet funkčných domén –  197980, čo znamená, že na každého 27. obyvateľa Slovenska, spadá 1 doména (vzhľadom na počet obyvateľov k 30. septembru 2009 – 5 421 937)
• Priemerná dĺžka znakov na doménu:       9,185781392
• Počet znakov s najvyšším zastúpením:     8
• Počet domén s 2 znakmi:                      731
• Počet domén s 63 znakmi:                     2
• Domény s najväčším počtom znakov (63) –
  • tennajsampodivnejsizhlukpismeniekvdomeneakysilenvietepredstavit.sk
  • ziskajtepoistenieautaajcestovnepoistenieastavebnesporenieonline.sk

• Najpočetnejší znak v slovenských doménach je písmeno „a“ – 192752, potom „e“ – 165203 a „o“ s 147366 znakmi, čo je 11%, 9% a 8% zo všetkých znakov.
• Znak „-“ (pomlčka) je využívaná častejšie ako písmená „g“, „z“, „f“, „j“, „x“, „w“ a „q“
• Najmenej využívaným znakom je číslica 8, ktorá sa v názvoch domén nachádza presne 300 krát.

Všeobecne, štatistiky slovenských domén sú v súčasnosti na veľmi nízkej úrovni. Veríme, že poskytnuté údaje boli pre väčšinu z vás užitočné a už teraz sa môžete tešiť na pokračovanie s ďalšími zaujímavými faktami a číslami ;)

]]> http://blog.websupport.sk/2010/03/zaujimave-statistiky-slovenskych-domen/feed/ 13 http://blog.websupport.sk/2010/02/ako-pracuju-vyvojari-vo-websupporte/ http://blog.websupport.sk/2010/02/ako-pracuju-vyvojari-vo-websupporte/#comments Fri, 19 Feb 2010 09:33:04 +0000 WebSupport.sk team http://blog.websupport.sk/?p=345

Článok bude o nazretí do zákulisia jednej z časti WebSupportu. Akým spôsobom pracuje náš development. Vo svojej práci najčastejšie využíva agilný spôsob vývoja s metodikou SCRUM. Konkrétne tomuto procesu sa budeme ďalej v článku venovať

Celý kalendárny rok je rozdelený na iterácie – 2 týždňovky. Zároveň sú developeri rozdelení do vývojových teamov. Každý projekt, update, bugfix je na tieto iterácie naplánovaný a priradený teamu. Jednotlivé teamy majú svoju kapacitu, kapacita vyplýva zo súčtu úväzkov jednotlivých developerov. Zloženie teamov sa pravidelne mení.

Každá iterácia má taktiež svoje etapy a rozdelenie. Najdôležitejšie sú: plánovací meeting, denné meetingy, demo meeting a freeday. Tu je znázornený priebeh vývoja jednej iterácie:

Klient dodá kompletnú špecifikáciu prípadne ju s ním vypracujeme. Následne rozdelíme celý projekt na backlogy.

Backlog je logický celok, ktorý vyplýva zo špecifikácie. Napr. pri vytváraní blogovacieho portálu, by bol jeden z backlogov pridávanie a manažovanie článkov, druhý by mohol byť pridávanie a manažovanie komentárov.

Jednotlivým backlogom sa určí odhadovaný čas vývoja, priorita a priradia sa do iterácií. Súčet odhadovaných časov pre backlogy nemôže presahovať kapacitu teamu. Na začiatku každej iterácie je plánovací meeting.

Plánovací meeting

Pozostáva z predstavenia a oboznámenia teamu, rozplánovania celej iterácie. Zúčastňujú sa ho všetci programátori, ktorí budú na danej iterácii pracovať.

Spoločnými silami sa každý backlog určený pre iteráciu rozdelí na menšie úlohy (tasky). Tieto tasky už interpretujú prácu developera. Čas strávený na splnení daného tasku by nemal presiahnuť 16 hodín. Pokiaľ je daný task náročnejší je potrebné ho rozdeliť na viac taskov. Tak isto je potrebné dohodnúť sa, kedy budú denné meetingy počas danej iterácie.

Pri rozdelovaní backlogu na menšie tasky má každý priestor vyjadriť sa a je to priam žiadúce. Každý task sa zapisuje spolu so všetkými pripomienkami a dodatočnými informáciami. Po spísaní všetkých taskov sa určí postupnosť, resp. priorita.

Po tom, ako sú spísané všetky úlohy nasleduje časové ohodnotenie daného tasku. Každý task zahrňuje aj dokumentáciu k danej funkcionalite a otestovanie. Členovia teamu májú kartičky, ktoré obsahujú číslo v hodinách. Tento postup sa nazýva plánovací poker.

Každý člen teamu si premyslí, koľko bude trvať vypracovanie daného tasku a vyberie príslušnú hodnotu na kartičke, avšak neukazuje ju ostatným kolegom. Po tom ako sú všetci rozhodnutí pre správnu hodnotu sú vyzvaní, aby ukázali svoje kartičky.

Každý musí následne vysvetliť prečo zvolil danú hodnotu. Všetky dôvody sa zapisujú do poznámky k danému tasku. Ohodnocovanie tasku prebieha dovtedy, pokiaľ sa všetci nezhodnú na jednej časovej hodnote. Výsledná časová hodnota sa zapíše k danému tasku. Postup ohodnocovania úlohy prebieha identicky pre každý task.

Denný meeting

Každý člen teamu je povinný zúčastniť sa ho. Prípadnú neprítomnosť musí riešiť dostatočne včas. Každý z členov teamu musí odpovedať na otázky:

• Čo spravil
• Čo bude robiť
• Aké prekážky mu stoja v ceste, aby mohol napredovať podľa plánu

Problémy sa však neriešia. Denný meeting nie je priestor pre riešenie problémov a zdržovanie celého tímu. Na daily meetingu sa môže dohodnúť prípadný termín, kedy bude meeting, na ktorom sa vyrieši problém.

Demo meeting

Stretnutie s klientom a predstavenie celej práce za 2 týždne. Klient sa pýta a upresňuje svoju špecifikáciu. Prípadné zmeny sa zapisujú.

Freeday

Slúži ako rezerva pre prípadné predĺženie iterácie. Team by sa počas tohto dňa mal vzdelávať, urobiť si poriadok v kódoch, dokumentácii, retrospektívne zhodnotiť iteráciu a urobiť prípadne vylepšenia do ďalšej. V ideálnom prípade sa neriešia tasky.

Zlá škálovatelnosť MySQL

MySQL databáza má v niektorých prípadoch veľmi zlú škálovatelnosť. Nedá sa jednoducho vždy zvýšiť kapacita výkonu iba upgradom hardwaru na ktorom beží.
V našom prípade má MySQL problém s veľkým množstvom tabuliek, ktoré sa používajú a zamykaním table_cache v MySQL. Thready čakajú veľa času na otvorenie tabuliek (kým neuvoľní zámok iný thread). Keďže nastaveniami MySQL sa to vyriešit nedá, jediné riešenie je rozloženie záťaže na viac MySQL serverov na virtuálnych serveroch.
Postup je jednoduchý: reboot serveru do XEN verzie kernelu. S XEN verziou máme možnosť dynamicky spúštať virtuálne servery zároveň s hlavným systémom. Následne môžme po častiach popresúvať databázy z hlavnej MySQL na dalšie virtuálne servery.

Jeden z problémov ktoré sa vyskytli, bola chyba v XEN kerneli debianu, ktorá ešte nebola opravená v hlavnom repozitári.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516479

Odlahčenie záťaže databáz

Monitorujeme sql query bežiace na MySQL serveroch a hľadáme neoptimalizované query ktore zbytočne zaťažujú server. Ak objavíme nejaký problém, kontaktujeme zákazníka. V niektorých prípadoch aj pomôžeme s optimalizáciu sql query. Na grafe je vidieť klesnutie záťaže na databázovom serveri po oprave query nad veľkou tabuľkou s problémom ORDER BY RAND(). Graf ilustruje ako môže záťaž na serveroch ovplyvňovať zlý kód aplikácie (query do db).

Bližšie informácie o probléme ORDER BY RAND() http://www.titov.net/2005/09/21/do-not-use-order-by-rand-or-how-to-get-random-rows-from-table/

Často sa nás pýtaju klienti, či ich server unesie vysokú návštevnosť, tisícky zobrazení a podobne. Návštevnosť je dôležitá, ale keď je aplikácia zle naprogramovaná, nepomôžu vám ani najvýkonejšie servery. A platí to aj presne naopak. Pri pekne odladenom a vychovanom kóde, vám bude stačiť aj virtual s pár MB Ram.

Email služby

Dávnejšie v lete sa nám podarilo znížiť zaťaženie emailového serveru zmenou I/O schedulera z CFQ na DEADLINE. CFQ scheduler ktorý rovnomerne rozdeľuje diskové operácie, ktoré volajú procesy začal robiť problémy pri veľkom počte procesov v systéme, ktoré čítali/zapisovali veľa malých súborov. Po zmene schedulera na DEADLINE sa výrazne zlepšila rýchlosť emailových služieb. DEADLINE scheduler používa 4 I/O fronty a zoraďuje čakajúce requesty aby zvýšil I/O priepustnosť. Je výhodné ak prevláda jeden typ záťaže. Na grafe je pekne vidno, ako to znížilo zaťaženie.

Momentálne už emailové služby obsluhuje iný, výkonnejší server.

Web služby

Rýchlosť webových služieb unlimited a custom hostingu sa zlepšila po ugprade webserverov z distribúcie debian etch na verziu lenny a kernelu na verziu 2.6.31, ten prináša lepší readahead algoritmus pre I/O operácie. Taktiež bola opravená chyba v driveri pre raid radič, ktorá spôsobovala spomalenie diskových operácií pri vyššej záťaži. Na grafe môžete vidieť zníženie loadu na webserveroch po aplikovní novej verzie kernelu.

Nakoľko sme nedávno na náš zdieľaný webhosting implementovali podporu Ruby on Rails (ktorú si môžete jednoducho aktivovať vo Webadmine), rozhodli sme sa spracovať aj jednoduchý a prehľadný návod, ako by ste mohli tento programovací jazyk a jeho výhody využívať aj na Vašich virtuálnych serveroch.

Na každom virtuálnom serveri je nainštalovaný Debian Lenny, takže pravdepodobne budete oboznámení s jeho nástrojom na správu software:apt-get, resp. aptitude.

Samotný Ruby sa nachádza v štandardných repozitároch, takže Vám stačí jednoducho vykonať:

aptitude install ruby rdoc irb rubygems libzlib-ruby libfcgi-ruby1.8 openssl libopenssl-ruby

čím nainštalujete všetky potrebné programy, knižnice a závislosti.

Keď Vám tieto balíčky zbehnú, bude potrebné nainštalovať aj Rails – framework postavený na scriptovacom jazyku Ruby. Toto je možné realizovať len ak sa Vám úspešne podarilo nainštalovať vyššie uvedený balík rubygems.

gem install rails –include-dependencies

A to je vlastne všetko :-)

Dodatočne môžete vyžadovať podporu MySQL/PostgreSQL, alebo sqlite. Rieši sa to nasledovnou inštaláciou príslušných knižníc:

aptitude install libmysql-ruby libpgsql-ruby libsqlite3-ruby

Nový RoR projekt vytvoríte tak, že si zvolíte pracovné prostredie (odporúčam napríklad /var/www/ruby) a spustíte príkaz

rails nazovprojektu

V prípade, že v projekte plánujete využívať MySQL databázu (defaultne sa totiž spúšťa spolu s sqlite3), napíšete:

rails nazovprojektu -d mysql

Následne sa automaticky vytvorí základná koreňová štruktúra súborov, potrebných pre beh každej RoR aplikácie.

Posledný krok je spustenie servera – Ruby má možnosť pracovať s niekoľkými rôznymi servermi, spolu s inštaláciou však prichádza Webrick.

Naštartujeme z nášho aplikačného prostredia (/var/www/rails/nazovprojektu)

script/server

a fungujeme.

Webrick však beží na porte 3000, do prehliadača treba teda zadať

http://ip-virtualu:3000

a môžeme teda veselo programovať. :)

Taktiež tu je možnosť využiť na interpretovanie Ruby scriptov štandardný Apache

apt-get install apache2 libapache2-mod-fcgid libfcgi-ruby1.8

povolíme nejaké dodatočné moduly

a2enmod ssl
a2enmod rewrite
a2enmod suexec
a2enmod include

a do adresára /var/rails/nazovprojektu/public nahodíme tento htaccess

#AddHandler fastcgi-script .fcgi
#AddHandler cgi-script .cgi
AddHandler fcgid-script .fcgi
Options +FollowSymLinks +ExecCGI

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
#RewriteRule ^(.*)$ dispatch.cgi [QSA,L]
#RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

ErrorDocument 500 “<h2>Application error</h2>Rails application failed to start properly”

Nakoniec  k popisu s Apachom treba ešte nakonfigurovať virtualhost v /etc/apache2/sites-available/default a v prípade, že chceme, aby všetko fungovalo na hlavnom virtualhoste

napísať:

<Virtualhost *:80>
ServerName localhost
DocumentRoot /var/rails/testapp/public

<Directory /var/rails/testapp/public>
Options ExecCGI FollowSymLinks
AllowOverride all
Order allow,deny
Allow from all
</Directory>
</Virtualhost>

V prípade, že chceme robiť viacero inštancií pod jedným serverom, tak píšeme

<Virtualhost *:80>
ServerName nazovprojektu.example.com
DocumentRoot /var/rails/nazovprojektu/public/

<Directory /var/rails/nazovprojektu/public>
Options ExecCGI FollowSymLinks
AllowOverride all
Order allow,deny
Allow from all
</Directory>
</Virtualhost>

a samozrejme reštart apache /etc/init.d/apache2 restart

V prípade, že sa o Ruby on Rails chcete dozvedieť alebo naučiť niečo viac, nahliadnite do týchto 12 tutorialov - http://www.digitalmediaminute.com/article/1816/top-ruby-on-rails-tutorials

Veľmi zjednodušene môžeme rozdeliť pamäť v Linuxe na 2 typy:

• mapped – aplikácie – stack, data, loadnuté knižnice, alokovaná pamäť za behu app, …
• unmapped – page cache (disková cache) – cacheujú sa tam súbory pri čítaní/zápise na disky, rieši to kernel nezávisle od aplikácií
• (a ešte máme nejaké ďalšie ako slab, kde sú TCP/IP stack buffre, directory entries, atď.)

Page cache je v Linuxe nie najlepšie implementovaná.
Jeden z problémov, ktoré ma trápia, je napríklad to, že jeden task pri zápise alebo načítaní veľkého množstva dát odstráni z page cache všetko ostatné a nahradí to tým, čo číta/zapisuje.

Na desktope to tak nevadí.
Predstavme si ale vyťažený server, kde pristupujú stovky klientov a každý jeden démon, na ktorý je pripojený klient, číta iné dáta z disku a masívne sa tam využívajú nacachované data.

Zrazu sa spustí nejaký backup alebo iná aplikácia a začne robiť s objemným množstvom dát.
Stane sa to, že sa dáta potrebné pre tie démony z page cache odstránia, následne démony čakajú na IO z diskov, lebo nemajú dáta nacachované, server laguje a je to pekne v **** :-)

Ukážka, server zo 16 GB RAM, vytvoríme 6 GB file, zmažeme ho a pozrieme sa na pamäť:

# dd if=/dev/zero of=foo bs=1M count=6144
6144+0 records in
6144+0 records out
6442450944 bytes (6.4 GB) copied, 67.489 seconds, 95.5 MB/s
# free -m
            total      used      free    shared    buffers    cached
Mem:        15928      15872        55          0          0      12946
-/+ buffers/cache:      2926      13001
Swap:          949        520        428
# rm foo
# free -m
            total      used      free    shared    buffers    cached
Mem:        15928      9630      6297          0          0      6865
-/+ buffers/cache:      2765      13163
Swap:          949        520        428

Ako môžete vidieť – 6GB nám zmizlo z cached a je free.
Vytvorenie 6GB súboru nám odstránilo z cache 6GB nacachovaných dát a následne zmazanie súboru uvoľnilo pamäť z page cache.

V Linuxe už dlho existuje nejaké limitovanie pamäte pre procesy (syscall setrlimit()), napr. builtin príkaz ulimit v shelloch, alebo pam v /etc/security/limits.conf (hlavne pre užívateľov, ktorí sa prihlásia).
To nám ale limituje iba mapped pamäť, nie page cache. Môžete aplikáciu olimitovať povedzme na 100 MB, ale aj tak pri čítaní/zápise veľkého množstva dát vám odcachuje potrebné dáta z page cache.

V nových kerneloch nám pribudla pekná featura tzv. control groups, pomocou nej môžeme nastaviť pre rôzne procesy limity na celkovú použitú pamäť.
Teda mapped aj unmapped, taktiež nastaviť iba konkrétne CPU pri smp systémoch, kde majú dané procesy bežať.
Kernel v Ubuntu má všetko čo je treba, tak si to poďme rovno ukázať, ako sa to konfiguruje.

# mkdir /cgroup
# mount -t cgroup -o cpuset,memory none /cgroup

# cat /cgroup/cpuset.cpus
0-3 <--- 2 CPU po 2 jadrá, teda 4 jadrá dokopy.
# cat /cgroup/cpuset.mems
0-1<--- iba pri numa systémoch, každé CPU má vlastnú pamäť, majú to hlavne Opterony,
ale sú aj Xeony z numa podporou.

# mkdir /cgroup/test (tu sa nam objavia automaticky vsetky subory ako v /cgroup/)
  Teraz musíme nastaviť CPU a pamäť, lebo defaultne ma nová cgroupa všetko prázdne.
# cat /cgroup/cpuset.cpus >/cgroup/test/cpuset.cpus
# cat /cgroup/cpuset.mems >/cgroup/test/cpuset.mems
  Olimitujeme túto cgroupu na 128 MB RAM.
# echo 128M >/cgroup/test/memory.limit_in_bytes
  Hodíme pid bashu, s ktorým robíme do novej cgroupy, všetky novovytvorené child
procesy budú automaticky v tejto cgroupe.
# echo $$ >/cgroup/test/tasks
  vytvoríme 6GB file
# dd if=/dev/zero of=foo bs=1M count=6144
6144+0 records in
6144+0 records out
6442450944 bytes (6.4 GB) copied, 108.919 seconds, 59.1 MB/s
# free -m
            total      used      free    shared    buffers    cached
Mem:        15928      15696        231          0          0      13417
-/+ buffers/cache:      2278      13649
Swap:          949        556        392
# rm foo
# free -m
            total      used      free    shared    buffers    cached
Mem:        15928      15553        374          0          0      13291
-/+ buffers/cache:      2262      13665
Swap:          949        556        392

Voila, dd nám nezmazalo 6 GB z page cache, ale bolo limitované na 128 MB RAM a v prípade, že aplikácia prekročí sama nastavený limit pamäti (nie page cache), tak ju killne OOM killer.

Môžeme ju zrušiť

# rmdir /cgroup/test
rmdir: /cgroup/test: Device or resource busy
  Samozrejme sa nedá, lebo tam máme bash,
  tak ho najskôr prehodíme do hlavnej cgroupy
# echo $$ >/cgroup/tasks
# rmdir /cgroup/test

Page cache je stále zle vyriešené, ale toto je aspoň niečo, čím môžeme olimitovať rôzne aplikácie na serveri.
Ďalšou zaujímavou vecou v cgroups, ktorá ešte nie je priamo v kerneli, je bio-cgroup + dm-ioband – tým sa dá limitovať I/O bandwith, ale netestoval som.

Existujú aj nejaké userspace tooly, ale neskúšal som ani jeden. Niekde na Fedora stránke som videl, že majú aj pam modul pre cgroups, netestoval som ho.

V tejto sérií článkov Vám ukážeme ako máme riešený helpdesk. Konkrétne ako sa vysporiadávame s požiadavkami našich klientov. Denne nám prídu stovky mailov s otázkami, pripomienkami a žiadosťou o pomoc. Bez dobrého ticketového systému by bolo efektívne spravovanie toľkých požiadavok nemožné.

Nám v tomto vídatne pomáha open source software OTRS.org

Každý mail ktorý nám zákazník pošle na kontaktnú adresu helpdesk@websupport.sk, systém stiahne a priradí mu číslo (ticket). Následne ho na základe filtrov vloží do patričnej záložky a priradí zamestnancovi.

Systém ďalej funguje ako normálny mailový klient. Na požiadavky/tickety sa dá odpovedať, dajú sa presunúť inému zamestnancovi alebo technikom. Dajú sa locknúť kým sa na nich pracuje, aby to isté nemusel robiť niekto druhý, môžete ich sledovať prípadne komentovať.

Lepšie fungovanie systému pochopíte z týchto screenshotov: http://otrs.org/screenshot/ prípadne z dema: http://demo.otrs.org/otrs/index.pl

Článok sme vytvorili, pretože si myslíme že niektorým našim klientom, ktorý nič takéto nepoužívajú, by sa podobný systém mohol zdať užitočný. OTRS doporučujeme všetkým firmám, ktorých komunikácia so zákazníkmi prebieha hlavne na úrovni mailov a o ich požiadavky sa stará viacero zamestnancov. Systém má rozhranie aj pre zákazníkov, to ale my nepoužívame. Taktiež sa doň dajú logovať aj telefonáty, ale to už ručne a preto túto funkciou nepoužívame.

Ak vás OTRS zaujalo, radi vám pri jeho implementácii pomôžeme. Prípadne odpovieme otázky aj v komentároch pod článkom.

V budúcom článku o helpdesku vám ukážeme ako máme vyriešené telefonické požiadavky.

Berte a vychutnávajte.

Pre niektorých z vás (našich klientov) môže byť zaujímavé vidieť na akom železe sú uložené vaše stránky, vaše emaily a čo všetko sa stará o to aby chod nášho hostingu bol bezproblémový. Pri pridávaní nových serverov do ďalšieho racku sme naše mašinky pofotili a tak sa s vami o ne podelíme.

Začneme diskovým polom (dole) s obslužným serverom. Kedysi slúžilo ako storage pre weby, dnes už pre maily.

Weby sú porozdelované medzi servery ktoré sú na ďalšom obrázku. Takmer všetky servery majú 8-16GB ram a dva štvorjadrové procesory Xeon. Každý z nich ma samozrejme meno (hostname). Tie sú odvodené prevažne z názvov rôznych filmov alebo ich hlavných hrdinov.

Na ďalšom obrázku sú webservery: prvý je Redneck SunFire X4100 M2.

Spodní štyria krásavci sú servery Sunfire X2200. Úplne hore je Max – z filmu Mad Max, DiNorscio z filmu Find me guilty , Indiana Jones – to hádam netreba vysvetľovať. Logan je z Logan’s run a Krull z filmu Krull.

Nedávno pribudli do nového racku traja roboti. Všetci s označením Sunfire x4150.

am – z hry I Have No Mouth, and I Must Scream, kde najdrsnejší počítač na svete ovládne ľudstvo a 5 z nich si nechá a mučí ich vyše 100 rokov.

proteus – z filmu Demon seed o veľmi zlom počítači

colossus – z filmu Colossus: The forbidden project o ďalšom počítači ktorý ovládne ľudstvo.

My sme všetky tieto najväčšie monštrá najali, aby sa starali o naše služby a ochránili vaše data. Zoznámte sa:

Servery majú dvojité napájanie.

Nočný pohľad zo zadu:

Nakoniec pohľad na celý prvý rack. Tých serverov je v racku tak málo z dôvodu veľkého výkonu a veľkého odberu. Viac ich do tohto racku nie je možné dať. Na spodu racku sú ešte pozostatky starých serverov, keď sme používali samostatne poskladané servery. (pôvodne ich bolo 10). Za celú dobu fungovania našich služieb sa u nás vystriedalo množstvo počítačov/serverov, mnohé z nich už nemáme. Naštastie sa nám podarilo znovuobjaviť úplné prvý server z pred 7-dmich rokov, ktorý vám predstavíme nabudúce.

Ak by ste mali akékoľvek otázky, pripomienky alebo vylepšienia, budeme veľmi radi ak sa vyjadríte v diskusii a spoločne tak budeme prevádzkovať lepšie služby.