Showing posts with label Troubleshooting. Show all posts
Showing posts with label Troubleshooting. Show all posts

A curious case of flickering lights and a well pump


This has to be one of the most unexpected troubleshooting finales I've seen in a long while.

UPS on the cheap: Ecoflow River 2 versus River 3 (non-plus)


This blog post compares UPS transfer times between Ecoflow River 2 and River 3 (non-plus). That's it. That's the intro.

Powering a USB Dash Cam: Lessons Learned from VanTrue N4 Pro


Welcome back guys and gals. This time around, there won't be any diagrams, pictures, or wonky Excel charts. Just a public service announcement from a guy who just spent a few days troubleshooting an issue with the VanTrue N4 Pro dash cam. I promise to keep it short, unlike the troubleshooting process I just went through. Ha ha.

This is for folks who are using their dash cams with 3rd party power supplies or cables. If you're using the exact power supply that came with your camera, this issue might not apply to you.

Quick look: Voltage drift / instability on Ruideng RD6006 power supply


This post is a quick record of voltage drift / variations I noticed during recent experiments with using a MOSFET as a voltage-controlled resistor, where the MOSFET's Gate-Source voltage was driven by the Ruideng RD6006(W) DC-DC power supply.

Measuring breadboard wiring resistance: how bad is bad?


This article is a brief record of my early breadboard wiring adventures, because learning things the hard way is fun! You may also read the related post if you wish:




The story of MySQL Bug #86664


This is a story about why it's a good idea to test and verify the behavior of new software releases, even if the change log says that a particular bug was already fixed.

Investigating InnoDB FULLTEXT cache performance issues in MySQL <5.6.30


I'm not a huge fan of the InnoDB FULLTEXT feature and I admit I wasn't too keen to play with it in the past. Apparently, the feeling is mutual and so FULLTEXT issues haven't popped up in too many projects I worked on... until last week.

This post describes the troubleshooting process of a FULLTEXT cache performance issue. Quite inconspicuous at the beginning, it proved to be a lot of fun in the end.

Ready, Set, GDB!

Understanding and profiling MySQL execution with Callgrind, Pstack and Perf


You may sometimes hear complaints about MySQL not providing good enough tools for profiling and execution analysis. A few years ago I would have agreed with such opinions, thankfully MySQL developers have made huge efforts to improve the situation in recent major versions. MySQL DBAs now have some great native diagnostic tools at their disposal... which is totally not what this article is about :)

Native MySQL tooling (whatever it might be) is just the tip of the iceberg and if you want to be a better troubleshooter, SysAdmins are the first people you should talk to. Their toolboxes are full of awesomeness and the tools they use have one significant advantage over MySQL tools: they can analyze server execution holistically, regardless of the MySQL version you may be using.

In this article, we will have a look at three OS-level tools: pstack, perf and callgrind (Valgrind tool).

Profiling MySQL memory usage with Valgrind / Massif


High memory usage scenarios may sometimes be trivial to troubleshoot e.g. when memory parameters are explicitly set too high. Investigations into such issues may also prove to be very difficult when memory pressure is a result of specific workload patterns or better yet, engine bugs.

Advanced memory troubleshooting in MySQL was never easy but thanks to performance_schema memory instrumentation in MySQL 5.7, we finally have some tools to work with. There are still situations when performance schema will not be sufficient:
  1. On servers running MyQL <5.7 (well... vast majority),
  2. When the component you're interested in is not instrumented,
  3. When you don't fancy reading cryptic names of performance schema instruments. While I do love performance schema, this is no joke: OS-level heap profiles are much easier to read than data in performance schema (and they point you directly to the relevant locations in the code).
In this short article, I'll show you how easy it is to use the well known Valgrind / Massif tools to profile MySQL memory usage, no matter which MySQL version you're running.

Debugging MySQL execution with server tracing


In the life of a professional MySQL DBA there comes a moment when issues are no longer trivial enough to be diagnosed using simple repros and built-in diagnostic commands. While trying to understand complex problems, you may be forced (challenged?) to look for answers at the lowest level, by analyzing the server's source code.

If you're a seasoned database engineer who killed several keyboards reporting MySQL bugs, you can stop reading now. If you're just about to begin your journey into the source, you could probably use all the help you can get so keep reading. In this short article I'll describe the MySQL server tracing feature I've been using as an aid during MySQL investigations.

Investigating memory usage with Performance Schema in MySQL 5.7


Performance Schema has been with us for a while now. Over the years, it has gone a long way from being a curiosity disabled by default to becoming a sophisticated diagnostic tool you may want to enable permanently in your production database.

MySQL 5.7 introduced some exciting Performance Schema features and the first one I'm going to look at is the instrumentation for server memory usage.