Archive for mei, 2010

XLS introduceert Fedora 13

donderdag, mei 27th, 2010

Vanaf vandaag is het mogelijk om Fedora 13 te kiezen bij het bestellen van een nieuwe VPS of de herinstallatie van een reeds bestaande VPS.

FedoraProject is de development tak van RedHat en alle nieuwe features die ook in de mainstream RedHat releases komen worden hier als eerste gelanceerd. Door de snelle development- en releasecycle van Fedora is de lifecycle (de lengte waarin security-updates worden aangeboden) veel korter dan bij andere distributies. De formule die Fedora hanteert is 6 maanden + 2 releases, welke ieder half jaar uitkomen, wat de maximale lifecycle op 18 maanden brengt.

Magento-Performance en Optimalisatie

vrijdag, mei 21st, 2010

Het webshop CMS Magento is met name het laatste jaar erg populair geworden. Het heeft enorm veel features en is makkelijk in het gebruik. Hierdoor worden er nu al een behoorlijk aantal Magento shops op onze virtuele servers gehost. Een klacht die wel regelmatig naar boven komt betreft shops die langzaam worden op drukke momenten, hierdoor kan er voor een webshop makkelijk omzet verloren gaan. Het toevoegen van extra RAM op de server of VPS is hierbij maar in beperkte mate een oplossing omdat Magento in deze gevallen ook veel te hongerig naar CPU-kracht bleek en enthousiast alle beschikbare cores vol trok.

Wij kijken vaak met klanten mee om de performance van hun sites en applicaties te verbeteren en zo ook met Magento. Hieronder een aantal configuratietips van onze systeembeheerders die de performance van Magento enorm kunnen verbeteren.

  • Gebruik een up-to-date versie van Magento. De ontwikkelaars van Magento zijn zich bewust van de performance issues en zijn de laatste maanden hard bezig om de snelheid te verhogen.
  • Zet de logging module mage_log uit, deze veroorzaakt enorm veel harddisk IO. Als alternatief kan er binnen Magento een Google Analytics ID worden opgegeven.
  • Sla de var-directory binnen het geheugen op. Dit kan met tmpfs bereikt worden en zal een enorme hoeveelheid harddisk-IO voorkomen.
  • Optimaliseer Apache en MySQL. Binnen Apache is het belangrijk om KeepAlive uit te schakelen zodat inactieve threads geen geheugen gebruiken. Bij MySQL is de eerste stap bij optimalisatie het activeren en optimaliseren van de query_cache_size en thread_cache_size. Hoe we deze en andere variabelen veranderen is echter sterk afhankelijk van de specifieke situatie.
  • Opcode caching aanzetten. Dit kan een hoop schelen, eAccelerator is onze favoriet maar er zijn meerdere oplossingen beschikbaar.

Neem als bestaande klant of lezer van dit blog gerust contact met ons op als u meer advies nodig heeft. Wij denken graag met u mee om de snelheid van uw site of applicatie te maximaliseren en daarbij de kosten beheerstbaar te houden.

N2 STALE meldingen opgelost

zondag, mei 9th, 2010

We kregen de laatste tijd van klanten vaak vragen over de betekenis van de melding ‘STALE’ in de N2 monitoring interface. In het kort betekent deze melding dat, op een gegeven tijdstip, de UDP-pakketjes die de n2txd-agent naar ons monitoring-systeem stuurt niet zijn aangekomen. Als dit een enkele keer bij een VPS voorkomt maar hij niet minutenlang in die staat blijft hangen is er op zich geen reden tot ongerustheid, maar liever zien we ze natuurlijk helemaal niet.

Ons vermoeden voor het vaker voorkomen van deze meldingen was dat het iets te maken had met de netwerk-interface van de monitoring machine. We hebben deze onlangs dan ook vervangen door nieuwere hardware met een A-merk netwerkkaart. Helaas bleken we hiermee op een dood spoor te zitten, de meldingen bleven bij vlagen verschijnen.

