Quicksearch

Disclaimer

The individual owning this blog works for Oracle in Germany. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.

Wednesday, September 11. 2013

Sometimes i would like to be able to do the jedi mind trick. Like "This isn't the performance issue you are searching for". Because it would be easier to convince people in that case that they saw the effect, but not the cause. That said, I think the real root cause on what i will describe in this block of this problem is the separation of database admins and system admins. But that's my personal opinion.. Imagine from one day to another, your storage goes mad. The analytic tools of your storage show long latencies, the led of the storage just show massive use of the storage. As you didn't made any change your first assumption is "storage has a defect" or "i just hit a bug in the storage firmware". At the end he or she thinks "No major release changes. Perhaps a few minor configuration changes. And none of them has to do with storage".

Friday, July 6. 2012

Folks, there is a tool that is highly misused, a tool that was meant for a completly different task, but now used by people to measure or compare something: ping. Don't use it as a latency measuring tool. Ping doesn't deserve this. Ping is a tool to find out, if a host is reachable by IP (that said, i saw more than one situation where a system was reachable by ping, but absolutely dead otherwise).

However: The measured numbers with three digits precision after a comma suggests, that there really measure network latency precicely. It is perhaps that precise. However the truth is: It don't measure network latency, it measures an amalgam of many things. And the network is just a part of it. When you are pinging you are measuring the time from sending the ICMP echo request to the time the ping tool is receiving the ICMP reply. So far so good, however it includes that the ping tool has maybe giving up the cpu because it was just waiting, so it has to be put on some CPU again. And then when you compare implementations it may be the case, that an implementation of ICMP was considered as good enough and it wasn't optimized anymore because i don't think there is a single person on the planet doing icmp echo request/reply as a mission critical, performance critical part.

There are better tools to measure the latency. For example on Solaris by using superping.d which leverages dtrace and ping to get a more precise image of the real network latency by closely monitoring the network stack via DTrace. On the other side, ICMP is answered by a kernel driver, so when you really want to measure network latency from app to app use a tool like iperf, that is started as a process in userland (... and run it with similar scheduling priorities as your real application).

BTW: Before you ask ... even with a 1 GB interface you can measure for example with superping the difference between the latency based on the ping tool and the latency measured by superping.d . And now take the reduced physical latencies in 10 GbE or even Infiniband networks into consideration and what it means for the precision of your measurement.

So, please: Use ping as a tool to make a first guess if the system on the other side is running. However: Don't use it as a tool to measure network latencies in your local network (or even to assess the quality of a networking implementation). I dare you, i double dare you

Thursday, December 22. 2005

Okay, you´ve downloaded the Sun One Directory server, want to use an opensource application with schema extensions for OpenLdap... but ... the schema files of openldap are non-standard, so you are not able to add them to the Sun One Directory Server. You have to rewrite them. Or convert them with a little script.