>> Yes, that's right, the MySQL database is on another machine from pmaccd. >> I >> know this isn't the recommended setup, but (a) the machines are >> co-located > > This is not true. A modular design is generally the way to go for bigger > installations.
Oh, good. It seemed sensible. > Both scenarios are indeed supported. RTT of 70ms doesn't look impressive > but will definitely work. That's the reliable worst-case. It's usually better, but there are some machines in other data centres. > The connection to the database is not persistent; every time the SQL cache > scanner kicks in (sql_refresh_time), a new connection to the database is > made. Ah... In that case, what may be happening is that we are running out of sockets. At peak loads, there can be so many TCP/IP connections that the kernel starts to limit them. I've raised this kernel limit in the past, but there will always be maximal peaks. It is the nature of the internet. If there was less traffic on those machine, I'd be less interested in logging it. That would also explain why I though I saw the daemon switch to another IP interface in the middle of running. Because it did! All makes sense now... I don't suppose there's an option to make at least one connection persistent? Or for the plugin to retry for a few seconds rather than just die? I can restart pmacctd, but it looses data in that second or two. And my client IP interface would also stop jumping around, that would be nice. I'll bet if I was aggregating less and generating a flood of records, then I'd always stay connected? So my deliberate attempt to keep transactions low is biting me in the ass? Typical. ;-) > The mysql_real_connect(), part of the MySQL API, doesn't allow to specify > an IP address to use for originating a TCP connection to a remote > database. > Hence pmacct can do nothing about it; if there is a knob to be configured > on the MySQL side of the things, that can be very likely in your my.cnf > MySQL configuration file. If you are successful in this, let us know - it > could be good to know for other people. I'll look into it, and let you know what I find. Down to the source code, if I have to. > I traditionally totally second Karl's and Wim's position of: "PostgreSQL > rocks"; although i'm not sure PostgreSQL would do any better in the same > pants. Meh, it's not like I had a choice. LAMP (Linux, Apache, MySQL, PHP) is basically a defacto standard. It's everywhere, and it mostly works. I actually picked pmacct because of it's MySQL support. It was the crucial feature. Once the data was flowing in, it was quite a boring task to throw it into some web pages and pretty graphs in an existing management system, which was the whole point of the exercise. I've got a single page which shows real-time traffic across multiple servers, all nice and neat. Now I just have to make sure it keeps working when I turn my back for two hours. -- Jeremy Lee BCompSci (Hons) The Unorthodox Engineers www.unorthodox.com.au _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