Uiteindelijk bleek de oorzaak te liggen in een veel subtieler schaalprobleem. Het programma dat verantwoordelijk is voor het ontvangen en verwerken van de UDP-pakketjes was tot nog toe een single-threaded daemon die in de in een ‘infinite loop’ iedere keer op een UDP-pakketje wachtte, dit pakketje verwerkte, eventueel wat opruimwerk verrichte en dan weer op een pakketje wachtte. Dit ontwerp had voor de eerste paar duizend hosts geen enkel probleem en het programma gebruikt, ook nu, nooit echt veel CPU.

De stap ‘opruimwerk’ bleek echter een onvoorspelbare factor. Deze duurde soms net lang genoeg dat een hoger aantal UDP-pakketjes zich opstapelde in de kernel. Als deze wachtrij te lang werd, dan begon de kernel doodleuk met het weggooien van volgende pakketjes.

De software is nu aangepast naar een multi-threaded ontwerp, waarbij een losse achtergrond-thread alleen de verantwoordelijkheid heeft voor het uit de kernel-wachtrij trekken van de UDP pakketjes. Hierdoor kunnen deze zich niet meer opstapelen en zijn de STALE-meldingen als het goed is verleden tijd.

XLS introduceert Ubuntu 10.04 LTS

dinsdag, mei 4th, 2010

Wij hebben het sinds gisteren mogelijk gemaakt de nieuwe Ubuntu 10.04 op nieuwe virtuele servers te bestellen en op bestaande VPSen te herinstalleren. Dit is een LTS (Long Term Support) versie van Ubuntu dus u krijgt 5 jaar support op deze versie.

Op de volgende wiki pagina kunt u meer informatie vinden over het upgraden van een bestaande VPS met Ubuntu naar Ubuntu 10.04. Zorg dat u deze pagina leest voordat u een upgrade uit gaat voeren.

Plesk incompatible met OpenSSL update (CentOS)

dinsdag, mei 4th, 2010

Bij het rebooten van een VPS met Plesk en CentOS is het mogelijk dat Plesk niet meer wil starten omdat deze niet compatible is met de geupdate versie van OpenSSL.

in de plesk logfile /var/log/sw-cp-server/error_log zou u in dat geval voorbij moeten zien komen:

(log.c.75) server started
(network.c.336) SSL: error:00000000:lib(0):func(0):reason(0)
(….)

Plesk heeft een Update van hun “Parallels Panel web-engine” instructies voor de update kunt u vinden op:
http://kb.parallels.com/en/8338

Wij raden in ieder geval aan om voor het rebooten van uw VPS of het updaten van CentOS Plesk te updaten om deze update te implementeren.

VPS Cluster Storing

dinsdag, mei 4th, 2010

Wij hebben vanochtend van 10:00 tot ongeveer 11:20 een storing gehad op één van onze VPS clusters.

Na onderzoek is gebleken dat de problemen veroorzaakt zijn door één van de RAID-controllers die defect was geraakt. De andere raidcontroller kon het werk wel overnemen maar degeen met de error stuurde verstorende signalen naar de rest van het cluster. Dit veroorzaakte zoveel overlast binnen het interne netwerk van het cluster dat de servers de verbinding met de SAN (Storage Area Network) kwijt zijn geraakt. Het probleem kon door personeel ter plekke om 11.15 worden verholpen en vervolgens hebben wij alle virtuele servers weer online gebracht.

Wij gaan contact opnemen met de leverancier van de SAN om ervoor te zorgen dat dit probleem zich niet meer voor kan doen. Aangezien wij voor dit soort situaties van redundante RAID-controllers gebruik maken is het voor onze klanten en voor ons niet acceptabel dat het systeem alsnog last kan hebben van het stuk gaan van een enkele RAID-controller.

Alle virtuele servers lijken in ieder geval goed te draaien. Neem contact met ons op als u nog vragen of opmerkingen heeft.