Mark's blog - Comments

David Keech: Linux, Solaris and FreeBSD iostat monitoring with Cacti

nospam@example.com (David Keech) — Wed, 10 Mar 2010 16:14:49 +0000

I just thought I'd add, in case anyone using cacti hasn't yet discovered them, the Better Cacti Templates project. http://code.google.com/p/mysql-cacti-templates/ They have some similar IOStat graphs to these ones along with graphs for Apache, Memcached, Nginx and a set of absolutely brilliant MySQL graphs.

David Keech: Linux, Solaris and FreeBSD iostat monitoring with Cacti

nospam@example.com (David Keech) — Wed, 10 Mar 2010 16:05:33 +0000

Importing templates from newer versions of Cacti into older versions of Cacti usually does not work. These templates were exported from 0.8.7b (or later depending on which OS you are using). The current version is 0.8.7e. Try upgrading.

Mig: Centreon review

nospam@example.com (Mig) — Wed, 10 Mar 2010 15:51:31 +0000

Thanks, I needed this in order to convince the PHB.

Vegard: LigHTTPd and Apache - Symfony benchmarks

nospam@example.com (Vegard) — Fri, 05 Mar 2010 00:48:15 +0000

Actually if we're going to use Moores Law (1) we should have seen much better performance on this today, but that is not the case. A tuned setup will reach around 150 req/s and then flat out. With PHP-caching you can reach up to around 200 req/s, but then again that does not add up to Moores Law. So these numbers seems quite correct. You can read more about how to serve (in my tests) up to 9000 req/s in my blog, but that is not dynamic data! There is a huge differense between serving static and dynamic data. (2) (1) http://en.wikipedia.org/wiki/Moore's_law (2) http://www.vvvegard.net/blog/category/varnish/ Kind regards, Vegard

Tom: Linux, Solaris and FreeBSD iostat monitoring with Cacti

nospam@example.com (Tom) — Sat, 13 Feb 2010 00:01:42 +0000

Error: XML: Hash version does not exist. I'm running latest cacti 0.8.7a and I can't import any of the templates. Ideas?

Richard Wiseman: Apache mod_proxy balancing with PHP sticky sessions

nospam@example.com (Richard Wiseman) — Fri, 05 Feb 2010 10:49:17 +0000

Sorry, typo in my last post! It should read: "It appears to be ignoring the route=www8888 in my BalancerMember entry."

Richard Wiseman: Apache mod_proxy balancing with PHP sticky sessions

nospam@example.com (Richard Wiseman) — Fri, 05 Feb 2010 10:16:15 +0000

Thanks for the article, it almost works for me! Any idea why I might be getting: proxy: BALANCER: Found value balancer.www8888 for stickysession balancerID proxy: BALANCER: Found route www8888 followed immediately by: proxy: Entering byrequests for BALANCER (balancer://cluster) ? It appears to be ignoring the route=www888 in my BalancerMember entry. Thanks!

Mark Round: Building a redundant iSCSI and NFS cluster with Debian - Part 4

nospam@example.com (Mark Round) — Thu, 04 Feb 2010 11:46:16 +0000

When Heartbeat takes over an IP address, it send a "gratuitous ARP"[1] which should let everything know that the MAC address has changed. In my experience, failover is pretty quick and many of the initiators don't seem to notice. The worst case scenario is that it appears that a disk has temporarily gone offline which may produce a SCSI timeout/reset error. [1]=http://wiki.wireshark.org/Gratuitous_ARP

Bart Coninckx: Building a redundant iSCSI and NFS cluster with Debian - Part 4

nospam@example.com (Bart Coninckx) — Thu, 04 Feb 2010 11:40:20 +0000

Hi Mark, what happens to the iscsi initiator when a failover happens? I can imagine there is quite a delay involved with this. First you have the time to failover which, granted, can be reduced by correctly configuring ha.cf but what I wonder mostly about is the ARP cache for the storage interfaces: they will point to the MAC adresses of the last active node. Once a failover has happened, how long will it take for them to understand that the IP stack should now talk to a different MAC address to which the shared IP is linked? If this is a shorter amount of time than the iscsi initiatior or higher level file systems or applications can deal with it's no biggie, but if not ...

Mark Round: LigHTTPd and Apache - Symfony benchmarks

nospam@example.com (Mark Round) — Fri, 22 Jan 2010 11:25:18 +0000

FWIW, I'm inclined to agree. This test was run years ago (2006), and I can't remember all the details or even what system was running the ab client. I seem to recall the application being in dev mode, with all sorts of tracing and logging enabled which slowed it down. But 17 req/s is poor - but the principle behind the test still stands; LigHTTPd clearly beat Apache. I haven't revisited this for years (we never ended up going with LigHTTPd in production) so it would be interesting to run these tests again on up-to-date hardware and software...

Tom: LigHTTPd and Apache - Symfony benchmarks

nospam@example.com (Tom) — Thu, 21 Jan 2010 03:00:46 +0000

Wow, 17 req/s, I get at least 50 req/s on complex pages using my favorite python framework (pylons). I get even better results, like 3000 req/s when using one of the various erlang frameworks. 17 req/s is just pathetic.

mateusz: Linux, Solaris and FreeBSD iostat monitoring with Cacti

nospam@example.com (mateusz) — Sat, 16 Jan 2010 09:19:06 +0000

Great work !!!! Thanks a lot

runlevel: Linux, Solaris and FreeBSD iostat monitoring with Cacti

nospam@example.com (runlevel) — Mon, 11 Jan 2010 20:36:56 +0000

AH HA!, i found out my issue with: + No SNMP data returned when adding data querys, i had to set the snmp timeout from 400ms to 10000ms. my host was returning snmpwalk data but very slowly. once i set it to a timeout of 10,000ms cacti can now get the data and add the query!

runlevel: Linux, Solaris and FreeBSD iostat monitoring with Cacti

nospam@example.com (runlevel) — Mon, 11 Jan 2010 17:56:57 +0000

Same issue here + No SNMP data returned

perez: Linux, Solaris and FreeBSD iostat monitoring with Cacti

nospam@example.com (perez) — Wed, 06 Jan 2010 14:56:12 +0000

is this post still alive cause I am running into the similar problem??