Men en sak man ofta missar när man kravställer backup, det är att kravställa återställningstid och att det faktiskt går att återställa backupen. Säg att du backar 100Gb data över internet, för det mesta så skickar du ju bara förändringar vilket gör att volymen på backupkontot bara ökar, vilket blir en flaskhals sen när du ska återställa det, hur lång tid tror du att det tar att återställa 100Gb över internet? Självklart så beror det på linan, men det tar sin lilla stund oavsett.

Så, en uppmaning till alla: Kravställ att din backup ska kunna återläsas och att det finns en högsta återställningstid, du kommer att tjäna på det när du väl vill göra en återställning.

CentOS kommer som tvåa, och det är inte särskilt förvånande, om Debian är en liten och smidig F1 maskin så är CentOS mer som en jäkligt robust pansarvagn att jobba med, jag tycker att den känns enormt solid och paketformatet RPM är väldigt lättarbetat och tenderar att lösa dependencyproblem bättre än APT.

Vill du läsa artikeln finns den här: www.idg.se/2.1085/1.425993/debian-toppar-pa-linuxservrar

Med rätt mjukvara så är det inga problem att köra SIP på telefonerna mot tex CellIP, dock så minns jag inte hur man gör

Jag har tänkt mig 500 Sek / st för telefonerna, tar du båda på en gång så säger vi 800. Jag skickar ogärna dom, men betalar du frakten så löser vi det! Annars finns dom att hämta på kontoret i Nacka Strand.

Sugen? Kontakta mig på andreas@abergman.se eller på twitter @a_bergman

Vad lärde vi oss av detta då? Backup, Backup, Backup.

Missa den inte på: GleSYS.se

Sedan väljer du att installera dom applikationer du vill ha, tex MySQL, Nginx och PHP. Allt är frid och fröjd så länge din applikation bara har ett fåtal besökare, MEN när besöksantalet växer, applikationen blir mer krävande, du lägger till CPU, RAM och HDD men applikationen går ändå inte fortare, känns det igen?

Allt detta beror på att linux är helt felpaketerat, många av applikationerna, begränsningarna i hur många filer och processer en användare får använda och antalet databastabeller som får vara öppna samtidigt i databasen, är alla konfigurerade för att köras på en mobiltelefon, prestandamässigt åtminstone.

För att ta ett exempel: en större webbapplikation kanske har en 2000 databastabeller, är det en WordPress multisite så kan den mycket väl ha fler, vad sägs om några tusen tabeller? Som standard är den MySQL konfiguration som skeppas med Debian 6 satt med en table_open_cache till 256, det optimala för MySQL är antalet tabeller * max antal joins och i de flesta webbapplikationer gör man fler än 2 joins i en query, säg att man gör 3 joins som mest i en query det gör att table_open_cache borde vara någonstans runt 2000 * 3 dvs 6000. Så istället för att skeppa en liten konfig som standard, skeppa en konfig som låter mig nyttja servern till max.

Ett bättre och ett fel som många springer på och som jag avhandlar i det här blogginlägget är att användarkonton i linux av någon outgrundlig anledning har ett maxtak på 1024 öppna filer. Jag köper att man kanske har det på Ubuntu som är en desktopapplikation, men i Debian som installeras som en server? Hur har man tänkt där?

Det är två exempel på hur sned standardkonfigurationen är, det känns som att när man paketerar linuxdistributionerna så tänker man “Men vi vill ju inte att servern går omkull, så vi konfar allting lågt”. Jag vet att det är ofta är standardkonfigurationen för applikationen som skeppas, och det spelar ingen roll, det är precis lika skevt och det är inte intressant om det är applikationens konfiguration eller om det är en konfiguration gjord av teamet bakom distributionen, det som påverkas i slutändan är användaren och användarupplevelsen.

I min värld så är det helt snett, att nyttja en server till 50% av sin kapacitet är inte ekonomiskt. Säg att du köpt en server för 20 000, och lite tillbehör för 10 000 så din kostnad för servern är 30 000 och kanske 5 000 / månad (man brukar räkna 5500 som kostnaden för en server / månad med underhåll och patchar) om då bara nyttjar servern till 50% då slänger du ju bort 50% av din investering varje månad, och hur sjukt är inte det? I en ideal värld så vill man utnyttja servern så mycket som möjligt, säg att den ligger på 70% vid normal användning och 100% vid en peak, då nyttjar man både sin investering och den energi som går åt att driva och kyla servern maximalt. Här kan man applicera samma tänk som man använder när man pratar om fördelarna med virtualisering, högre utnyttjande av mindre hårdvara är bättre ekonomi och miljö.

I en del fall är det kanske inte hållbart att köra servern tills den kroknar och går ner, utan man vill försöka hålla maskinen online och vill då ha ett max utnyttjande på 90% vid en peak, oavsett så är nyckeln att se över konfigurationen. Om servern utnyttjas till sitt max, då är det också enklare att se vart i sin applikation man ska optimera, man kanske måste snygga till koden, databasen eller tänka över hela sin design, men det kan och ska man inte göra förrän man är säker på att man nyttjar servern till sitt max, eller åtminstone det max man satt upp som företagspolicy.

