> Nothing I've done has significantly changed the eight minute lag which is > even consistent across all the machines. Running 'date' on a console gives > a time eight to ten minutes ahead of the latest database record. If I > restart pmacctd, I get an eight minute gap in the data. If I restart every > five minutes (I got impatient) rows just never get into the database.
And just to prove that the universe hates me and makes my words lies, after letting it run all night it's now inserting into the database in near real-time. There hasn't been a single missed slot in eight hours. The lag is gone. It's the same on all the servers, including the ones I didn't mess with. *shrug* So, I'm just going to back away carefully from the console and leave it alone. I kind of feel that the lag will come back if I restart the daemon, so I just won't. I'll keep an eye on it and see if it breaks in any new ways. I've been trawling through MySQL documentation looking for a way to anchor the client TCP/IP connection to a specific local interface. The server has such an option, but apparently not the client library. Not documented, anyway. The answer is in the MySQL source code, but the stupid repository code browser is down, and I don't wanna download the whole thing just yet. Oh, PS; After looking at the debug SQL, I've got a small suggestion. when you do UPDATE statements, you set "stamp_updated=NOW()". MySQL actually has a field attribute to automatically do that to a TIMESTAMP field, called "ON UPDATE CURRENT_TIMESTAMP". You could optimize the queries even further so that if this attribute was detected on the "stamp_updated" field, then you could omit the explicit "stamp_updated=NOW()" part of every SQL statement. The same thing gets done, but you use less bandwidth. And it's probably an easy optimization. -- Jeremy Lee BCompSci (Hons) The Unorthodox Engineers www.unorthodox.com.au _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
