Showing entries 1 to 4
Displaying posts with tag: threads (reset)
Tab Sweep: Email, AntClassLoader, CouchBase Manager, Memory Usage, ...

Recent Tips and News on Java, Java EE 6, GlassFish & more :

Java, GlassFish v3, High CPU and Memory Usage, Locked Threads, Death (Gregor Bowie)
Why I will continue to use Spring *and* Java EE in new Enterprise Java Projects in 2012/2013 (Nikos Maravitsas)
The Most Frequently Asked Question About Java EE 6 & NetBeans (Geertjan)
• …

[Read more]
Things I didn't know you could do with top...

My colleague Mike Hamrick, who I'm very fortunate to work with, made a presentation on some cool things you can do with top: http://tinyurl.com/48pmu83. These are some great tips that every MySQL DBA or developer should watch!

Write data asynchronously to MySQL

I think most developers are able to cache database queries by now. But what about DML queries? Every query, connection - or in the general case - ressource needs time. So I thought a lot about how to write data as efficiently as possible into the database - in my case MySQL. Hmm...We have to take a closer look at the details and we can't choose the same asynchronously writing method for every kind of query. With kind of query I mean that it depends on what storage engine we use, the complexity of the query, should more than one record be written at once, are triggers involved and so on. Sure, the one or the other query MUST be written instantly, but most of the writing querys are stackable with no need to check if the request has succeed.

Read the rest »

The invisible I/O thread failures are no more

To get the status of the replication slave, it is possible to check the Last_Error and Last_Errno fields from SHOW SLAVE STATUS. Unfortunately, they only give information about the status of the SQL thread (and not always that either). If the I/O thread fails, for example, because the server configuration is not correctly set up, or if the connection to the master is lost due to a network outage, it is necessary to dig through the error log to find out the reason. This might be possible, although annoying, for a DBA to do since he has access to the files on the machine where the server is running, but when using automatic recovery applications that watch the status of the replication, this is not practical. It is also easier to see the status of the server through a normal client connection, …

[Read more]
Showing entries 1 to 4