Det är irrelevant om servern är en VPS eller dedikerat stål, det är ändå i allas intresse att servern utnyttjas till fullo, eller det är åtminstone i kundens intresse, en VPS leverantör tycker nog inte att 100% nyttjande av 100% av maskinerna är sådär superkul. Men det ger kunden mer bang for the buck.

Kan vi inte enas om att se över våra konfigurationer och se till att vi nyttjar våra maskiner så mycket det går?

Men, allt eftersom jag började läsa så såg jag att det är ju redan löst, med funktionen session_set_save_handler eller direkt i php.ini med memcached, då är det session.save_handler som gäller. Som default så använder PHP files, men det finns inbyggt stöd för memcache och det är superenkelt att aktivera.

session.save_handler = memcache
session.save_path = "tcp://127.0.0.1:11211"

Klart! Nu sparar PHP alla sessioner till din lokala memcacheburk, skulle du vilja spara det på en extern instans så är det bara att ersätta IP-adressen. Memcache är kanske inte helt optimalt för att spara data in, då det har en tendens att crasha och första datan. Så en kombination av (No)SQL och Memcache hade varit ett bra alternativ, SQL för säkerheten och Memcache för hastigheten, med NoSQL som typ MongoDB så kan man skippa Memcache.

I dokumentationen för PHP finns det bra exempel på hur du själv kan anpassa session_set_save_handler för att använda den backend du vill använda. @ChristofferP påpekade att bland annat PHP ramverket Litihum har stöd för alternativa session stores.

Fördelen med att kunna spara sessionen i ett delat storage är att man kan skippa sticky sessions när man lastbalanserar, och balansera jämnare över klustret. Om det är någon som vet om det finns ett smidigt sätt att inkludera sin egen sessionsklass i WordPress, säg till!

Av någon anledning så kommer dom flesta linuxdistributioner, och de programpaket som skeppas med en minimal konfiguration, vilket gör att man ganska snabbt stöter på problem och flaskhalsar på grund av lågt satta begränsningar i operativsystemet.

En av de begränsningar man stöter på är att antalet tillåtna file descriptors (FD) för användaren som webbservern och eller PHP-FPM körs som är för lågt satta. Debian 6 skeppas med 1024 file descriptors / användare, och maxantalet i systemet brukar vara runt 3 miljoner. Exakt vilket antal FD man bör ha på användaren är svårt att säga, men förutsatt att servern inte kör fler applikationer än Nginx och PHP-FPM så kan man ta i ganska rejält, på en stor installation jag jobbar med så har användaren en gräns på runt 300 000, men jag kan inte se något fel i att öka den ännu mer.

Att felsöka filedescriptors

Till att börja med så vill man veta hur många FDs som systemet får ha som mest.

# sysctl fs.file-max
fs.file-max = 70000

Nu vet vi att systemet som mest kan ha 70 000 FDs. Hur många FDs används då?

#sysctl fs.file-nr
fs.file-nr = 1020 0 70000

Där 1020 är antalet aktiva filer (file handles), 0 antalet allokerade men inaktiva filer, och 70 000 är max antal. För att ta reda på max antal FDs för en specifik annvändare, logga in som användaren och kör:

#ulimit -Sn
1024
#ulimit -Hn
1024

ulimit talar om för dig hur många FDs som användaren får lov att ha öppna, 1024 är lagom för de flesta, men har du högt trafikerade servrar så kommer du behöva höja, det gör du genom att ändra gränsen i /etc/security/limits.conf

abergman                soft    nofile          65535
abergman                hard    no file          65535

Det gör att min användare, abergman får lov att ha 65535 file descriptors, för att ändringen ska slå igenom så måste webbservern och PHP-FPM startas om.

Referenser för dig som vill läsa mer, även ett stort tack till Tom för att han pekade mig i rätt riktning vad gäller mod_limits i PAM.
http://www.cs.uwaterloo.ca/~brecht/servers/openfiles.html
http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/
http://research.cs.wisc.edu/condor/condorg/linux_scalability.html

To copy a applicationpool, you only have to run:

import-module webadministration
copy IIS:\AppPools\OldPool IIS:\AppPools\NewPool -force

You might receive an error when loading the module, but you can ignore it. Happy copying!

Source(http://www.mcbsys.com/techblog/2011/06/copy-an-iis7-application-pool/)

Installationen var inget att orda om, det gick snabbt och enkelt, och inställningarna är självförklarande.

För något år sen så körde jag ett antivirus av Norton, och det var ju ingen höjdare, minst sagt! Men Kaspersky Internet Security 2011 märks knappt, datorn tuggar på och jag behöver knappt engagera mig, och det är ju hemskt skönt, finns så mycket annat som är roligt.

Eftersom Kaspersky Internet Security 2011 har inbyggt stöd mot phising, dvs hemsidebedrägeri så slipper jag oroa mig för att användaren klickar på fel länkar, eller laddar ner något korkat, för Kaspersky håller koll på datorn.

Nu rekommenderar jag Kaspersky Internet Security till all mina vänner, även om jag inte har en fet badge att visa när jag gjort ett test, så är jag sjukt nöjd med det här antiviruset.