Recente updates Pagina 2 Wissel reactie discussies | Sneltoetsen

  • Reinoud 19:13 op 21 January 2011 Permalink | Beantwoorden
    Tags: cacti   

    Cacti graph exportation 

    I am a enthusiast user of Cacti because it gives me a good insight in the health and functioning of my servers. Aside from that it’s a great tool to discover the cause of a problem when an incident occurs. We are all familiar with the extreme flexibility of Cacti and it’s data and graph templates but today I discovered a feature which I hadn’t seen before.

    The Cacti is the graph exportation feature to be precise. It gives you the opportunity to export all or a subset of your graphs periodically using various methods. It can export your graphs via FTP, SFTP or locally on the server that is running your Cacti daemon. Of course you can specify authentication and path information for your export but even better you can control a lot more! You can arrange everything from the timing of the exports until the size of the exported graphs.

    Possible applications of this feature are easy to imagine for example automatic offsite access to your graphs for when your Cacti server becomes unreachable and you need to backtrack the problem. Another application can be the providing of authentication free access to your graph tree for example to your internal network.

    You can find the graph exportation settings when logging into your Cacti administration panel using an account with enough rights to administer settings on your Cacti installation. After logging in you navigate to the console tab, from the left menu choose Settings under the section Configuration. On the page that appears select the tab Graph Export.

    Edit:

    Be careful with the export interval you choose. Cacti has several options to create a timing scheme, for example hourly, daily or per poller-run. Be aware of the fact that when you have large number of graphs the exportation can be quite a burden on the load of your servers I/O!

     
  • Reinoud 22:55 op 20 January 2011 Permalink | Beantwoorden  

    Continuing in English 

    Although much hasn’t yet been written on this blog I hereby officially announce that future writings on this blog will be in English.

    Choosing English as a language for this blog has two primary reasons. By far the most important is that computers are English. That’s an odd sentence but it’s true. Everything that surrounds computers is named English. Abbreviations, hardware, programming functions and language constructors but most importantly communication! As all the previous and even more is in English it seems silly to write in Dutch. When writing in Dutch over and over again there is a doubt in my mind whether or not to translate a certain word or not. Sometimes you do and it makes a sentence seem ugly, sometimes you don’t and it makes your whole post seem inconsistent.

    Except for the translational problems there is the audience. Since my primary subject of writing will be day to day handy things I encounter during my work it is useful information for the whole world. Not just the (very tiny) Dutch speaking part.

    So, English it will be. If you don’t like it: Translate!

     
  • Reinoud 19:26 op 7 September 2010 Permalink | Beantwoorden
    Tags: MySQL   

    MySQL en threads die hangen op end-state 

    Dat MySQL zich soms eigenaardig gedraagt is geen verassing. De database server geniet als gevolg van zijn brede inzet blijkbaar een onuitputtelijk respect van de ‘community’ en lijkt weinig te lijden te hebben onder steeds serieuzer worden prestatie- en schaalbaarheid-problematiek.

    Soms lijkt het alsof de MySQL het niet voor elkaar krijgt om volwassen te worden, iets dat misschien veranderd nu moeder bedrijf Sun is ingelijfd door Oracle. Een onderbouwing voor deze stelling blijkt uit een probleem waarmee ik en een aantal van mijn collegae de afgelopen weken mee hebben geworsteld.

    De MySQL server waar de problemen in kwestie zich voor deden wordt intensief belast en gebruikt maar is hiervoor hadwarematig ook ter degen uitgerust. De server beschikt bijvoorbeeld over 16 GB geheugen, verschillende processors en zeer snelle SSD schijven.

    Na enkele maanden zonder problemen in productie te hebben gedraaid begon de server in kwestie kuren te vertonen. De log-gegevens en analytische statistieken van de server vertoonde geen afwijkingen. De load was stabiel net zoals het geheugen gebruik en I/O gebruik. Na een diepere analyse kwam naar voren dat er threads bleven steken op de state ‘end’. De threads in kwestie waren altijd bezig met simpele UPDATE en INSERT queries op een variatie aan tabellen en databases. Echter zodra een thread in de state ‘end’ kwam kregen alle  andere threads die bewerkingen of selecties op tabellen en databases uitvoerden de status ‘locked’ . Gezien de intensieve belasting van de server zorgde dit er voor dat binnen een korte periode alle threads bezet waren, allen met de status ‘locked’.

    Het zoeken van de oorzaak in zo’n geval is relatief complex aangezien het vaststellen van een eenduidige oorzaak niet voor de hand licht gezien de wisselende databases en tabellen waarop de problemen zich voordoen. Na het door lezen van de MySQL documentatie met betrekking tot General Thread States werd het in ieder geval duidelijker waarmee een thread bezig was tijdens de ‘end’ state.

    Gezien het feit dat de server in kwestie een master servers in een replicatie proces sprong de activiteit ‘writing to binary log’ in het bijzonder in het oog. Was er dan toch een mogelijk probleem met de configuratie en / of opstelling van de SSD schijven? I/O prestaties waren echter dik in orde, daarbij wanneer een thread hing op end state was er geen enkele I/O activiteit waar te nemen. Misschien zat het dan toch in de cache van de schijven of  RAID Controller?

    Cache was inderdaad de oorzaak van het probleem, echter niet de cache waar we in eerste instantie aan dachten. Een tweede activiteit die MySQL uitvoert gedurende de end-state van een thread is het bijwerken van de query-cache. Als gevolg van zeer diepgaande technische problemen, hier uitgelegd door Lutz Euler, heeft MySQL last van het bijhouden van (zeer) grote query-caches. Na het verkleinen van de query-cache van 4 GB naar 512 MB is het probleem als sneeuw voor de zon verdwenen. Meer achtergrond informatie vind je hier.

    Ondanks dat de melding van de bug door de MySQL developers is gesloten doet het probleem zich in de meest recente versie nog steeds voor. Opmerkelijk want in een omgeving die veel van een server vraagt kan een degelijke query-cache het verschil maken!

     
  • Reinoud 19:54 op 5 September 2010 Permalink | Beantwoorden
    Tags: , iPhone,   

    En ook hallo vanaf een iPhone 

    Misschien minder bekend, maar daardoor niet onhandig is de iPhone App voor WordPress.

    Bekend of niet, deze post is geschreven vanaf een iPhone met de officiële WordPress App.

    Vooral handig zijn de geo-tag en de foto die ik heb toegevoegd aan deze post. Dit laat zien waarom juist blogging op mobiele apparaten bijdraagt aan een meer dynamisch internet.

     
  • Reinoud 17:26 op 5 September 2010 Permalink | Beantwoorden
    Tags: , iPad,   

    Hallo vanaf een iPad 

    Voordat ik iets configureer aan mijn blog schrijf ik eerst dit bericht. Om te laten zien dat een iPad qua mogelijkheden niet onderdoed voor een “normale” computer heb ik dit blog opgezet.

    Dit blog is volledig opgezet via een iPad. Om te beginnen heb ik als eerste de inloggegevens van de hostingprovider van dit domein opgegeraven. Vervolgens heb ik de DNS opnieuw ingesteld om te wijzen naar ddze nieuwe server. Nadat de DNS was geconfigureerd heb ik op de nieuwe server ingelogd in Plesk om een accountvoor het domein aan te maken. Hierbij heb ik direct de nodige instellingen gewijzigd en een database aangemaakt. Na een korte test heb ik vervolgens inlgelog via SSH op de nieuwe server. Om dit te doen heb ik wel een SSH App uit de AppStore moeten downloaden. Daarna was het tijd om de tarrball met WordPress te downloaden. Uitpakken, installleren en configuratie doorlopen.

    En als laatste natuurlijk even deze post typen!

     
c
Maak een nieuw bericht
j
volgende post/volgende reactie
k
vorige post / vorige opmerking
r
Beantwoorden
e
Bewerken
o
toon / verberg reacties
t
ga naar boven
l
ga naar log-in
h
hulp weergeven/verbergen
shift + esc
Annuleren